bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alan Mackenzie
Subject: bug#22884: 25.0.92; C/l mode editing takes waaaayy too long
Date: Fri, 4 Mar 2016 21:08:18 +0000
User-agent: Mutt/1.5.24 (2015-08-30)

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.

It would mean this, yes.  open-paren-in-column-0-is-defun-start would
become obsolete.

> 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?

Definitely the master branch.  The change is far too involved to slip
into emacs-25 at this late stage.  So I think you should install your
patch.

The new scheme would come with some restrictions: the use of category
properties to effect instantaeous global changes to syntax-table text
properties throughout a buffer would have to be deprecated (i.e.
forbidden).  CC Mode currently does this.  Setting
`inhibit-modification-hooks' non-nil and making substantive buffer
changes would likewise be taboo.  There may be other minor restrictions.
Because of this, it might be an idea to make the new comment handling
optional (default on).

-- 
Alan Mackenzie (Nuremberg, Germany).





reply via email to

[Prev in Thread] Current Thread [Next in Thread]