all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Lennart Borgman <lennart.borgman@gmail.com>
To: Alan Mackenzie <acm@muc.de>
Cc: emacs-devel@gnu.org
Subject: Re: C Mode: acceleration in brace deserts.
Date: Fri, 4 Dec 2009 11:34:11 +0100	[thread overview]
Message-ID: <e01d8a50912040234m76173f2cjaecdb54b89a2989@mail.gmail.com> (raw)
In-Reply-To: <e01d8a50912031157n353ab4ob5b8030f994c435a@mail.gmail.com>

Hi again Alan,

On Thu, Dec 3, 2009 at 8:57 PM, Lennart Borgman
<lennart.borgman@gmail.com> wrote:
> Hi Alan,
>
> On Thu, Dec 3, 2009 at 8:39 PM, Alan Mackenzie <acm@muc.de> wrote:
>> Hi, Lennart!
>>
>> The state of this cache is held entirely in the variables (all of them
>> buffer local) initialised thusly:
>>
>> (defun c-state-cache-init ()
>>  (setq c-state-cache nil
>>        c-state-cache-good-pos 1
>>        c-state-nonlit-pos-cache nil
>>        c-state-nonlit-pos-cache-limit 1
>>        c-state-brace-pair-desert nil
>>        c-state-point-min 1
>>        c-state-point-min-lit-type nil
>>        c-state-point-min-lit-start nil
>>        c-state-min-scan-pos 1
>>        c-state-old-cpp-beg nil
>>        c-state-old-cpp-end nil)
>>  (c-state-mark-point-min-literal))
>>
>> , where `c-state-mark-point-min-literal' merely sets 3 variables already
>> named.  I don't honestly see a way MuMaMo could disturb this state by
>> accident.
>
>
> Thanks. Mumamo needs to know because it switches major mode and that
> normally kills buffer local variables.


I have a bit trouble with this. I believe there is a simple solution,
but it requires some low level changes to Emacs. Your changes here
illustrates very well why such a change may be desireable to support
mult major modes.

You are parsing the buffer from the beginning to find a state at a
point (this state is here "in literal or not"). This of course breaks
if there are chunks with different major modes in the buffer.

All parsers naturally behave like this (unless they are not
specifically taught about multi major modes and its implementation).
js2, semantic, font-lock are other examples.

I think the easiest cure for this is to let them just see the parts of
the buffers that are in the programming language they know of at the
moment. (This is perhaps not enough but a good start that covers most
possibilities - and can be used for all parsers.)

This must however be implemented on a low level. All C primitives
reading the buffer must know about it. It is probably in most cases
straightforward to implement it. A level between the buffer reading
primitives and the buffer content is needed.  This hides the parts
that should not be seen.


It is probably possible to support your changes in MuMaMo now, but it
is not easy while it will perhaps break easily instead. I have done
something similar to syntax-ppss. I wish we could have the low level
change instead.




  reply	other threads:[~2009-12-04 10:34 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-03 16:21 C Mode: acceleration in brace deserts Alan Mackenzie
2009-12-03 16:26 ` Lennart Borgman
2009-12-03 16:59   ` Alan Mackenzie
2009-12-03 17:22     ` Lennart Borgman
2009-12-03 19:39       ` Alan Mackenzie
2009-12-03 19:57         ` Lennart Borgman
2009-12-04 10:34           ` Lennart Borgman [this message]
2009-12-04 11:03             ` Lennart Borgman
2009-12-04 11:56               ` Alan Mackenzie
2009-12-04 12:03                 ` Lennart Borgman
2009-12-04 12:18                   ` Lennart Borgman
2009-12-04 13:54             ` Alan Mackenzie
2009-12-04 19:03               ` Lennart Borgman
2009-12-05  2:11                 ` Lennart Borgman
2009-12-05  4:49                   ` Stefan Monnier
2009-12-04  5:31     ` Richard Stallman
2009-12-04 11:37       ` Alan Mackenzie
2009-12-05  6:50         ` Richard Stallman
2009-12-03 17:09 ` 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=e01d8a50912040234m76173f2cjaecdb54b89a2989@mail.gmail.com \
    --to=lennart.borgman@gmail.com \
    --cc=acm@muc.de \
    --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.