From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: emacs rendering comparisson between emacs23 and emacs26.3 Date: Mon, 6 Apr 2020 12:14:49 +0000 Message-ID: <20200406121449.GB7100@ACM> References: <83k12zz6ds.fsf@gnu.org> <054393f3-3873-ab6e-b325-0eca354d8838@gmx.at> <20200403174757.GA8266@ACM> <20200405111623.GB5049@ACM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="82923"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rudalics@gmx.at, eliz@gnu.org, rrandresf@gmail.com, emacs-devel@gnu.org To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Apr 06 14:15:41 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jLQfF-000LRW-6d for ged-emacs-devel@m.gmane-mx.org; Mon, 06 Apr 2020 14:15:41 +0200 Original-Received: from localhost ([::1]:59484 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jLQfE-0005V6-7b for ged-emacs-devel@m.gmane-mx.org; Mon, 06 Apr 2020 08:15:40 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39066) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jLQeV-0004SR-Ig for emacs-devel@gnu.org; Mon, 06 Apr 2020 08:14:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jLQeU-0005vk-0A for emacs-devel@gnu.org; Mon, 06 Apr 2020 08:14:55 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:51252 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1jLQeS-0005uA-Jm for emacs-devel@gnu.org; Mon, 06 Apr 2020 08:14:53 -0400 Original-Received: (qmail 84625 invoked by uid 3782); 6 Apr 2020 12:14:50 -0000 Original-Received: from acm.muc.de (p4FE15D4F.dip0.t-ipconnect.de [79.225.93.79]) by localhost.muc.de (tmda-ofmipd) with ESMTP; Mon, 06 Apr 2020 14:14:49 +0200 Original-Received: (qmail 8268 invoked by uid 1000); 6 Apr 2020 12:14:49 -0000 Content-Disposition: inline In-Reply-To: X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:246515 Archived-At: Hello, Richard. On Sun, Apr 05, 2020 at 22:36:22 -0400, Richard Stallman wrote: > [[[ To any NSA and FBI agents reading my email: please consider ]]] > [[[ whether defending the US Constitution against all enemies, ]]] > [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > > > This assumption proved to be very problematic. > > > Problematic for whom? > > Well, for me for a start. > If it causes a problem only for you personally as a maintainer, I am > sure we could find a way to spare you from spending time on this. But > we are miscommunicating completely. > I assumed you meant "problematically for some people who are doing > some kinds of things with Emacs", and I would like to know what kinds > of things they are. The answer that is crucial for deciding whether > this problem ought to have been "fixed" or not. Yes, that is what I meant. The "kind of things" is nothing more than writing comments in C (etc.) source code. Sooner or later, such a comment has a parenthesis in it, and sooner or later (e.g. by M-q), this will end up in column 0, when (as is often the case) the user has no " *" comment prefix. > > Suppose open-paren-in-column-0-is-defun-start is non-nil, and we have > > something like: > > { > > /* foo > > (but bar > > */ > > } > > ^ > > point > Now I see the scenario. Indeed, with > open-paren-in-column-0-is-defun-start non-nil, some users would regard > the resulting behavior as a problem. [ Please do M-: (setq comment-use-syntax-ppss nil) to reenable o-p-i-c-0-i-d-s's action. ] I think "some" is an understatement. With show-paren-mode enabled, and with point after the }, it visibly mismatches the ( rather than matching the {. If this was all that happened, it might not be too bad. But (forward-comment -1) fails on such a beast. scan-lists (backwards) fails, too. We're talking about low level Emacs primitives being buggy. This is surely worse than higher level functions being buggy. > I do not see how this constitutes a reason to deliminate that option. > Why is that better than the obvious response: to tell the user, > Either delate that open-paren, or indent it, or set > open-paren-in-column-0-is-defun-start to nil. Because it is highly non-trivial to detect this happening in the code. To insert code to detect this would cause a slow down, likely a big slow down. > Does someone want to present an argument leading to the conclusion > that it was better to deactivate that variable? This has, I think, been much discussed on this list in years past. I actually implemented a solution whereby comments and strings would have been marked by a text property in forward scanning, and back_comment would merely examine that property. This scheme wasn't accepted for Emacs, and it would have suffered the same from needing large scale scanning. My position at the moment is that the o-p-i-c-0-i-d-s mechanism should remain active, but that we should fix the bugs in it such that the backward scanning would only stop at a column-0 paren not in a comment or string. I outlined one way of doing this in the thread called "A proposal for the future of open-paren-in-column-0-is-defun-start", but nobody has responded to the thrust of this post at all, as yet. > > I think I meant that, given their validity, it is up to us as Emacs > > developers to arrange that they don't cause trouble, rather than > > expecting our users to insert these obtrusive backslashes. > Why assume that the one recommended way to edit the buffer to avoid > the confusion is inserting a backslash? This was the recommendation which used to be in the Emacs manual. (I think I took it out.) When bug #22884 hit, Paul Eggert "solved" it by refilling the copyright text such that the paren wasn't in column 0 anymore. > -- > Dr Richard Stallman > Chief GNUisance of the GNU Project (https://gnu.org) > Founder, Free Software Foundation (https://fsf.org) > Internet Hall-of-Famer (https://internethalloffame.org) -- Alan Mackenzie (Nuremberg, Germany).