Re: [Emacs-diffs] comment-cache 223d16f 2/3: Apply `comment-depth' text properties when calling `back_comment'.

[Alan Mackenzie]

Hello, Richard.

On Wed, Mar 09, 2016 at 11:37:52AM -0500, Richard Stallman wrote:
> [[[ 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. ]]]

>   > My changes might speed up back_comment, but that's not the prime reason
>   > for them.  Rather, I want utterly to expunge all the nonsense about
>   > parens in column 0.

> You might think of this rule as a kludgy rough approximation finding
> the defuns in the file.  But it is also a useful way of controlling
> what count as defuns.  For instance,

> (eval-when-compile
> (defun foo ...)

> (defun bar...)
> )

> treats foo and bar as defuns, whereas

> (eval-when-compile
>   (defun foo ...)

>   (defun bar...)
> )

> treats the whole thing as one defun.

Thanks for the tip!

> I always want the former.

I suppose I do, too.

> Without the open-paren-in-column-0 feature, the whole
> eval-when-compile form would have to count as one defun, and the user
> would have no choice about that.

> Thus, before you talk about "fixing" this, would you please
> state what behavior you want to implement?

That moving backwards over comments and strings will do the Right Thing,
even when those literals contain parentheses in column 0.

Currently, problems happen frequently when somebody inadvertantly puts a
paren in C0, usually in a comment, and this wreaks havoc with
indentation and fontification, etc., because (e.g.) CC Mode handles part
of the comment as though it were code.

The latest problem, found and reported by Paul Eggert as bug #22884, was
in a config.h, and a comment near the start, containing the license
statement, started a line with "(at your option)".  The consequence of
this was editing a comment on Line 1661 took ~10 seconds for the edit to
echo.

Just for information, I've already implemented the behaviour, putting it
into a new git branch called "comment-cache".  It is a matter for
testing and experience whether this change will be merged into the
master branch.  The edit that previously took 10s is now instantaneous.

However, open-paren-in-column-0-is-defun-start still exists in this
version, just that the low level syntactic routines no longer need to
use it.  Trying out C-M-a on your eval-when-compile, it still jumps to
the (defun foo ...).  :-)  However, on setting open-paren-...-start to
nil, the C-M-a moved to the (eval-when-compile).

So, yes, it would seem that open-paren-...-start is still useful, and so
should survive.

> If it makes the right thing happen automatically in some cases
> and doesn't make the wrong thing start to happen in other cases,
> it could be an improvement.  But let's see it and verify that.

Well, to me, it's clearly an improvement (I maintain CC Mode).  But I
only committed the new code yesterday, and so far there's been no
feedback from anybody else who's tried it.

So, when I said "expunge all the nonsense about parens in column zero",
let's take it I meant "from the low level syntactic routines".  :-)

> -- 
> Dr Richard Stallman
> President, Free Software Foundation (gnu.org, fsf.org)
> Internet Hall-of-Famer (internethalloffame.org)
> Skype: No way! See stallman.org/skype.html.

-- 
Alan Mackenzie (Nuremberg, Germany).