GNU bug report logs - #26642
25.1; Lisp Mode: open paren at start of line in doc string messes up top level form detection

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 26642 in the body.
You can then email your comments to 26642 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Philipp Matthias Schäfer
 <philipp.matthias.schaefer <at> posteo.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.1; Lisp Mode: open paren at start of line in doc string messes up
 top level form detection
Date: Mon, 24 Apr 2017 20:06:34 +0200

[Message part 1 (text/plain, inline)]

An open parenthesis in the first column of a line that is fully part of
a string within a top level form, causes the top level form detection to
fail.

As an example, consider

(defun foo ()
  "
(bar)"
)

Invoking EVAL-DEFUN on any point between the first and the last
parenthesis of that example, informs me that BAR has a void function
definition. The example also shows the result of automatic indentation
for new lines, which started the last line in column 0 (instead of
column 2).

There is the simple workaround of escaping the open parenthesis in the
string. `git grep -P "^\\\\\("` shows that this workaround is used all
over the place in the Emacs sources.

I would prefer if I would not need to do that.

Digging into the code, one of the culprits for the EVAL-DEFUN problem
seems to be BEGINNING-OF-DEFUN-RAW, which searches backward from point
for the regexp "^\\s(". So, if I am anywhere after the open parenthesis
before bar, the regexp search finds that parenthesis and stops there.

A test whether the resulting point is within a string or not is missing.
A naive solution for this is to count the unescaped double quotes from
the start of the file, while taking comments into account. This would
also be necessary if no other information is available.

However, I have almost no knowledge of how Emacs works internally, hence
there might be information kept somewhere (for syntax highlighting, for
example), that would make this easier.

Apart from reporting this bug, my question is: Is this something that is
worth pursuing further? Or are there very clear reasons against solving
this problem that are obvious to someone with sufficient experience?

Cheers,

Philipp

[signature.asc (application/pgp-signature, attachment)]

Message #8 received at 26642 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Philipp Matthias Schäfer
 <philipp.matthias.schaefer <at> posteo.de>
Cc: 26642 <at> debbugs.gnu.org
Subject: Re: bug#26642: 25.1;
 Lisp Mode: open paren at start of line in doc string messes up top
 level form detection
Date: Tue, 25 Apr 2017 13:08:24 -0400

The is the long-standing "open paren in column zero" issue.
Searching should find several previous discussions.

Message #11 received at 26642 <at> debbugs.gnu.org (full text, mbox):

From: John Mastro <john.b.mastro <at> gmail.com>
To: Philipp Matthias Schäfer
 <philipp.matthias.schaefer <at> posteo.de>
Cc: 26642 <at> debbugs.gnu.org
Subject: Re: bug#26642: 25.1; Lisp Mode: open paren at start of line in doc
 string messes up top level form detection
Date: Tue, 25 Apr 2017 10:30:06 -0700

Glenn Morris <rgm <at> gnu.org> wrote:
> The is the long-standing "open paren in column zero" issue.
> Searching should find several previous discussions.

You can get the behavior you want by setting the variable
`open-paren-in-column-0-is-defun-start' to nil.

        John

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.