From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#63286: 30.0.50; CC Mode: New `c-for-clauses-as-arglist' style variable Date: Tue, 9 May 2023 15:11:00 +0000 Message-ID: References: <1769719.uSAL7GYomB@ravel> <2122918.kWKFG3mEot@ravel> <1769415.c5zRbCDrAu@ravel> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35627"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 63286@debbugs.gnu.org, acm@muc.de To: Olivier Certner Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue May 09 17:12:40 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1pwP15-00097z-8v for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 09 May 2023 17:12:39 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pwP0X-0002qG-23; Tue, 09 May 2023 11:12:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pwP0U-0002q8-Ga for bug-gnu-emacs@gnu.org; Tue, 09 May 2023 11:12:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pwP0U-0006d3-8W for bug-gnu-emacs@gnu.org; Tue, 09 May 2023 11:12:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pwP0U-0004Gd-4J for bug-gnu-emacs@gnu.org; Tue, 09 May 2023 11:12:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 09 May 2023 15:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63286 X-GNU-PR-Package: emacs Original-Received: via spool by 63286-submit@debbugs.gnu.org id=B63286.168364507216336 (code B ref 63286); Tue, 09 May 2023 15:12:02 +0000 Original-Received: (at 63286) by debbugs.gnu.org; 9 May 2023 15:11:12 +0000 Original-Received: from localhost ([127.0.0.1]:44144 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pwOzf-0004FP-EH for submit@debbugs.gnu.org; Tue, 09 May 2023 11:11:12 -0400 Original-Received: from mx3.muc.de ([193.149.48.5]:22282) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pwOzb-0004Eo-OA for 63286@debbugs.gnu.org; Tue, 09 May 2023 11:11:10 -0400 Original-Received: (qmail 59172 invoked by uid 3782); 9 May 2023 17:11:01 +0200 Original-Received: from acm.muc.de (pd953a602.dip0.t-ipconnect.de [217.83.166.2]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 09 May 2023 17:11:00 +0200 Original-Received: (qmail 9528 invoked by uid 1000); 9 May 2023 15:11:00 -0000 Content-Disposition: inline In-Reply-To: <1769415.c5zRbCDrAu@ravel> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:261419 Archived-At: Hello, Olivier. On Tue, May 09, 2023 at 12:08:55 +0200, Olivier Certner wrote: [ .... ] > Elegance in this matter, at least in my book, is reaching objectives with the > minimal amounts of code at the right place(s) while preserving or enhancing > the design (that's perhaps a reductive definition, but it is enough for the > current discussion). The part of the design that your patch would disrupt would be the principle of the two stage indentation. The first stage determines the syntactic context, and the second stage indents it according to the current style. Your patch would put style dependent things into the first stage. [ .... ] > > The style variables are intended for widely used features in CC Mode. > I'm generally skeptical on most popularity contexts since they are usually > biased, either statistically or conceptually. But I'll contribute an > additional data point: I certainly did not have to use any of them in 20+ > years until recently, except for `c-basic-offset' and `c-offsets-alist' of > course. If you're stating a policy, then I don't think it is written anywhere > in the doc or in code comments. And I think the current situation may just be > proof of its non-existence. If it's a new one, than I hope I can convince you > it shouldn't apply in this case. You will have used style variables implicitly in constructing your own styles. They are central to the entire style mechanism. And yes, there are lots of conventions in CC Mode (and indeed in Emacs as a whole) which are implicit. There is no maintainers' manual. [ .... ] > > There have been many fixes made to indentation over the years, and > > if even just a few of these involved adding new style variables, the > > style system would be more confusing and less usable that it is. > There are changes and changes. I would not be surprised that most > don't call for a new style variable. This is simply not the case > here. The current problem isn't materially different from all the other indentation problems in years past. [ .... ] > I know the manual in and out, and the code realizing the indentation very > well. I've also written a bunch of non-trivial lineup functions (comparable > to some bundled in `cc-align.el') and I'm already using the excellent > combining facilities provided by offset lists. > And with that knowledge, I have to disagree. Writing lineup functions is not > easy, it can be tedious and messy, even if in the end the code doesn't need to > be very long. That can indeed be the case, but it isn't the case here. Just to press home this point, I threw the following (untested) together in a few minutes. It needs a doc string and probably some comments, but could easily serve as the basis for your new lineup function: (defun c-lineup-KNF-for (langelem) (save-excursion (goto-char (c-langelem-pos langelem)) (when (or (looking-at "\\\\([^_]\\|$\\)") (and (or (eq (char-after) ?\() (zerop (c-backward-token-2))) (eq (char-after) ?\() (zerop (c-backward-token-2)) (looking-at "\\\\([^_]\\|$\\)"))) (vector (+ (current-column) c-basic-offset))))) .. Forgive me pointing out that your proposed patch, by contrast, is over 100 lines long. > Because of a certain lack of coherency in how syntactic contexts are > built (and lack of sufficient documentation for that process), it is > indeed easy to forget cases, which only appear later when indenting > some new or yet unexplored code. Sure, you can write lineups very > quickly for toy examples, but this is not what I'm aiming at (and > you're now aware of the larger context). Yes, when coding, you've got to take care. This is true even for the "simplest" of tasks. > I don't claim to have years of experience with the internals of CC mode and > lineups, contrary to you. Yet, in addition to what I already exposed, I've > carefully analyzed a large part of CC Mode code in the past days (I've not > counted, but based on the number of files and their size, very roughly between > 30 and 50% of the code base), that's also why I'm confidently making these > statements. I might be wrong. On the other hand, I'm also beginning to > wonder if your ~20-year maintainership of CC Mode is simply biasing you on the > matter. Indeed, one is either ignorant/inexperienced, or is biased by a long period spent doing something. That is an inescapable conundrum. [ .... ] > > No, there have been no other bug reports about this in the last 20 years > > or so, at least. Yours is the first one. > Then at least there won't be things repeated. But this gives me even > more responsibility, speaking up for all those that didn't voice their > concern. Which, now that I vaguely recall, probably included me over > 20 years ago in a very different context. If such other programmers actually exist. > And, again, I know of no C editor behaving the same as Emacs+CC Mode on `for' > clauses, and certainly not the popular ones (but I also do not know all of > them, and have not used some for years; please someone point out to those that > would do). Emacs has been at the forefront of editor development for nearly 50 years. In many respects, other editors have caught up, but not in all respects. ;-) [ .... ] > > I think there are rather _several_ different situations rather than many. > You're playing on words but I think you've got the idea. The main point is > that this complexity is unnecessary. Still, you're underestimating the number > of corner cases. I don't think I am underestimating them, having tended to lineup functions many times before. > > I don't foresee the troubles that you do. By the time the lineup > > function comes to be run, things like extra parenthesised expressions > > have already been analysed by the indentation engine. The anchor > > positions allow one readily to find the opening parenthesis and the > > preceding `for' token, or determine that they don't exist in the current > > case. > Not only I foresee them, but I've already experienced some of them. Which brings me back to a question I asked earlier, and I don't think you answered: Have you already tried to implement the indentation you want using, e.g., lineup functions? If so, where did that try hit problems? [ .... ] > Adding only a few new tests is more than enough, because there is provably no > change at all if the variable is not explicitly set and because changes are > confined to `for' clauses only. There would be substantial changes to the large nested cond form which constitutes c-guess-basic-syntax. The pertinent topic of what happens to those occurences which would no longer trigger CASE 7D hasn't even come up for discussion, yet. > How does this "complicate" the suite? If adding a few tests is a > problem, then the test suite is the problem. Addendum: I cannot find > anything in the source tree but a mere 'cc-mode- tests.el' that is 111 > lines long (including comments). Where is the "suite" you're talking > about? In the upstream project at SourceForge, see https://cc-mode.sourceforge.net/hgaccess.php. > Even if you want to be comprehensive, on this precise change there's not much > more to document than what is already in the patch. Of course, a lot should > be added to explain all the special cases of the engine, but this is > independent from this report. Again, you're talking about "substantial > changes in the documentation", but you don't mention what you have in mind. I have in mind the doc changes in your proposed patch. I haven't even started considering to what extent they would be needed, or need expanding upon. > Finally, as for "fragmentation" or threat to "cohesiveness", I'm sorry to have > to say that I have yet to read a single precise and relevant argument that can > really back this point of view. Well, I've tried to explain this over several posts here. I'm sorry I've not succeeded. Maybe the subject of restricting the two parts of indentation to their current separate functionalities (see above) might have done the trick. > > In short, I don't think the approach you've presented is the right one > > to get the indentation that you need. > Then I'm asking you to step back and then reconsider, because you're most > likely wrong. At the very least, filling the gaps between the vague high- > level principles you stated (and which I generally support) and how the > proposed change actually breaks them, as well as answering my other questions, > would be very welcome. If you're not willing to, then I'm not sure there is > any point in continuing this discussion. For the reasons I've tried to explain, I won't be using your proposed patch. That's just the way things are. Sorry. > Regards. > -- > Olivier Certner -- Alan Mackenzie (Nuremberg, Germany).