From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: A problem with old bugs Date: Wed, 08 Mar 2017 18:08:38 +0200 Message-ID: <83d1drhhtl.fsf@gnu.org> References: <87r32h9zj4.fsf@jane> <83h93dnf9h.fsf@gnu.org> <87k28162aa.fsf@jane> <83lgshghe1.fsf@gnu.org> <874lz45k12.fsf@jane> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1488989404 17531 195.159.176.226 (8 Mar 2017 16:10:04 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 8 Mar 2017 16:10:04 +0000 (UTC) Cc: emacs-devel@gnu.org To: Marcin Borkowski Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 08 17:09:55 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cle9y-0003MU-4Z for ged-emacs-devel@m.gmane.org; Wed, 08 Mar 2017 17:09:54 +0100 Original-Received: from localhost ([::1]:57148 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cleA2-00049b-JR for ged-emacs-devel@m.gmane.org; Wed, 08 Mar 2017 11:09:58 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39392) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cle9F-00041Z-Tz for emacs-devel@gnu.org; Wed, 08 Mar 2017 11:09:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cle9B-0005d7-0U for emacs-devel@gnu.org; Wed, 08 Mar 2017 11:09:09 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:59276) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cle9A-0005d3-TQ; Wed, 08 Mar 2017 11:09:04 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1329 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cle9A-0005De-5o; Wed, 08 Mar 2017 11:09:04 -0500 In-reply-to: <874lz45k12.fsf@jane> (message from Marcin Borkowski on Wed, 08 Mar 2017 08:01:45 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:212840 Archived-At: > From: Marcin Borkowski > Cc: emacs-devel@gnu.org > Date: Wed, 08 Mar 2017 08:01:45 +0100 > > > > I replied to the 2 bug reports, let's hope we will get the ball > > rolling again on them. > > OK, I'll try to make a few final modifications and push them. Thanks. > > As for the patch posted here, I think it makes sense to make such > > changes only if they are done in all modes. Doing that only in one > > major mode will only confuse people. So if you'd like to pursue this > > change (and I do think it would be a good change), please make the > > change in a way that will produce similar behavior in all the other > > modes with define their beginning-of-defun functionality. > > I am not sure whether I understand. The problem was specifically with > lisp version of `beginning-of-defun'. With other modes, there is a bit of > a mess: some modes set `beginning-of-defun-function' (e.g. js-mode and > js2-mode), some rebind C-M-a to their beginning-of-defun (e.g. c-mode). > Now, other modes (again, I used c-mode and js2-mode for reference) do > various things when arg=0 for beginning-of-defun - e.g. c-mode claims to > go back to the current defun's header, js2-mode just pretends that arg > is 1 etc. I tried in Lisp and in C, and they both go up one line. > Unifying that (1) might not be the best idea and (2) would require quite > a lot of work for all Emacs built-in modes. But if we do that only in Lisp, we just increase the mess, don't we? I might be okay with fixing only a few popular modes, because that will make the mess smaller, so it will be a step in the right direction, even if we don't go all the way. > I could try to do that, but this would take a bit. Also, I do not know > many of the languages involved, and I'd prefer not to touch their > modes. I don't expect you to need to know these languages, as beginning-of-defun should already be well defined for them.