From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: emacs rendering comparisson between emacs23 and emacs26.3 Date: Tue, 07 Apr 2020 22:29:27 -0400 Message-ID: References: <83k12zz6ds.fsf@gnu.org> <054393f3-3873-ab6e-b325-0eca354d8838@gmx.at> <20200403174757.GA8266@ACM> <20200405111623.GB5049@ACM> <20200406121449.GB7100@ACM> Reply-To: rms@gnu.org Content-Type: text/plain; charset=Utf-8 Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="6138"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, eliz@gnu.org, rrandresf@gmail.com, emacs-devel@gnu.org, rudalics@gmx.at To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Apr 08 04:30:18 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 1jM0Tp-0001Tl-Nf for ged-emacs-devel@m.gmane-mx.org; Wed, 08 Apr 2020 04:30:17 +0200 Original-Received: from localhost ([::1]:55310 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jM0To-0006qU-Po for ged-emacs-devel@m.gmane-mx.org; Tue, 07 Apr 2020 22:30:16 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43047) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jM0T4-0005ct-5O for emacs-devel@gnu.org; Tue, 07 Apr 2020 22:29:31 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:43367) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1jM0T4-0008MZ-15; Tue, 07 Apr 2020 22:29:30 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1jM0T1-0003f4-LL; Tue, 07 Apr 2020 22:29:27 -0400 In-Reply-To: (message from Stefan Monnier on Mon, 06 Apr 2020 23:26:21 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:246631 Archived-At: [[[ 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. ]]] > > > 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, > > > > I am surprised, because that never happens to me. > Of course that never happens to you: you're the one who introduced the > open-paren-in-column-0 heuristic, so you're clearly biased. Please focus on the issue not on personalities. Anyone can be mistaken, but don't argue that an objective claim is wrong based on who made it. What matters is whether one can get good results from open-paren-in-column-0, good enough to make it usable and useful. I found the open-paren-in-column-0 heuristic satisfactory because in practice I saw that open-parens did not drift into column zero. Other people have said that this does happen to them, and they can't avoid it. They, and I, were using the same editor, with the same heuristic, and getting totally different results. Why is that? Surely that is pertinent. I conjecture it is because of indentation conventions, but if that is not the reason, what is? > > What do you think of such indentation as a solution for this problem. > That presumes you have control over the code (and coding conventions). It presumes that the developers adopt the practice of indenting the text of block comments, or can be persuaded to do so. IF my conjecture is correct, open-paren-in-column-0 is useful for programs where block comments are indented. Is that conjecture correct? How about if we finish comparing notes, and see. If that is how things are, it should be useful to support open-paren-in-column-0-is-defun-start = t rather than make it a no-op. If the code you edit does not indent block comments, you would be happier with open-paren-in-column-0-is-defun-start = nil, but you don't need that feature to be no-op'ed. (I did not start indenting the text of block comments because of the open-paren-in-column-0 heuristic. I did it because that looks nice.) -- 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)