[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: File name completion glitch
From: |
David Kastrup |
Subject: |
Re: File name completion glitch |
Date: |
Mon, 16 Mar 2009 12:57:15 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) |
"Drew Adams" <address@hidden> writes:
> Immediate feedback that you hit the wrong key lets you correct the
> typo on the spot. Instead, giving you some inappropriate completion
> (according to unexpected new matching criteria) makes you wonder
> "WTF?!" and then go out of your way to remove the completed text and
> retype what you meant.
C-/ should fix that, right?
> See the URLs below for real examples of such inappropriate
> completions.
>
> I don't deny that some people will find the extra, non-vanilla
> match-trying useful ("_enormously_" or otherwise). But let users who
> do find it so customize option `completion-styles' to add non-vanilla
> matching methods - no big deal. The new feature makes it simple for
> them to do that; why impose it on everyone by default?
Because the default is what people discover. Features that will with a
large likelihood be considered useful by to non-specialists are better
configured on than off by default. Otherwise, most people will not
benefit from them.
Fontlocking was one such feature. The current completion is similar in
my book: I quite like it and would not know off-hand where to go hunting
for it.
> Leave the default behavior as it's always been. But advertise as
> loudly as you like the possibility of customizing `completion-styles'
> to add additional matching methods (e.g. partial-completion) at
> will. That's a reasonable way to introduce something like this.
Except that it does not work.
> After time, if it turns out that most *users* prefer to change the
> behavior to include additional matching methods, we can change the
> default then. At that point, based on experience and user input, we
> can discuss what the best default mix of completion styles might be
> (including styles yet to be defined, no doubt).
I think that particularly in the _pretests_ we should rather err on the
progressive than on the conservative side. _If_ that leads to negative
feedback, we have something to base a decision on. If we have it off by
default in the pretests, there is nothing to guess how people would like
it.
> Richard said, "Please undo this change, poll the users, and redo the
> change if they generally want it."
Pretests are a way to poll.
> I say, please undo this change, and wait to see what the users do and
> think after some time.
They will do and think nothing if they don't get to see the feature.
> What's the hurry? It doesn't take long for a good feature to find its
> way into common practice, especially nowadays.
Only if it is there.
--
David Kastrup