From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: Problems with whole buffer Custom functions. Date: Sun, 22 Jan 2006 18:58:17 -0800 Message-ID: References: <8764obk6ul.fsf@jurta.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1137985143 30478 80.91.229.2 (23 Jan 2006 02:59:03 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 23 Jan 2006 02:59:03 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 23 03:59:02 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1F0ruw-0000dv-4Q for ged-emacs-devel@m.gmane.org; Mon, 23 Jan 2006 03:58:54 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F0rxY-000537-B9 for ged-emacs-devel@m.gmane.org; Sun, 22 Jan 2006 22:01:36 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1F0rxF-000530-0I for emacs-devel@gnu.org; Sun, 22 Jan 2006 22:01:17 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1F0rxD-00052V-9Z for emacs-devel@gnu.org; Sun, 22 Jan 2006 22:01:16 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F0rxC-00052R-VX for emacs-devel@gnu.org; Sun, 22 Jan 2006 22:01:15 -0500 Original-Received: from [148.87.122.30] (helo=rgminet01.oracle.com) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1F0s1s-0004FX-1r for emacs-devel@gnu.org; Sun, 22 Jan 2006 22:06:04 -0500 Original-Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k0N2wTJh009137 for ; Sun, 22 Jan 2006 19:58:29 -0700 Original-Received: from rgmsgw300.us.oracle.com (localhost [127.0.0.1]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k0N2wT4i018313 for ; Sun, 22 Jan 2006 19:58:29 -0700 Original-Received: from dradamslap (dhcp-apac-jp-csvpn-gw9-141-144-144-159.vpn.oracle.com [141.144.144.159]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id k0N2wNgR018284 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sun, 22 Jan 2006 19:58:28 -0700 Original-To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <8764obk6ul.fsf@jurta.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:49430 Archived-At: > 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.