Re: emacs rendering comparisson between emacs23 and emacs26.3

[Alan Mackenzie]

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).