Re: Saving minibuffer history

[Hrvoje Niksic]

Stefan Monnier <address@hidden> writes:

> For the case of start-itimer vs run-with-idle-timer, I can see you
> point, so I've "reverted" the change.  For the case of (if
> (coding-system-p 'utf-8) 'utf-8 'iso-2022-8), I think the new code
> is preferable, since the choice is really not dependent on
> differences betwen Emacs and XEmacs but just on the availablility of
> utf-8.

That's true in a way, but it's also the case that under XEmacs the
utf-8 coding system is loaded from an external package.  So it can
happen that it is present in one XEmacs invocation and not in another.
Because of that I made savehist not use utf-8 in XEmacs.

> I put "reverted" in quotes because I still have gotten rid of
> savehist-xemacs and replaced it with (featurep 'xemacs) since this
> form is recognized/optimized by the byte-compiler.

That's fine.

> >> I have one question: what's the point of savehist-no-conversion?
> 
> > The code simply needs to check whether the buffer contents has changed
> > since the last save.  I wanted to checksum the raw buffer data, which
> > 'no-conversion achieves in Emacs, and 'binary in XEmacs.  To make the
> > intentions clear and remove an `if' from the code, I used a defconst.
> 
> So if the buffer contents changed but that change is not reflected
> in the saved file (e.g. the buffer contents has a latin-1 é replaced
> by a latin-9 é, but both get written (in utf-8) as the same
> byte-sequence) you end up uselessly re-saving the exact same file.

That seems like a contrived example.  savehist's buffer contents
consists of lists with new entries pushed at the front -- it never
changes a single character.

Even if such a thing did happen, the file would be uselessly re-saved
exactly once.

> I know it's not an important case, but I'm wondering: why not simply
> use savehist-coding-system?

Because this use has nothing to do with saving to file or any external
representation, it just needs to be fast and do as little as possible.
Remember that this is done off a timer, and this needs to be fast to
not interrupt the user's work.  With large savehist buffers I prefer
to be on the safe side.

> > What is your intended replacement?  If I understand
> > minibuffer-history-variable, it only records the minibuffer
> > history for minibuffer input whose history is not otherwise
> > specified.  Which means that it doesn't record the history of M-x,
> > M-:, C-x C-f, etc.
> 
> minibuffer-history-variable has a default value used for when no
> histvar is specified, indeed, but it is also set by
> read-from-minibuffer to the history variable that should be used.
> So by recording its value in minibuffer-setup-hook I accumulate all
> the histvars that have been seen.

What about those that haven't been seen yet?  Won't they be saved as
nil by savehist-save?