Re: master e8488bcc9c: Avoid having font locking triggering unnecessary auto-saving

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I'm not completely surprised, to be honest.  The handling of MODIFFs is
> surprisingly delicate.  Take a look at the code for
> `Frestore_buffer_modified_p` to get an idea.  Setting MODIFF back to
> a previous value is something I would not recommend.

Hm...

  /* Here we have a problem.  SAVE_MODIFF is used here to encode
     buffer-modified-p (as SAVE_MODIFF<MODIFF) as well as
     recent-auto-save-p (as SAVE_MODIFF<auto_save_modified).  So if we
     modify SAVE_MODIFF to affect one, we may affect the other
     as well.
     E.g. if FLAG is nil we need to set SAVE_MODIFF to MODIFF, but
     if SAVE_MODIFF<auto_save_modified that means we risk changing
     recent-auto-save-p from t to nil.
     Vice versa, if FLAG is non-nil and SAVE_MODIFF>=auto_save_modified
     we risk changing recent-auto-save-p from nil to t.  */
  SAVE_MODIFF = (NILP (flag)
                 /* FIXME: This unavoidably sets recent-auto-save-p to nil.  */
                 ? MODIFF
                 /* Let's try to preserve recent-auto-save-p.  */
                 : SAVE_MODIFF < MODIFF ? SAVE_MODIFF
                 /* If SAVE_MODIFF == auto_save_modified == MODIFF,
                    we can either decrease SAVE_MODIFF and auto_save_modified
                    or increase MODIFF.  */
                 : modiff_incr (&MODIFF));


(Ah, and FLAG isn't documented in the doc string, which perhaps it
should be?)

Well...  would upping auto_save_modified to MODIFF in
with-silent-modifications do the trick instead?  (I mean, if
recent-auto-save-p was already true when the macro was entered.)  I.e.,
reverse which modiff we're twiddling here.

Hm...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no