emacs-devel
[Top][All Lists]
Advanced

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

Re: Unbalanced change hooks (part 2)


From: Alan Mackenzie
Subject: Re: Unbalanced change hooks (part 2)
Date: Tue, 2 Aug 2016 19:38:35 +0000
User-agent: Mutt/1.5.24 (2015-08-30)

Hello, Eli.

On Tue, Aug 02, 2016 at 09:30:37PM +0300, Eli Zaretskii wrote:
> > Date: Tue, 02 Aug 2016 20:17:35 +0300
> > From: Eli Zaretskii <address@hidden>
> > Cc: address@hidden, address@hidden, address@hidden, address@hidden

> > > Anyhow, it's not just CC Mode.  As already discussed, there are 13 other
> > > files which use before-change-functions, and some of these uses are
> > > going to assume it works as documented, just as CC Mode did.  Sporadic
> > > failures are going to occur in some of these other places, due to those
> > > hook functions sometimes not being called.

> > I will believe that when I see specific bug reports about those other
> > packages.

> Btw, I'm slowly but surely arriving to the conclusion that the
> problems we are discussing can only happen when insert-file-contents
> is called with VISIT and REPLACE non-nil, i.e. when reverting a
> buffer.  Do we have any evidence to the contrary?

As long as C-x C-f on a file changed outside of Emacs is included in
"reverting", then no.

> If we do, can someone show or point to such contradicting evidence?

You haven't said how you reached this conclusion.

I've grepped for calls of the five functions (insert_1_both,
replace_range, del_range_\(1\|byte\|both\)) which have `prepare'
parameters, and noted where the argument is false.  I see 15
occurrences.  They are in callproc.c, coding.c, editfns.c, fileio.c,
fns.c, insdel.c, print.c, and xdisp.c.

Can you persuade me that it wouldn't be a good use of my time to look at
each of these 15 occurrences?  :-)

> If my conclusion is correct, then we should probably focus on this
> particular use case and look for a solution for it, as opposed to
> trying to solve some more general problem that seems not to exist.  It
> might be much easier and simpler.

I hope you're right.

-- 
Alan Mackenzie (Nuremberg, Germany).



reply via email to

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