Re: emacs rendering comparisson between emacs23 and emacs26.3

[Richard Stallman]

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

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

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.

Does someone want to present an argument leading to the conclusion
that it was better to deactivate that variable?

  > 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?


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