all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
Subject: RE: Problems with whole buffer Custom functions.
Date: Sun, 22 Jan 2006 18:58:17 -0800	[thread overview]
Message-ID: <MEEKKIABFKKDFJMPIOEBCEKDCOAA.drew.adams@oracle.com> (raw)
In-Reply-To: <8764obk6ul.fsf@jurta.org>

    > 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
the
    minibuffer, history list gets updated after exiting with RET, in
editable
    fields this could be done after activating the field.

Sounds good to me.

  reply	other threads:[~2006-01-23  2:58 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-13  3:32 Problems with whole buffer Custom functions Luc Teirlinck
2006-01-17  1:27 ` Juri Linkov
2006-01-17  4:13   ` Luc Teirlinck
2006-01-17 21:54     ` Juri Linkov
2006-01-18  0:29       ` Kevin Rodgers
2006-01-23  0:10       ` Richard M. Stallman
2006-01-22  0:45     ` Juri Linkov
2006-01-22  1:46       ` Luc Teirlinck
2006-01-23  1:42         ` Juri Linkov
2006-01-24 16:46           ` Richard M. Stallman
2006-01-24 21:45             ` Juri Linkov
2006-01-24 23:11               ` Lennart Borgman
2006-01-25  7:55                 ` Juri Linkov
2006-01-25 15:45               ` Richard M. Stallman
2006-01-22  1:55       ` Luc Teirlinck
2006-01-23  1:43         ` Juri Linkov
2006-01-22  0:45     ` Juri Linkov
2006-01-22 17:44       ` Richard M. Stallman
2006-01-19 17:44   ` Richard M. Stallman
2006-01-22  0:45     ` Juri Linkov
2006-01-22 17:44       ` Richard M. Stallman
2006-01-22 21:28         ` Drew Adams
2006-01-23  1:47           ` Juri Linkov
2006-01-23  2:58             ` Drew Adams [this message]
2006-01-23  6:17               ` Juri Linkov
2006-01-24 16:47           ` Richard M. Stallman
2006-01-23  1:47         ` Juri Linkov
2006-01-24 16:46           ` Richard M. Stallman
2006-01-23 18:04         ` martin rudalics
2006-01-25  3:28           ` Richard M. Stallman
2006-01-22 17:44       ` Richard M. Stallman
  -- strict thread matches above, loose matches on Subject: below --
2006-01-25  8:58 LENNART BORGMAN

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=MEEKKIABFKKDFJMPIOEBCEKDCOAA.drew.adams@oracle.com \
    --to=drew.adams@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.