[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Problems with whole buffer Custom functions.

From: Drew Adams
Subject: RE: Problems with whole buffer Custom functions.
Date: Sun, 22 Jan 2006 18:58:17 -0800

    > I assume you mean that there would be a separate M-n/M-p history for
    > each value (editable field).

    I meant a history mechanism like is used in modern GUI applications,
    e.g. in Firefox typing M-down in an editable field opens a list of
    values previously entered into the same field.  There is also Emacs-like
    completion that filters out values based on the contents of the field.

Yes.  Good.

    > What would be the extent (limit) of the proposed history
    > list(s)? Would the limit be the current Emacs session? the current
    > access to Customize for that field? Or would the histories be
    > persistent (e.g. via savehist.el)?

    Adding a new history variable with a list (or alist with one sublist per
    option/field or per widget class) of previously entered values would
    automatically allow saving it with savehist.el or desktop.el.

Sounds good to me.  (I almost mentioned an alist implementation myself.)

If we did that, we might also (eventually) provide an easy way to empty
(clear) one or all of these history lists - like you can do in a Web
browser.  Not that histories of edited values pose a great threat to
privacy, but you might want to clear them out at some point so you could
more easily notice subsequent changes - that is, reset the history.

    > What would constitute an entry in such a history list: would
    > it be each individual edit (a la undo) or each value that the user
    > sets or saves (via Set for Current Session or Save...)?

    I think preserving each value that the user sets or saves is more useful
    than preserving mini changes undoable with the ordinary undo.

So do I. That's why I brought it up. However, it might still be useful to
(also) be able to incrementally undo the edits for each field (separately)
since the field's last set or save operation. That could help with editing
complex Lisp expressions, for instance.

    This would work exactly like history lists work in the minibuffer: in
    minibuffer, history list gets updated after exiting with RET, in
    fields this could be done after activating the field.

Sounds good to me.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]