On 2010-07-14 19:09, John J Barton wrote:
On Jul 12, 11:22 pm, Nicolas Hatier<[email protected]> wrote:
On 2010-07-12 10:17, John J Barton wrote:
...
Let's start again with 1.6a17. I'm not against removing the inline
completion, but other users did not what to use the arrow keys to
complete.
And why not?
You'll have to ask them to be sure, but two users said the arrow keys
cannot be reached from the ten-finger position and they are in
different positions on different keyboards interfering with
memorization.
This argument is not against using a key to initiate the autocompletion.
It's just against being forced to use up and down. You just have to
continue allowing the tab, as well as up and down. But don't start
autocomplete before one of these three keys are pressed, and I still
think inline completion should disappear.
Command-line-type people are used to use Tab for
completion. Cmd, bash and other shells never do completion before a
specific key is typed. Visual Studio autocomplete requires up or down.
Firefox and IE's address bar, as well as google autosuggest requires
up/down before using any of the candidate. The model is available and
quite widespread. Why reinventing it if it ain't broke?
Command line completion in a development environment is not like
completion in browser address bars nor in OS command lines. The syntax
of the language and the properties of objects dramatically reduce the
space of valid entries. Especially completion while stopped on a
breakpoint, where dynamic information can be leveraged.
Exact - that's why I took my main autocomplete model from Visual Studio.
I'm neither a MS basher or lover, I don't want to start a flame war, so
let's just say that for UI design they are usually more right than wrong.
The completion can take advantage of these constraints to make the
input much faster in principle. Whether we can realize this in
practice is not yet shown. There are some difficult cases I have not
yet investigated, like quoted strings, regexp, etc. But I would like
to continue this experiment until we conclude that fast autocompletion
is not practical. In 1.7 I plan to use the autocompletion in the
script panel to edit JS function bodies in running code.
That would be great.
The key examples I am looking for now are cases where autocompletion
causes you to enter something incorrect. I am also interested in
concrete expressions of dislike, such as "The UI flashes too much
while I am typing".
Also to be clear, I'm not against using eg TAB to cause completion
rather than cycling.
tab, up, down to initiate autocomplete mode then for cycling
esc to cancel
enter, dot and other non-word keys to chose the current candidate.
word keys reduce the number of candidates.
Nicolas
jjb
--
You received this message because you are subscribed to the Google Groups
"Firebug" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/firebug?hl=en.
