From: Alan Mackenzie <acm@muc.de>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 30393@debbugs.gnu.org, dgutov@yandex.ru,
monnier@IRO.UMontreal.CA, npostavs@users.sourceforge.net
Subject: bug#30393: 24.4; cperl-mode: indentation failure
Date: Sun, 11 Feb 2018 12:49:30 +0000 [thread overview]
Message-ID: <20180211124930.GB4515@ACM> (raw)
In-Reply-To: <8360752gj8.fsf@gnu.org>
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 <acm@muc.de>
> > Cc: Noam Postavsky <npostavs@users.sourceforge.net>,
> > Stefan Monnier <monnier@IRO.UMontreal.CA>, 30393@debbugs.gnu.org
> > +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
> > +@code{open-paren-in-column-0-is-defun-start} 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).
next prev parent reply other threads:[~2018-02-11 12:49 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-08 15:25 bug#30393: 24.4; cperl-mode: indentation failure paulusm
2018-02-09 1:44 ` Noam Postavsky
[not found] ` <mailman.8766.1518140709.27995.bug-gnu-emacs@gnu.org>
2018-02-09 17:50 ` Alan Mackenzie
2018-02-10 3:55 ` Noam Postavsky
2018-02-10 8:53 ` Dmitry Gutov
2018-02-10 11:26 ` Alan Mackenzie
2018-02-10 12:08 ` Eli Zaretskii
2018-02-11 12:49 ` Alan Mackenzie [this message]
2018-02-11 16:16 ` Eli Zaretskii
2018-02-14 21:00 ` Alan Mackenzie
2018-02-15 17:39 ` Eli Zaretskii
2018-02-16 11:52 ` Dmitry Gutov
2018-02-16 17:43 ` Alan Mackenzie
2018-02-17 2:16 ` Dmitry Gutov
2018-02-17 10:54 ` Alan Mackenzie
2018-02-10 14:58 ` Stefan Monnier
2018-02-11 10:36 ` Alan Mackenzie
2018-02-11 22:53 ` Stefan Monnier
2018-02-12 18:38 ` Alan Mackenzie
2018-02-12 20:45 ` Stefan Monnier
2018-03-05 8:42 ` Alan Mackenzie
2018-03-05 16:14 ` Eli Zaretskii
2018-03-06 18:09 ` Alan Mackenzie
2018-04-08 10:52 ` Alan Mackenzie
2018-04-09 18:41 ` Eli Zaretskii
2018-04-10 17:31 ` Alan Mackenzie
2018-04-16 19:21 ` bug#30393: 24.4; cperl-mode: indentation failure - Documentation enhancements Alan Mackenzie
2018-04-19 7:52 ` Eli Zaretskii
2020-08-22 16:07 ` Lars Ingebrigtsen
2020-11-03 13:45 ` bug#30393: [PATCH] Add a test to verify that the bug is gone (and a fix for Emacs 26) Harald Jörg
2020-11-03 14:29 ` Lars Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180211124930.GB4515@ACM \
--to=acm@muc.de \
--cc=30393@debbugs.gnu.org \
--cc=dgutov@yandex.ru \
--cc=eliz@gnu.org \
--cc=monnier@IRO.UMontreal.CA \
--cc=npostavs@users.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.