[Top][All Lists]

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

Re: Suggestion to have highlight related bindings consistent between sea

From: Kaushal
Subject: Re: Suggestion to have highlight related bindings consistent between search-map and hi-lock-map
Date: Thu, 20 Aug 2015 01:09:12 +0000

Great! Then should the patch be applied? I haven't heard from anyone that this change will break a 3rd party package.

I don't have commit rights. So either you, Stefan or someone else having the commit rights will have to apply the patch.


On Wed, Aug 19, 2015 at 6:28 PM Juri Linkov <address@hidden> wrote:
> @Juri So what did you think?

Stefan says, it is not worth it, if it is not breaking third-party packages.

> On Thu, Jul 30, 2015 at 9:32 PM Kaushal <address@hidden> wrote:
>> I thought quite some bit on how we can add in a warning for key binding
>> change. But as Stefan says, it is probably not worth it.
>> First of, we would need to create a wrapper function or a wrapper macro to
>> create wrapper functions for all the commands that we want to phase out
>> from being bound with the "C-x w" prefix map. The wrapper function will
>> call the wrapped function and then issue a warning/message in the echo area
>> saying that that function is already bound to "M-s h" prefix and will no
>> longer be bound to "C-x w" prefix in future. After that, in a future emacs
>> version, the final step to unbind those "C-x w" bindings will remain.
>> On Thu, Jul 30, 2015 at 6:48 PM Stefan Monnier <address@hidden>
>> wrote:
>>> > Do we have a 2-step deprecation process where the first step
>>> > is to warn the users about the planned changes by issuing
>>> > a message like “use the new key instead” like we do with
>>> > ‘define-obsolete-function-alias’ and ‘make-obsolete-variable’?
>>> No, for key-bindings we just make the change, since we don't pay nearly
>>> as much attention to breaking "user compatibility" (which can be fixed
>>> with a define-key in ~/.emacs).
>>> OTOH if the change ends up breaking third-party packages it might be
>>> more problematic.
>>>         Stefan

reply via email to

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