Re: Saving minibuffer history

[Stefan Monnier]

>> 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.

OK, I'll revert that part as well, then.  Thanks for the explanation.

>> >> 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.

It is.

>> 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.

OK, so it's done for performance reason, on the assumption that encoding
with no-conversion is significantly faster than with utf-8.  Thanks.

>> 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?

I don't think so: they won't be saved at all.  Notice also that
the variable savehist-all-history-variables is also saved along with the
actual history variables.


        Stefan