emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: VOTE: Changing completions-common-part face's default


From: Eli Zaretskii
Subject: Re: VOTE: Changing completions-common-part face's default
Date: Sat, 09 Nov 2019 14:04:43 +0200

> From: João Távora <address@hidden>
> Date: Sat, 9 Nov 2019 11:42:31 +0000
> Cc: Dmitry Gutov <address@hidden>, Stefan Monnier <address@hidden>, 
>       Drew Adams <address@hidden>, emacs-devel <address@hidden>
> 
> > It is OK to have special needs,
> 
> I could just as well illustrate your use 'prefix'
> need-to-see-the-first-difference case as a special need.

You could, but since that's how Emacs worked for the last 11 years, I
don't see how such a claim would stand.

> "special" in contrast to what I would suppose is the "norm"
> is not very useful here, especially when applied to a new
> feature. My position is that your argument is weak also
> because you don't have enough first-hand knowledge to
> talk about special needs __in the "flex" context__

I tried that with different styles, including flex, and I still don't
agree with you about the need to reverse the emphasis.  So what you
think must be the default at least for me doesn't sound 100% correct,
as I find flex very usable for me with the current method of emphasis.

> I gave my example as a data point. Take my word that it affects
> more people that I work with. SLIME's authors must also felt
> the "special need" back in 2006.  Probably all the authors/users
> of every other flex system in the world also feel that "special
> need" (though, they are using other editors and have stated your
> don't value their opinion much -- contrary to me.).

I'm sorry, but that's not how defaults in Emacs change, not because
you give me your word or describe what other applications do.  Not
when the proposed behavior is in such stark contrast to what we've
been doing for years.  We first introduce such a new feature as
optional, and later change it to be the default based on user reports
and complaints.  I suggest to do the same in this case.



reply via email to

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