Kod's current autocomplete system uses the default Cocoa behavior because I wanted to work on the back end, not the front end. Now the back end is in place and it's time to make the interface behave in a way that makes sense to programmers.
Things I have been hearing that I agree with: - Esc/Shift+Esc should cycle through results rather than bringing the menu up and closing it repeatedly - These keys should be customizable - Resulting text should not be selected, but rather the cursor should be moved to the end of the completed word (like TextMate, naturally) - The results list is not always necessary and can get in the way. But I like seeing the list if the first suggestion isn't what I want.
Here is what I propose: - Keyboard shortcuts will be preferences, though I may not get around to the GUI for some time - The default Cocoa autocomplete behavior will be completely disabled and a custom system put in its place - That means the suggestions list will be temporarily removed, but I want to bring it back with syntax-highlighted items - Whatever the consensus is on Perfect Autocomplete Behavior will be implemented
What is Perfect Autocomplete Behavior? I have two models to work from. One is TextMate, the simplest. Esc/Shift+Esc cycles through results and the cursor is kept at the end. The other is Xcode, which shows a "completion ghost" which is accepted if you press Return, in addition to an Esc suggestions menu. I think I prefer the TextMate model with the addition of a list that appears if the first suggestion is not taken. It's certainly easier to implement.
> Kod's current autocomplete system uses the default Cocoa behavior because I > wanted to work on the back end, not the front end. Now the back end is in > place and it's time to make the interface behave in a way that makes sense > to programmers.
> Things I have been hearing that I agree with: > - Esc/Shift+Esc should cycle through results rather than bringing the menu > up and closing it repeatedly > - These keys should be customizable > - Resulting text should not be selected, but rather the cursor should be > moved to the end of the completed word (like TextMate, naturally) > - The results list is not always necessary and can get in the way. But I > like seeing the list if the first suggestion isn't what I want.
> Here is what I propose: > - Keyboard shortcuts will be preferences, though I may not get around to > the GUI for some time > - The default Cocoa autocomplete behavior will be completely disabled and a > custom system put in its place > - That means the suggestions list will be temporarily removed, but I want > to bring it back with syntax-highlighted items > - Whatever the consensus is on Perfect Autocomplete Behavior will be > implemented
> What is Perfect Autocomplete Behavior? I have two models to work from. One > is TextMate, the simplest. Esc/Shift+Esc cycles through results and the > cursor is kept at the end. The other is Xcode, which shows a "completion > ghost" which is accepted if you press Return, in addition to an Esc > suggestions menu. I think I prefer the TextMate model with the addition of a > list that appears if the first suggestion is not taken. It's certainly > easier to implement.
> Your thoughts?
> -Steve Johnson
> -- > You received this message because you are subscribed to the Google > Groups "Kod.app" group. To unsubscribe from this group, send email to > kod-app+unsubscribe@googlegroups.com<kod-app%2Bunsubscribe@googlegroups.com >(More info at > http://groups.google.com/group/kod-app)
> Kod's current autocomplete system uses the default Cocoa behavior because I > wanted to work on the back end, not the front end. Now the back end is in > place and it's time to make the interface behave in a way that makes sense > to programmers.
> Things I have been hearing that I agree with: > - Esc/Shift+Esc should cycle through results rather than bringing the menu > up and closing it repeatedly > - These keys should be customizable > - Resulting text should not be selected, but rather the cursor should be > moved to the end of the completed word (like TextMate, naturally) > - The results list is not always necessary and can get in the way. But I > like seeing the list if the first suggestion isn't what I want.
> Here is what I propose: > - Keyboard shortcuts will be preferences, though I may not get around to > the GUI for some time > - The default Cocoa autocomplete behavior will be completely disabled and a > custom system put in its place > - That means the suggestions list will be temporarily removed, but I want > to bring it back with syntax-highlighted items > - Whatever the consensus is on Perfect Autocomplete Behavior will be > implemented
> What is Perfect Autocomplete Behavior? I have two models to work from. One > is TextMate, the simplest. Esc/Shift+Esc cycles through results and the > cursor is kept at the end. The other is Xcode, which shows a "completion > ghost" which is accepted if you press Return, in addition to an Esc > suggestions menu. I think I prefer the TextMate model with the addition of a > list that appears if the first suggestion is not taken. It's certainly > easier to implement.
> Your thoughts?
> -Steve Johnson
> -- > You received this message because you are subscribed to the Google > Groups "Kod.app" group. To unsubscribe from this group, send email to > kod-app+unsubscribe@googlegroups.com<kod-app%2Bunsubscribe@googlegroups.com >(More info at > http://groups.google.com/group/kod-app)
-- You received this message because you are subscribed to the Google Groups "Kod.app" group. To unsubscribe from this group, send email to kod-app+unsubscribe@googlegroups.com (More info at http://groups.google.com/group/kod-app)
> Kod's current autocomplete system uses the default Cocoa behavior because I > wanted to work on the back end, not the front end. Now the back end is in > place and it's time to make the interface behave in a way that makes sense > to programmers.
> Things I have been hearing that I agree with: > - Esc/Shift+Esc should cycle through results rather than bringing the menu > up and closing it repeatedly > - These keys should be customizable > - Resulting text should not be selected, but rather the cursor should be > moved to the end of the completed word (like TextMate, naturally) > - The results list is not always necessary and can get in the way. But I > like seeing the list if the first suggestion isn't what I want.
> Here is what I propose: > - Keyboard shortcuts will be preferences, though I may not get around to > the GUI for some time > - The default Cocoa autocomplete behavior will be completely disabled and a > custom system put in its place > - That means the suggestions list will be temporarily removed, but I want > to bring it back with syntax-highlighted items > - Whatever the consensus is on Perfect Autocomplete Behavior will be > implemented
> What is Perfect Autocomplete Behavior? I have two models to work from. One > is TextMate, the simplest. Esc/Shift+Esc cycles through results and the > cursor is kept at the end. The other is Xcode, which shows a "completion > ghost" which is accepted if you press Return, in addition to an Esc > suggestions menu. I think I prefer the TextMate model with the addition of a > list that appears if the first suggestion is not taken. It's certainly > easier to implement.
> Your thoughts?
> -Steve Johnson
> -- > You received this message because you are subscribed to the Google > Groups "Kod.app" group. To unsubscribe from this group, send email to > <kod-app%2Bunsubscribe@googlegroups.com> > kod-app+unsubscribe@googlegroups.com (More info at > <http://groups.google.com/group/kod-app> > http://groups.google.com/group/kod-app)
-- You received this message because you are subscribed to the Google Groups "Kod.app" group. To unsubscribe from this group, send email to kod-app+unsubscribe@googlegroups.com (More info at http://groups.google.com/group/kod-app)
On Sun, Jan 2, 2011 at 3:20 PM, Reed Stoner <kalte...@gmail.com> wrote: > I'm with Mario and Swizec
> Reed
> On Jan 2, 2011, at 3:00 PM, Mario Michelli <mmiche...@gmail.com> wrote:
> Autocomplete ghosting definitely has my vote, it's easy to ignore and feels > more elegant.
> Sent from my iPad
> On Jan 2, 2011, at 8:54 PM, Swizec Teller < <swi...@gmail.com> > swi...@gmail.com> wrote:
> From all the autocomplete systems I've worked with over the years, > XCode's seems the least intrusive and thus the least annoying.
> Therefore, my vote goes towards autocompletion ghosts.
> ~Swizec
> On 2 January 2011 19:54, Steve Johnson < <sr...@case.edu> <sr...@case.edu> > sr...@case.edu> wrote:
>> Kod's current autocomplete system uses the default Cocoa behavior because >> I wanted to work on the back end, not the front end. Now the back end is in >> place and it's time to make the interface behave in a way that makes sense >> to programmers.
>> Things I have been hearing that I agree with: >> - Esc/Shift+Esc should cycle through results rather than bringing the menu >> up and closing it repeatedly >> - These keys should be customizable >> - Resulting text should not be selected, but rather the cursor should be >> moved to the end of the completed word (like TextMate, naturally) >> - The results list is not always necessary and can get in the way. But I >> like seeing the list if the first suggestion isn't what I want.
>> Here is what I propose: >> - Keyboard shortcuts will be preferences, though I may not get around to >> the GUI for some time >> - The default Cocoa autocomplete behavior will be completely disabled and >> a custom system put in its place >> - That means the suggestions list will be temporarily removed, but I want >> to bring it back with syntax-highlighted items >> - Whatever the consensus is on Perfect Autocomplete Behavior will be >> implemented
>> What is Perfect Autocomplete Behavior? I have two models to work from. One >> is TextMate, the simplest. Esc/Shift+Esc cycles through results and the >> cursor is kept at the end. The other is Xcode, which shows a "completion >> ghost" which is accepted if you press Return, in addition to an Esc >> suggestions menu. I think I prefer the TextMate model with the addition of a >> list that appears if the first suggestion is not taken. It's certainly >> easier to implement.
> -- > You received this message because you are subscribed to the Google > Groups "Kod.app" group. To unsubscribe from this group, send email to > kod-app+unsubscribe@googlegroups.com<kod-app%2Bunsubscribe@googlegroups.com >(More info at > http://groups.google.com/group/kod-app)
I type until it gives me the right option. I never really cycle through them anyway, so using the arrow keys is fine. Thinking about it: You won't go far wrong imitating the behaviour of chrome and firefox's location bar.
Is it worth talking about snippets in the same thread?
On 2 Jan 2011, at 21:55, Steve Johnson <sr...@case.edu> wrote:
> So are you guys saying you don't mind if you have to use the arrow keys to cycle through suggestions?
> On Sun, Jan 2, 2011 at 3:20 PM, Reed Stoner <kalte...@gmail.com> wrote: > I'm with Mario and Swizec
> Reed
> On Jan 2, 2011, at 3:00 PM, Mario Michelli <mmiche...@gmail.com> wrote:
>> Autocomplete ghosting definitely has my vote, it's easy to ignore and feels more elegant.
>> Sent from my iPad
>> On Jan 2, 2011, at 8:54 PM, Swizec Teller <swi...@gmail.com> wrote:
>>> From all the autocomplete systems I've worked with over the years, >>> XCode's seems the least intrusive and thus the least annoying.
>>> Therefore, my vote goes towards autocompletion ghosts.
>>> ~Swizec
>>> On 2 January 2011 19:54, Steve Johnson <sr...@case.edu> wrote: >>> Kod's current autocomplete system uses the default Cocoa behavior because I wanted to work on the back end, not the front end. Now the back end is in place and it's time to make the interface behave in a way that makes sense to programmers.
>>> Things I have been hearing that I agree with: >>> - Esc/Shift+Esc should cycle through results rather than bringing the menu up and closing it repeatedly >>> - These keys should be customizable >>> - Resulting text should not be selected, but rather the cursor should be moved to the end of the completed word (like TextMate, naturally) >>> - The results list is not always necessary and can get in the way. But I like seeing the list if the first suggestion isn't what I want.
>>> Here is what I propose: >>> - Keyboard shortcuts will be preferences, though I may not get around to the GUI for some time >>> - The default Cocoa autocomplete behavior will be completely disabled and a custom system put in its place >>> - That means the suggestions list will be temporarily removed, but I want to bring it back with syntax-highlighted items >>> - Whatever the consensus is on Perfect Autocomplete Behavior will be implemented
>>> What is Perfect Autocomplete Behavior? I have two models to work from. One is TextMate, the simplest. Esc/Shift+Esc cycles through results and the cursor is kept at the end. The other is Xcode, which shows a "completion ghost" which is accepted if you press Return, in addition to an Esc suggestions menu. I think I prefer the TextMate model with the addition of a list that appears if the first suggestion is not taken. It's certainly easier to implement.
>>> Your thoughts?
>>> -Steve Johnson >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Kod.app" group. To unsubscribe from this group, send email to >>> kod-app+unsubscribe@googlegroups.com (More info at http://groups.google.com/group/kod-app)
>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Kod.app" group. To unsubscribe from this group, send email to >>> kod-app+unsubscribe@googlegroups.com (More info at http://groups.google.com/group/kod-app) >> -- >> You received this message because you are subscribed to the Google >> Groups "Kod.app" group. To unsubscribe from this group, send email to >> kod-app+unsubscribe@googlegroups.com (More info at http://groups.google.com/group/kod-app)
> -- > You received this message because you are subscribed to the Google > Groups "Kod.app" group. To unsubscribe from this group, send email to > kod-app+unsubscribe@googlegroups.com (More info at http://groups.google.com/group/kod-app)
> -- > You received this message because you are subscribed to the Google > Groups "Kod.app" group. To unsubscribe from this group, send email to > kod-app+unsubscribe@googlegroups.com (More info at http://groups.google.com/group/kod-app)
> I type until it gives me the right option. I never really cycle through > them anyway, so using the arrow keys is fine. > Thinking about it: > You won't go far wrong imitating the behaviour of chrome and firefox's > location bar.
> Is it worth talking about snippets in the same thread?
> On 2 Jan 2011, at 21:55, Steve Johnson <sr...@case.edu> wrote:
> So are you guys saying you don't mind if you have to use the arrow keys to > cycle through suggestions?
> On Sun, Jan 2, 2011 at 3:20 PM, Reed Stoner < <kalte...@gmail.com> > kalte...@gmail.com> wrote:
>> I'm with Mario and Swizec
>> Reed
>> On Jan 2, 2011, at 3:00 PM, Mario Michelli < <mmiche...@gmail.com> >> mmiche...@gmail.com> wrote:
>> Autocomplete ghosting definitely has my vote, it's easy to ignore and >> feels more elegant.
>> Sent from my iPad
>> On Jan 2, 2011, at 8:54 PM, Swizec Teller < <swi...@gmail.com><swi...@gmail.com> >> swi...@gmail.com> wrote:
>> From all the autocomplete systems I've worked with over the years, >> XCode's seems the least intrusive and thus the least annoying.
>> Therefore, my vote goes towards autocompletion ghosts.
>> ~Swizec
>> On 2 January 2011 19:54, Steve Johnson < <sr...@case.edu><sr...@case.edu><sr...@case.edu> >> sr...@case.edu> wrote:
>>> Kod's current autocomplete system uses the default Cocoa behavior because >>> I wanted to work on the back end, not the front end. Now the back end is in >>> place and it's time to make the interface behave in a way that makes sense >>> to programmers.
>>> Things I have been hearing that I agree with: >>> - Esc/Shift+Esc should cycle through results rather than bringing the >>> menu up and closing it repeatedly >>> - These keys should be customizable >>> - Resulting text should not be selected, but rather the cursor should be >>> moved to the end of the completed word (like TextMate, naturally) >>> - The results list is not always necessary and can get in the way. But I >>> like seeing the list if the first suggestion isn't what I want.
>>> Here is what I propose: >>> - Keyboard shortcuts will be preferences, though I may not get around to >>> the GUI for some time >>> - The default Cocoa autocomplete behavior will be completely disabled and >>> a custom system put in its place >>> - That means the suggestions list will be temporarily removed, but I want >>> to bring it back with syntax-highlighted items >>> - Whatever the consensus is on Perfect Autocomplete Behavior will be >>> implemented
>>> What is Perfect Autocomplete Behavior? I have two models to work from. >>> One is TextMate, the simplest. Esc/Shift+Esc cycles through results and the >>> cursor is kept at the end. The other is Xcode, which shows a "completion >>> ghost" which is accepted if you press Return, in addition to an Esc >>> suggestions menu. I think I prefer the TextMate model with the addition of a >>> list that appears if the first suggestion is not taken. It's certainly >>> easier to implement.
>> -- >> You received this message because you are subscribed to the Google >> Groups "Kod.app" group. To unsubscribe from this group, send email to >> <kod-app%2Bunsubscribe@googlegroups.com> >> kod-app+unsubscribe@googlegroups.com (More info at >> <http://groups.google.com/group/kod-app> >> http://groups.google.com/group/kod-app)
> -- > You received this message because you are subscribed to the Google > Groups "Kod.app" group. To unsubscribe from this group, send email to > kod-app+unsubscribe@googlegroups.com<kod-app%2Bunsubscribe@googlegroups.com >(More info at > http://groups.google.com/group/kod-app)
I favor the type until right as well. Though it would be nice to have some way to get a popup list with another key stroke. Something like ESC - ESC or ESC - up arrow. (The exact shortcut isn't important right now) That way, if you don't know or aren't sure of exact spelling of the symbol or method you can at least have a list to look through.
Reed
Sent from my iPad
On Jan 2, 2011, at 4:31 PM, Swizec Teller <swi...@gmail.com> wrote:
I'm with Mario. Just type until the right suggestion is there.
In that regard I probably use it more as some sort of contextualised spellchecker. :P
The idea being that I type faster than it usually takes me to pick suggestions from a list.
~Swizec
On 2 January 2011 22:24, Mario <mmiche...@gmail.com> wrote:
> I type until it gives me the right option. I never really cycle through > them anyway, so using the arrow keys is fine. > Thinking about it: > You won't go far wrong imitating the behaviour of chrome and firefox's > location bar.
> Is it worth talking about snippets in the same thread?
> On 2 Jan 2011, at 21:55, Steve Johnson <sr...@case.edu> wrote:
> So are you guys saying you don't mind if you have to use the arrow keys to > cycle through suggestions?
> On Sun, Jan 2, 2011 at 3:20 PM, Reed Stoner < <kalte...@gmail.com> > kalte...@gmail.com> wrote:
>> I'm with Mario and Swizec
>> Reed
>> On Jan 2, 2011, at 3:00 PM, Mario Michelli < <mmiche...@gmail.com> >> mmiche...@gmail.com> wrote:
>> Autocomplete ghosting definitely has my vote, it's easy to ignore and >> feels more elegant.
>> Sent from my iPad
>> On Jan 2, 2011, at 8:54 PM, Swizec Teller < <swi...@gmail.com><swi...@gmail.com> >> swi...@gmail.com> wrote:
>> From all the autocomplete systems I've worked with over the years, >> XCode's seems the least intrusive and thus the least annoying.
>> Therefore, my vote goes towards autocompletion ghosts.
>> ~Swizec
>> On 2 January 2011 19:54, Steve Johnson < <sr...@case.edu><sr...@case.edu><sr...@case.edu> >> sr...@case.edu> wrote:
>>> Kod's current autocomplete system uses the default Cocoa behavior because >>> I wanted to work on the back end, not the front end. Now the back end is in >>> place and it's time to make the interface behave in a way that makes sense >>> to programmers.
>>> Things I have been hearing that I agree with: >>> - Esc/Shift+Esc should cycle through results rather than bringing the >>> menu up and closing it repeatedly >>> - These keys should be customizable >>> - Resulting text should not be selected, but rather the cursor should be >>> moved to the end of the completed word (like TextMate, naturally) >>> - The results list is not always necessary and can get in the way. But I >>> like seeing the list if the first suggestion isn't what I want.
>>> Here is what I propose: >>> - Keyboard shortcuts will be preferences, though I may not get around to >>> the GUI for some time >>> - The default Cocoa autocomplete behavior will be completely disabled and >>> a custom system put in its place >>> - That means the suggestions list will be temporarily removed, but I want >>> to bring it back with syntax-highlighted items >>> - Whatever the consensus is on Perfect Autocomplete Behavior will be >>> implemented
>>> What is Perfect Autocomplete Behavior? I have two models to work from. >>> One is TextMate, the simplest. Esc/Shift+Esc cycles through results and the >>> cursor is kept at the end. The other is Xcode, which shows a "completion >>> ghost" which is accepted if you press Return, in addition to an Esc >>> suggestions menu. I think I prefer the TextMate model with the addition of a >>> list that appears if the first suggestion is not taken. It's certainly >>> easier to implement.
>> -- >> You received this message because you are subscribed to the Google >> Groups "Kod.app" group. To unsubscribe from this group, send email to >> <kod-app%2Bunsubscribe@googlegroups.com> >> kod-app+unsubscribe@googlegroups.com (More info at >> <http://groups.google.com/group/kod-app> >> http://groups.google.com/group/kod-app)
> -- > You received this message because you are subscribed to the Google > Groups "Kod.app" group. To unsubscribe from this group, send email to > kod-app+unsubscribe@googlegroups.com<kod-app%2Bunsubscribe@googlegroups.com >(More info at > http://groups.google.com/group/kod-app)
-- You received this message because you are subscribed to the Google Groups "Kod.app" group. To unsubscribe from this group, send email to kod-app+unsubscribe@googlegroups.com (More info at http://groups.google.com/group/kod-app)
I agree. I think an Xcode style implementation of auto-complete is the best way to go that way you get the suggestion as you type but you can also get a popup with all the suggestions by hitting ESC.
Ze'ev On Jan 2, 2011, at 1:45 PM, Reed Stoner wrote:
> I favor the type until right as well. Though it would be nice to have some way to get a popup list with another key stroke. Something like ESC - ESC or ESC - up arrow. (The exact shortcut isn't important right now) That way, if you don't know or aren't sure of exact spelling of the symbol or method you can at least have a list to look through.
> Reed
> Sent from my iPad
> On Jan 2, 2011, at 4:31 PM, Swizec Teller <swi...@gmail.com> wrote:
>> I'm with Mario. Just type until the right suggestion is there.
>> In that regard I probably use it more as some sort of contextualised spellchecker. :P
>> The idea being that I type faster than it usually takes me to pick suggestions from a list.
>> ~Swizec
>> On 2 January 2011 22:24, Mario <mmiche...@gmail.com> wrote: >> I type until it gives me the right option. I never really cycle through them anyway, so using the arrow keys is fine. >> Thinking about it: >> You won't go far wrong imitating the behaviour of chrome and firefox's location bar.
>> Is it worth talking about snippets in the same thread?
>> On 2 Jan 2011, at 21:55, Steve Johnson <sr...@case.edu> wrote:
>>> So are you guys saying you don't mind if you have to use the arrow keys to cycle through suggestions?
>>> On Sun, Jan 2, 2011 at 3:20 PM, Reed Stoner <kalte...@gmail.com> wrote: >>> I'm with Mario and Swizec
>>> Reed
>>> On Jan 2, 2011, at 3:00 PM, Mario Michelli <mmiche...@gmail.com> wrote:
>>>> Autocomplete ghosting definitely has my vote, it's easy to ignore and feels more elegant.
>>>> Sent from my iPad
>>>> On Jan 2, 2011, at 8:54 PM, Swizec Teller <swi...@gmail.com> wrote:
>>>>> From all the autocomplete systems I've worked with over the years, >>>>> XCode's seems the least intrusive and thus the least annoying.
>>>>> Therefore, my vote goes towards autocompletion ghosts.
>>>>> ~Swizec
>>>>> On 2 January 2011 19:54, Steve Johnson <sr...@case.edu> wrote: >>>>> Kod's current autocomplete system uses the default Cocoa behavior because I wanted to work on the back end, not the front end. Now the back end is in place and it's time to make the interface behave in a way that makes sense to programmers.
>>>>> Things I have been hearing that I agree with: >>>>> - Esc/Shift+Esc should cycle through results rather than bringing the menu up and closing it repeatedly >>>>> - These keys should be customizable >>>>> - Resulting text should not be selected, but rather the cursor should be moved to the end of the completed word (like TextMate, naturally) >>>>> - The results list is not always necessary and can get in the way. But I like seeing the list if the first suggestion isn't what I want.
>>>>> Here is what I propose: >>>>> - Keyboard shortcuts will be preferences, though I may not get around to the GUI for some time >>>>> - The default Cocoa autocomplete behavior will be completely disabled and a custom system put in its place >>>>> - That means the suggestions list will be temporarily removed, but I want to bring it back with syntax-highlighted items >>>>> - Whatever the consensus is on Perfect Autocomplete Behavior will be implemented
>>>>> What is Perfect Autocomplete Behavior? I have two models to work from. One is TextMate, the simplest. Esc/Shift+Esc cycles through results and the cursor is kept at the end. The other is Xcode, which shows a "completion ghost" which is accepted if you press Return, in addition to an Esc suggestions menu. I think I prefer the TextMate model with the addition of a list that appears if the first suggestion is not taken. It's certainly easier to implement.
>>>>> Your thoughts?
>>>>> -Steve Johnson
>>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Kod.app" group. To unsubscribe from this group, send email to >>>>> kod-app+unsubscribe@googlegroups.com (More info at http://groups.google.com/group/kod-app)
>>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Kod.app" group. To unsubscribe from this group, send email to >>>>> kod-app+unsubscribe@googlegroups.com (More info at http://groups.google.com/group/kod-app)
>>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Kod.app" group. To unsubscribe from this group, send email to >>>> kod-app+unsubscribe@googlegroups.com (More info at http://groups.google.com/group/kod-app)
>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Kod.app" group. To unsubscribe from this group, send email to >>> kod-app+unsubscribe@googlegroups.com (More info at http://groups.google.com/group/kod-app)
>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Kod.app" group. To unsubscribe from this group, send email to >>> kod-app+unsubscribe@googlegroups.com (More info at http://groups.google.com/group/kod-app)
>> -- >> You received this message because you are subscribed to the Google >> Groups "Kod.app" group. To unsubscribe from this group, send email to >> kod-app+unsubscribe@googlegroups.com (More info at http://groups.google.com/group/kod-app)
>> -- >> You received this message because you are subscribed to the Google >> Groups "Kod.app" group. To unsubscribe from this group, send email to >> kod-app+unsubscribe@googlegroups.com (More info at http://groups.google.com/group/kod-app)
> -- > You received this message because you are subscribed to the Google > Groups "Kod.app" group. To unsubscribe from this group, send email to > kod-app+unsubscribe@googlegroups.com (More info at http://groups.google.com/group/kod-app)
> Here is what I propose:
> - Keyboard shortcuts will be preferences, though I may not get around to the
> GUI for some time
Just make a menu item. So the keyboard shortcuts can be changed in the
system preferences until the preference GUI is finished.
> From all the autocomplete systems I've worked with over the years,
> XCode's seems the least intrusive and thus the least annoying.
> Therefore, my vote goes towards autocompletion ghosts.
I think one reason its not that intrusive is, that the word
suggestions are very well sorted and context sensitive. If we use it
for all the words we would complete right now, things may change.
There should be noted, that Xcode too has autocompletion with ESC, and
completes a lot more words that way. Maybe we should keep ghost-
completion and ESC-completion separated? The user could choose which
variant he prefers and which words will be completed.
Maybe I have big hands, but to press ESC, I can leave my thenar
resting next to the keypad and only need to move my fingers. Its
really easy and fast to press ESC and move back to the writing
position. To access the keypad however, I need to move my whole hand,
and even my arm. Thats why I really would like to keep the ESC-cycling
ability, if possible. To close the autocomplete overlay, just keep on
typing until no more match is found and the window disappears, or
press backspace.
Xcode also implements the previously mentioned "keep on typing to
filter" feature within the ESCish autocompletion. However, this will
need the backspace key to not leave autocompletion, so you can
rebroaden your filter or correct typos.
The main reason I want to cycle thru a autocomplete list at all, are
cases like "veryLongWord_foo" vs. "veryLongWord_bar". I don't want to
type the whole "veryLongWord" just to tell the autocomplete system
that I need to append "_foo" instead of "_bar".
An alternate approach to solve this could be the use of TAB to
complete until any of the possibilities differ. (Similar to path
completion in bash.)
And one final idea: If you use TAB to accept the autocompletion, keep
the autocompletion list open. An additional TAB will select the next
item, SHIFT-TAB the previous. Any other key will act like usual and
additionally close the autocompletion list.
If it works like Xcode, I think it is perfect, but... be aware that XCode has hidden options to customize autocompletion, which allow you to make it behave like previous versions. (with suggestion list autopopup)
I also am a fan of Xcode's autocomplete, and I'd love to see it in Kod. But having the ability to customize it like aristidesfl mentions might be nice for those who prefer the popup style.
The only thing I wonder about is how useful autocomplete will be. Now, I'm not sure if that has more to do with the bundles/plugins than what we're discussing here, but I know autocomplete is particularly frustrating to me when say I'm writing CSS and typing "wid...", looking for "width" and what insists on coming up I'd "widows". I never use "widows", but because it's alphabetically first, it shows up. I guess what I'm saying is, I'd love to have the autocomplete system be aware, and change/adapt to what I use an type frequently.
- Zach LeBar
On Jan 3, 2011, at 1:27 PM, aristidesfl <aristide...@gmail.com> wrote:
> If it works like Xcode, I think it is perfect, but... > be aware that XCode has hidden options to customize autocompletion, which allow you to make it behave like previous versions. (with suggestion list autopopup)
> -- > You received this message because you are subscribed to the Google > Groups "Kod.app" group. To unsubscribe from this group, send email to > kod-app+unsubscribe@googlegroups.com (More info at http://groups.google.com/group/kod-app)
On Monday, January 3, 2011 8:05:16 PM UTC+1, zachlebar wrote:
> The only thing I wonder about is how useful autocomplete will be. Now, I'm > not sure if that has more to do with the bundles/plugins than what we're > discussing here, but I know autocomplete is particularly frustrating to me > when say I'm writing CSS and typing "wid...", looking for "width" and what > insists on coming up I'd "widows". I never use "widows", but because it's > alphabetically first, it shows up. I guess what I'm saying is, I'd love to > have the autocomplete system be aware, and change/adapt to what I use an > type frequently.
Oh, you bring back painful memories! Those widows! The autocomplete feature implemented by both Coda and Espresso is obnoxious and bordering on useless, and furthermore there is no obvious way to turn it off, so it just interrupts your flow. Yet another demonstration that any order is more natural than the alphabetic one.
You know, you could actually try the feature as it exists before bemoaning its theoretical badness. It uses all the words in the file, and will eventually allow extensions to provide further suggestions.
On Mon, Jan 3, 2011 at 2:05 PM, Zach LeBar <zachle...@gmail.com> wrote: > I also am a fan of Xcode's autocomplete, and I'd love to see it in Kod. But > having the ability to customize it like aristidesfl mentions might be nice > for those who prefer the popup style.
> The only thing I wonder about is how useful autocomplete will be. Now, I'm > not sure if that has more to do with the bundles/plugins than what we're > discussing here, but I know autocomplete is particularly frustrating to me > when say I'm writing CSS and typing "wid...", looking for "width" and what > insists on coming up I'd "widows". I never use "widows", but because it's > alphabetically first, it shows up. I guess what I'm saying is, I'd love to > have the autocomplete system be aware, and change/adapt to what I use an > type frequently.
> - Zach LeBar
> On Jan 3, 2011, at 1:27 PM, aristidesfl <aristide...@gmail.com> wrote:
> If it works like Xcode, I think it is perfect, but... > be aware that XCode has hidden options to customize autocompletion, which > allow you to make it behave like previous versions. (with suggestion list > autopopup)
> -- > You received this message because you are subscribed to the Google > Groups "Kod.app" group. To unsubscribe from this group, send email to > kod-app+unsubscribe@googlegroups.com<kod-app%2Bunsubscribe@googlegroups.com >(More info at > http://groups.google.com/group/kod-app)
Oh, I wasn't bemoaning anything yet. I haven't gotten a chance to try it yet, I plan to. I was just venting a little about previous implementations that just didn't cut it IMO. Glad to see others know what I'm talking about though, and that Kod isn't headed in that direction.
- Zach LeBar
On Jan 3, 2011, at 7:12 PM, Steve Johnson <sr...@case.edu> wrote:
> You know, you could actually try the feature as it exists before bemoaning its theoretical badness. It uses all the words in the file, and will eventually allow extensions to provide further suggestions.
> On Mon, Jan 3, 2011 at 2:05 PM, Zach LeBar <zachle...@gmail.com> wrote: > I also am a fan of Xcode's autocomplete, and I'd love to see it in Kod. But having the ability to customize it like aristidesfl mentions might be nice for those who prefer the popup style.
> The only thing I wonder about is how useful autocomplete will be. Now, I'm not sure if that has more to do with the bundles/plugins than what we're discussing here, but I know autocomplete is particularly frustrating to me when say I'm writing CSS and typing "wid...", looking for "width" and what insists on coming up I'd "widows". I never use "widows", but because it's alphabetically first, it shows up. I guess what I'm saying is, I'd love to have the autocomplete system be aware, and change/adapt to what I use an type frequently.
> - Zach LeBar
> On Jan 3, 2011, at 1:27 PM, aristidesfl <aristide...@gmail.com> wrote:
>> If it works like Xcode, I think it is perfect, but... >> be aware that XCode has hidden options to customize autocompletion, which allow you to make it behave like previous versions. (with suggestion list autopopup)
>> -- >> You received this message because you are subscribed to the Google >> Groups "Kod.app" group. To unsubscribe from this group, send email to >> kod-app+unsubscribe@googlegroups.com (More info at http://groups.google.com/group/kod-app)
> -- > You received this message because you are subscribed to the Google > Groups "Kod.app" group. To unsubscribe from this group, send email to > kod-app+unsubscribe@googlegroups.com (More info at http://groups.google.com/group/kod-app)
> -- > You received this message because you are subscribed to the Google > Groups "Kod.app" group. To unsubscribe from this group, send email to > kod-app+unsubscribe@googlegroups.com (More info at http://groups.google.com/group/kod-app)
