From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kaushal Newsgroups: gmane.emacs.devel 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 Message-ID: References: <874mlaearx.fsf@mail.linkov.net> <55A21229.6080903@gmail.com> <55A27E53.7020605@gmail.com> <834ml99zkp.fsf@gnu.org> <831tgd9wcm.fsf@gnu.org> <55AB58FB.8000501@gmail.com> <87r3nqk34p.fsf@mail.linkov.net> <878u96yl2o.fsf@mail.linkov.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b33d95228bdc1051db3cdb9 X-Trace: ger.gmane.org 1440098761 6634 80.91.229.3 (20 Aug 2015 19:26:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 20 Aug 2015 19:26:01 +0000 (UTC) Cc: Eli Zaretskii , Stefan Monnier , emacs-devel@gnu.org To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 20 21:26:01 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZSVTL-0005hK-Sm for ged-emacs-devel@m.gmane.org; Thu, 20 Aug 2015 21:26:00 +0200 Original-Received: from localhost ([::1]:50463 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZSEMv-0000fy-IC for ged-emacs-devel@m.gmane.org; Wed, 19 Aug 2015 21:10:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41234) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZSEM9-0000cO-LN for emacs-devel@gnu.org; Wed, 19 Aug 2015 21:09:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZSEM8-0000ry-7d for emacs-devel@gnu.org; Wed, 19 Aug 2015 21:09:25 -0400 Original-Received: from mail-ob0-x233.google.com ([2607:f8b0:4003:c01::233]:36711) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZSEM6-0000qe-BN; Wed, 19 Aug 2015 21:09:22 -0400 Original-Received: by obkg7 with SMTP id g7so19698361obk.3; Wed, 19 Aug 2015 18:09:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=SQL+2wm9nj4q1TO4YPxLL2eOWxyRby2T0MTzHsK7Vk8=; b=L07szVk7+4RIoEokrzYsdxFuOljR9abg6Gy9ap2xtHx5cXbokWt2DHfI+2M7bXeEwO gPfRJzVCMl8rZz5Lnnp+bZikJzRDPXwDHyeKuyzBPx9FF+VR9HJ6vdBpwOuHdCYhQedS 3vgLxUenhzgijM4SRkwii6r6hinCxXmfPUuIV5Is1dI8wIPd/L41NbqCUq5CL7JNrCJK UUrpJqE6crqhtKSqwCfl/C6FwednR15wH1uno9b2xSSVkylPbrCaDgpACNIk+D3mPfQd cBzcGyuicJXT3KDWTh+kZmCWKxgfC806RbcjnyxWcu14uTyhFtLi4S9yVP1aK/jOx/y4 W5RQ== X-Received: by 10.60.93.99 with SMTP id ct3mr411194oeb.56.1440032961901; Wed, 19 Aug 2015 18:09:21 -0700 (PDT) In-Reply-To: <878u96yl2o.fsf@mail.linkov.net> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4003:c01::233 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:188975 Archived-At: --047d7b33d95228bdc1051db3cdb9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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. Thanks. On Wed, Aug 19, 2015 at 6:28 PM Juri Linkov 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 wrote: > >> I thought quite some bit on how we can add in a warning for key bindin= g > >> change. But as Stefan says, it is probably not worth it. > >> > >> First of, we would need to create a wrapper function or a wrapper macr= o > to > >> create wrapper functions for all the commands that we want to phase ou= t > >> from being bound with the "C-x w" prefix map. The wrapper function wil= l > >> 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 < > monnier@iro.umontreal.ca> > >> 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 =E2=80=9Cuse the new key instead=E2=80=9D like we do= with > >>> > =E2=80=98define-obsolete-function-alias=E2=80=99 and =E2=80=98make-= obsolete-variable=E2=80=99? > >>> > >>> No, for key-bindings we just make the change, since we don't pay near= ly > >>> as much attention to breaking "user compatibility" (which can be fixe= d > >>> with a define-key in ~/.emacs). > >>> OTOH if the change ends up breaking third-party packages it might be > >>> more problematic. > >>> > >>> > >>> Stefan > --047d7b33d95228bdc1051db3cdb9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Great! Then should the patch be applied? I haven't hea= rd from anyone that this change will break a 3rd party package.

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

Thanks.

= On Wed, Aug 19, 2015 at 6:28 PM Juri Linkov <juri@linkov.net> 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 <kaushal.modi@gmail.com> wrote:
>> I thought quite some bit on how we can add in a warning for key bi= nding
>> 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 phas= e out
>> from being bound with the "C-x w" prefix map. The wrappe= r 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" pr= efix 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 <monnier@iro.umontreal.ca= >
>> wrote:
>>
>>> > Do we have a 2-step deprecation process where the first s= tep
>>> > is to warn the users about the planned changes by issuing=
>>> > a message like =E2=80=9Cuse the new key instead=E2=80=9D = like we do with
>>> > =E2=80=98define-obsolete-function-alias=E2=80=99 and =E2= =80=98make-obsolete-variable=E2=80=99?
>>>
>>> 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 mi= ght be
>>> more problematic.
>>>
>>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Stefan
--047d7b33d95228bdc1051db3cdb9--