[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).
- bug#22884: 25.0.92; C/l mode editing takes waaaayy too long, (continued)
- bug#22884: 25.0.92; C/l mode editing takes waaaayy too long, Alan Mackenzie, 2016/03/03
- bug#22884: 25.0.92; C/l mode editing takes waaaayy too long, Eli Zaretskii, 2016/03/03
- bug#22884: 25.0.92; C/l mode editing takes waaaayy too long, Paul Eggert, 2016/03/03
- bug#22884: 25.0.92; C/l mode editing takes waaaayy too long, Alan Mackenzie, 2016/03/04
- bug#22884: 25.0.92; C/l mode editing takes waaaayy too long, Paul Eggert, 2016/03/04
- bug#22884: 25.0.92; C/l mode editing takes waaaayy too long,
Alan Mackenzie <=
- bug#22884: 25.0.92; C/l mode editing takes waaaayy too long, Alan Mackenzie, 2016/03/13
- bug#22884: 25.0.92; C/l mode editing takes waaaayy too long, Alan Mackenzie, 2016/03/08
- bug#22884: 25.0.92; C/l mode editing takes waaaayy too long, Paul Eggert, 2016/03/09
- bug#22884: 25.0.92; C/l mode editing takes waaaayy too long, John Wiegley, 2016/03/09
- bug#22884: 25.0.92; C/l mode editing takes waaaayy too long, Paul Eggert, 2016/03/09
- bug#22884: 25.0.92; C/l mode editing takes waaaayy too long, John Wiegley, 2016/03/09
- bug#22884: 25.0.92; C/l mode editing takes waaaayy too long, Alan Mackenzie, 2016/03/09
- bug#22884: 25.0.92; C/l mode editing takes waaaayy too long, Drew Adams, 2016/03/09
- bug#22884: 25.0.92; C/l mode editing takes waaaayy too long, Alan Mackenzie, 2016/03/09
- bug#22884: 25.0.92; C/l mode editing takes waaaayy too long, Drew Adams, 2016/03/09