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

[Philipp Matthias Schäfer]

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
Description: OpenPGP digital signature