all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: emacs-devel@gnu.org, bug-cc-mode@gnu.org
Subject: A possible way for CC Mode to resolve its sluggishness
Date: Fri, 26 Apr 2019 19:30:56 +0000	[thread overview]
Message-ID: <20190426193056.GC4720@ACM> (raw)

Hello Emacs, CC Mode.

In the last few years there's been a continual stream of posts
complaining (always good naturedly) about the sluggishness of CC Mode
during extended buffer change operations, and sometimes even with single
operations (such as typing into a C++ raw string).

Recently, Zhang Haijun, noted that iedit-mode (a mode that performs
simultaneous edits on, say, all occurrences of a variable name
throughout a buffer) didn't work well in C++ Mode, because of the time
taken by its after-change-functions.

The problem is that CC Mode's before/after-change-functions are very
general, and scan the buffer looking for situations which only arise
sporadically.  Things like an open string getting closed, or a > being
inserted which needs to be checked for a template delimiter.  However,
these expensive checks are performed for _every_ buffer change.  Even
doing something like inserting a letter or a digit causes the full range
of tests to be performed.  This is not good.

To improve this, I propose that at a buffer change, simple fast
plausibility checks be performed before the change-functions get run,
and only where something complicated is afoot should (selected)
change-functions be run.  For example, inserting a letter or digit will
only rarely be complicated, inserting a brace or semicolon will usually
be so.

Now to the detailed proposal:
(i) A CC Mode buffer will be partitioned into @dfn{syntactic cells}.
These will be things like a section of code, a comment, a string, a raw
string, a CPP construct ....  Possibly even comment delimiters would
have their own cells.

(ii) Syntactic cells will be implemented by a text property, c-syntax,
whose value will indicate the type of the cell, and possibly an
identifier for it.  Neighbouring cells will always have distinct
c-syntax values.

(iii) On a buffer change which removes characters, we check for things
like:
  o - (beg end) straddling or touching cell borders;
  o - "structural" characters in (beg end) (say a brace or semicolon);
  o - "boundary" characters in (beg end) (say a comment or string
  delimiter);
  o - things happening with backslashes, etc.
If any of these things is true, we run the before-change-functions (or a
subset of them).  This will only happen every now and then.  When it
does, we will likely adjust the syntactic cells.

(iv) When a buffer change inserts characters, we check basically the
same things as in (iii) and if needed, run (a subset of) the
after-change-functions.  This also will only happen now and then, and
will like necessitate adjustment of the syntactic cells.

It will probably be possible to eliminate one or more existing CC Mode
structural caches - the speed of text property search (compared with
parse-partial-sexp from a cached "safe" position) will make this
possible.

Thoughts?

-- 
Alan Mackenzie (Nuremberg, Germany).



             reply	other threads:[~2019-04-26 19:30 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-26 19:30 Alan Mackenzie [this message]
2019-04-26 19:53 ` A possible way for CC Mode to resolve its sluggishness Eli Zaretskii
2019-04-26 20:11   ` Alan Mackenzie
2019-04-27  2:10 ` Stefan Monnier
2019-04-27  3:34   ` Óscar Fuentes
2019-04-27 13:57   ` Alan Mackenzie
2019-04-28 17:32     ` Stephen Leake
2019-04-29  1:46     ` Stefan Monnier
2019-04-29  9:23       ` Alan Mackenzie
2019-04-29 12:19         ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190426193056.GC4720@ACM \
    --to=acm@muc.de \
    --cc=bug-cc-mode@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.