Re: Thinking about changed buffers

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <address@hidden> writes:

> Yes.  But the `set-buffer-file-coding-system' explicitly marks the
> buffer as changed when you set it.  Setting, say,
> `write-region-annotate-functions' does not.

Hm.  Or perhaps including the coding system in the buffer hash is
unnecessary.

I'm just perusing the `set-buffer-modified-p' code and happened onto
this:


  /* 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++);

:-)

I think instead of all this, we could just introduce a new field in the
buffer struct...  er...  explicit_modified_flag_p.  Calling
`(set-buffer-modified-p t)' would just set that, and `buffer-modified-p'
would just return that.

(`(set-buffer-modified-p nil)' would clear it, of course, in addition to
doing everything else it's doing.)

So then we're back to just hashing the buffer contents and (some) text
properties, I think?

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