bug#22884: 25.0.92; C/l mode editing takes waaaayy too long

[Alan Mackenzie <acm@muc.de>]

Hello, Paul.

On Fri, Mar 04, 2016 at 12:32:06PM -0800, Paul Eggert wrote:
> Alan Mackenzie wrote:
> > I have had an idea for fixing Emacs so that we don't have this problem
> > with parens in column 0.  That is only to scan comments in the forward
> > direction, and to mark them with text properties.  `back_comment' will
> > then be little more than checking these text properties are up to date,
> > and then doing a backward text property search.

> Would this mean we no longer need to put \( into Elisp doc strings too? It has 
> always been annoying that we have to do that.

> If it's practical to fold your idea into the emacs-25 branch it sounds like 
> it'll solve the problem. If it's safer to put such a change into the master 
> branch, I can install the patch I already wrote into the emacs-25 branch, as a 
> stopgap. What do you think?

OK, I've hacked this out and committed it to the new branch
"comment-cache", branched off of master.

To use it, (setq comment-cacheing-flag t), and enjoy!  The old
`back_comment' is still in syntax.c, renamed to `old_back_comment', and
it is used when that flag is left at nil.

There should no longer be any restrictions about open parentheses in
column 0, neither in comments nor in strings.
open-paren-in-column-0-is-defun-start should now be a relic (although it
still appears in some lisp files).

At the moment, the code only uses the cached information (on the
`comment-depth' text property) for moving backwards over comments.  It
could be enhanced also to use this information for moving back over
strings, or moving forward over comments and strings, but this is more
of an optimisation than new functionality, and I'm not convinced the
saving would be all that much.  (At the end of any such move, the
variables `from' and `from_byte' are out of synch, and a CHAR_TO_BYTE
invocation is necessary.  I don't know how slow or fast this is.)

As I've said already, the new scheme comes with one or two minor
restrictions: any Lisp code which chnages the syntax table in a way
which affects how literals are handled needs also to call
`trim-comment-cache' to invalidate the cache.  The same applies to
anybody tweaking the `syntax-table' property of a symbol which is the
value of a `category' text property.  CC Mode does the latter
extensively, and I'll need to prepare a version which doesn't do this.

At the moment, the code hasn't yet been tested with nestable comments,
or `category' text properties.  Can you recommend me a major mode with
nestable comments?  I haven't really tested it for narrowing, either, or
anything like indirect buffers.  

I'm not convinced by the names I've chosen for all the new functions and
variables, and I think I ought to rename "comment-cache" to
"literal-cache", and likewise for all the rest.

Some amendment of the Elisp manual will be needed to document the new
minor restrictions.

I look forward to your comments!

-- 
Alan Mackenzie (Nuremberg, Germany).