[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Saving minibuffer history
From: |
Stefan Monnier |
Subject: |
Re: Saving minibuffer history |
Date: |
Wed, 19 Oct 2005 14:51:44 -0400 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) |
>> 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
- Re: Saving minibuffer history, (continued)
- Re: Saving minibuffer history, Hrvoje Niksic, 2005/10/16
- Re: Saving minibuffer history, Stefan Monnier, 2005/10/16
- Re: Saving minibuffer history, Hrvoje Niksic, 2005/10/18
- RE: Saving minibuffer history, Drew Adams, 2005/10/24
- RE: Saving minibuffer history, Drew Adams, 2005/10/24
- Re: Saving minibuffer history, Stefan Monnier, 2005/10/24
- Re: Saving minibuffer history, Stefan Monnier, 2005/10/16
- Re: Saving minibuffer history, Hrvoje Niksic, 2005/10/18
- Re: Saving minibuffer history, Stefan Monnier, 2005/10/18
- Re: Saving minibuffer history, Hrvoje Niksic, 2005/10/18
- Re: Saving minibuffer history,
Stefan Monnier <=
- Re: Saving minibuffer history, Hrvoje Niksic, 2005/10/20
- Re: Saving minibuffer history, Hrvoje Niksic, 2005/10/20
- Re: Saving minibuffer history, Stefan Monnier, 2005/10/20
- Re: Saving minibuffer history, Hrvoje Niksic, 2005/10/20
- Re: Saving minibuffer history, Hrvoje Niksic, 2005/10/24
- Re: Saving minibuffer history, Stefan Monnier, 2005/10/24
- Re: Saving minibuffer history, Hrvoje Niksic, 2005/10/25
- Re: Saving minibuffer history, Richard M. Stallman, 2005/10/26
- Re: Saving minibuffer history, Stefan Monnier, 2005/10/24
- Re: Saving minibuffer history, Stefan Monnier, 2005/10/25