emacs-devel
[Top][All Lists]
Advanced

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

Re: (insert ?\n) spuriously calls before-change-functions twice. Help!


From: Alan Mackenzie
Subject: Re: (insert ?\n) spuriously calls before-change-functions twice. Help!
Date: Tue, 5 Jan 2010 17:31:58 +0000
User-agent: Mutt/1.5.9i

Hi, Stefan,

On Tue, Jan 05, 2010 at 10:22:26AM -0500, Stefan Monnier wrote:
> > In emacs -Q, in an AWK buffer, do M-: (insert ?\n).  The following
> [...]
> > However, M-: (insert "\n") just does the Right Thing.

> That's curious indeed.

> > This second invocation of before-change-functions is surely a bug.  I
> > can make this happen in a Fundamental Mode buffer in my normal Emacs
> > session, but not in Emacs -Q.

> Can you try to figure out which diference between "emacs -Q" and your
> "normal Emacs session" triggers the problem?

I think I've tracked down what's happening.  After inserting the ?\n (any
other character is just the same), Emacs clears any text properties from
the new character by calling set_properties.  This, in its turn, invokes
before-change-functions.  A more detailed call stack is:

Finsert calls
  general_insert_function (insert, insert_from_string, 0, nargs, args) calls
    (*insert_func) (str, len), namely insert (str, len), calls
      insert_1_both (string, len, nbytes, 0, 1, 0), calls
        prepare_to_modify_buffer, calls
        signal_before_change.  This does the first invocation of b_c_f. <======

        insert_1_both inserts the character ?\n into the buffer.

        insert_1_both (conditionally on BUF_INTERVALS) calls
          set_text_properties on the newly inserted character, calls
            modify_region, calls
              prepare_to_modify_buffer, calls
                signal_before_change.  This does the second invocation of
                                       b_c_f.    <=============================

There doesn't seem to be any system in where the two change hooks are
invoked.  For example, insert directly calls signal_after_change, yet not
signal_before_change; surely invocations of these should be paired.

I think there needs to be two levels of these primitive: a "user level",
which invokes the change hooks, and calls the "internal level" to do the
actual work.  Other primitives would call only the "internal level".  Or
something like that.

For CC Mode, I will put in a test for two consecutive invocations of
before-change-functions without an after-change-functions between them.
In such a case, I then ignore the second invocation.  I think.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).




reply via email to

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