From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juri Linkov 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:23:11 +0300 Organization: LINKOV.NET Message-ID: <878u96yl2o.fsf@mail.linkov.net> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1440117013 30689 80.91.229.3 (21 Aug 2015 00:30:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 21 Aug 2015 00:30:13 +0000 (UTC) Cc: Eli Zaretskii , Stefan Monnier , emacs-devel@gnu.org To: Kaushal Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 21 02:30:05 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 1ZSaDc-0005h5-6L for ged-emacs-devel@m.gmane.org; Fri, 21 Aug 2015 02:30:04 +0200 Original-Received: from localhost ([::1]:50551 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZSBqY-0000IY-CQ for ged-emacs-devel@m.gmane.org; Wed, 19 Aug 2015 18:28:38 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35646) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZSBqN-0000BW-5c for emacs-devel@gnu.org; Wed, 19 Aug 2015 18:28:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZSBqM-0007CK-7F for emacs-devel@gnu.org; Wed, 19 Aug 2015 18:28:27 -0400 Original-Received: from sub3.mail.dreamhost.com ([69.163.253.7]:54505 helo=homiemail-a22.g.dreamhost.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZSBqH-0007Bk-Eb; Wed, 19 Aug 2015 18:28:21 -0400 Original-Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id E74921A8069; Wed, 19 Aug 2015 15:28:19 -0700 (PDT) Original-Received: from localhost.linkov.net (m212-53-116-166.cust.tele2.ee [212.53.116.166]) (Authenticated sender: jurta@jurta.org) by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPA id 820381A8063; Wed, 19 Aug 2015 15:28:18 -0700 (PDT) In-Reply-To: (Kaushal's message of "Tue, 18 Aug 2015 16:22:05 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (x86_64-pc-linux-gnu) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 69.163.253.7 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:188993 Archived-At: > @Juri So what did you think? Stefan says, it is not worth it, if it is not breaking third-party packag= es. > 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 e= macs >> version, the final step to unbind those "C-x w" bindings will remain. >> >> On Thu, Jul 30, 2015 at 6:48 PM Stefan Monnier >> 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