bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#30393: 24.4; cperl-mode: indentation failure


From: Alan Mackenzie
Subject: bug#30393: 24.4; cperl-mode: indentation failure
Date: Sun, 11 Feb 2018 12:49:30 +0000
User-agent: Mutt/1.7.2 (2016-11-26)

Hello, Eli.

On Sat, Feb 10, 2018 at 14:08:43 +0200, Eli Zaretskii wrote:
> > Date: Sat, 10 Feb 2018 11:26:54 +0000
> > From: Alan Mackenzie <address@hidden>
> > Cc: Noam Postavsky <address@hidden>,
> >     Stefan Monnier <address@hidden>, address@hidden

> > +definition, or defun.  Therefore, in these modes, don't put an opening

> Which "these modes" does this refer to?  How will the reader know when
> to use this convention and when not?

Good point.  I suppose the answer is that there now aren't any such
modes.  Maybe this part of the section should be removed.

> > +  In earlier versions of Emacs (through version 26.n), Emacs exploited
> > +this convention to speed up many low-level operations, which would
> > +otherwise have to scan back to the beginning of the buffer.
> > +Unfortunately, this caused confusion when an opening delimiter
> > +occurred at column zero inside a comment.  The resulting faulty
> > +analysis often caused wrong indentation or fontification.  The
> > +convention could be overridden by setting the user option
> > address@hidden to @code{nil}, but this
> > +slowed Emacs down, particularaly when editing large buffers.
> > +
> > +  To eliminate these problems, the low level functionality which used
> > +to test for opening delimiters at column 0 no longer does so.  Open
> > +delimiters may now be freely written at the left margin inside
> > +comments and strings without triggering these problems.

> This text is not needed.  The original text, which you deleted,
> described how to avoid a real problem; if that problem no longer
> exists, we should just delete that text.  If that problem does exist
> in some modes, we should leave that text as it was, with a better
> description of what modes are still subject to these problems.

> But describing something that is no longer done by Emacs is just waste
> of paper.

Perhaps the proposed fix was somewhat prolix ("long winded").  But, in a
sense, we're providing a new feature, the ability to write syntactically
correct parens.  If we don't mention this, people won't notice.
Occasionally somebody will remember the previous restriction, try to
look it up in the manual, and end up puzzled.

How about a compromise, and replacing those two long paragraphs with a
simple sentence such as:

    From Emacs 27.1, you can write opening parens at column zero without
    problems.

> Overall, I must say I'm confused regarding the purpose of this patch.
> What does it try to accomplish?

To note that the documented previous restrictions on parens in column 0
no longer hold.

I suppose we really want to mark this part of the manual as obsolete,
but we've got no mechanism for doing this.  Besides,
open-paren-in-column-0-is-defun-start still has _some_ functionality.

> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).





reply via email to

[Prev in Thread] Current Thread [Next in Thread]