emacs-devel
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]