[Top][All Lists]

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

Re: History for query replace pairs

From: Ted Zlatanov
Subject: Re: History for query replace pairs
Date: Sun, 05 Oct 2014 20:46:32 -0400
User-agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/25.0.50 (gnu/linux)

On Sun, 5 Oct 2014 05:59:34 +0000 (UTC) Tom <address@hidden> wrote: 

T> Ted Zlatanov <tzz <at> lifelogs.com> writes:
>> I'd like to make this part of the Emacs core, disabled by default. Any
>> objections?  I think it's nicer-looking than the current UI.
>> If not, maybe Tom would like to make it a GNU ELPA package?

T> If you put it into the core then it won't be available in this
T> release for users (I guess, because it's new functionality), only
T> in the next one which may be years away.

T> For this reason it may be better if you make an elpa (or melpa)
T> package, because then every user can use it immediately, it can
T> be polished there and it can be moved into the core later when
T> it's matured.

That's true for code that adds functionality, but IMHO code that
improves usability (such as yours) should go into the core for two
reasons: one, it should be usable by everyone; two, it can take
advantage of core improvements without keeping backward compatibility.

This is just my opinion, though.  It's your code and you're free to
submit it to the GNU ELPA or any other archive :)  Just let us know what
you prefer soon so we can move on with it.

On Sun, 05 Oct 2014 02:36:57 +0300 Juri Linkov <address@hidden> wrote: 

JL> I realized right now that the most intuitive and convenient way is
JL> to implement a new general function to read two values in the minibuffer
JL> with two entry fields.  These fields could be like in Widget/Customization 
JL> where the user can switch the entry point between two fields.
JL> Anything between them would be read-only like the current prompt is, e.g.

JL>   Query replace: [from] with: [to]

JL> where [from] and [to] are entry fields.  `M-p' will update these two fields
JL> with the previous values from the history.

That sounds fine, especially if it can be implemented quickly. Otherwise
maybe we should adopt Tom's code now and improve it later. What do you
think? I'll hold off until you and Tom have given your opinions.

Either way, I am excited about this. It will definitely improve the UI


reply via email to

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