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 13:28:46 -0800 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1137970617 29188 80.91.229.2 (22 Jan 2006 22:56:57 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 22 Jan 2006 22:56:57 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 22 23:56:55 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 1F0o8i-0003uS-Kz for ged-emacs-devel@m.gmane.org; Sun, 22 Jan 2006 23:56:53 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F0oBK-0008Ry-5z for ged-emacs-devel@m.gmane.org; Sun, 22 Jan 2006 17:59:34 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1F0moJ-0007Sm-DC for emacs-devel@gnu.org; Sun, 22 Jan 2006 16:31:43 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1F0moI-0007Rs-6x for emacs-devel@gnu.org; Sun, 22 Jan 2006 16:31:42 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F0moI-0007Rj-1E for emacs-devel@gnu.org; Sun, 22 Jan 2006 16:31:42 -0500 Original-Received: from [141.146.126.228] (helo=agminet01.oracle.com) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1F0msu-00046Z-5q for emacs-devel@gnu.org; Sun, 22 Jan 2006 16:36:28 -0500 Original-Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k0MLSuKS006401 for ; Sun, 22 Jan 2006 15:28:56 -0600 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 k0MLSt2K004778 for ; Sun, 22 Jan 2006 14:28:55 -0700 Original-Received: from dradamslap (dhcp-amer-rmdc-csvpn-gw5-141-144-104-212.vpn.oracle.com [141.144.104.212]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id k0MLSsZK004768 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sun, 22 Jan 2006 14:28:55 -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: 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:49415 Archived-At: I probably shouldn't jump in here, since I haven't been following this closely. Ignore, if my comments make little sense or are redundant. Juri> I'd reserve M-n and M-p in editable fields for history navigation. Since editable fields are very like the minibuffer where M-n and M-p are used to navigate in the minibuffer history, it makes sense to implement something similar for editable fields (after the release). RMS> I don't think this is necessary, because there is already an undo mechanism (the "backup value"). RMS: Does that provide a single backup value or an undo history of all edits of the value (field)? Juri: I assume you mean that there would be a separate M-n/M-p history for each value (editable field). 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)? 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...)? Instead I think it should preserve the ordinary undo list when you set the variable. Currently, setting the variable discards the undo list, which is more or less a bug. Either way would be OK for undo. I like Juri's suggestion (IIUC) of history lists with entries that would be the values that were set or saved (one list per option/field). Most such lists would be empty most of the time, of course. Given such history lists, undo would let you rewind your edits (either until the last set or save operation or, as RMS suggests, further), while, say, M-p would rewind the history of value settings (for that option). Especially when complex Lisp values are concerned, one is particularly interested in previously set values, not just in the mini changes of edits. And undoing edit operations on previous values (from the history list) might not be a real requirement. It's most important to be able to: 1. undo edits back to the last set or save operation, and 2. retrieve previously set or saved values. Of course, extending undo further back wouldn't be a bad thing, but it has a cost. Also, are we speaking of a single, global undo for the whole buffer or an individual undo per editable field? The latter would be preferable. S-TAB is the preferable key binding [for navigating backward], but currently it's impossible to specify a preferable key binding in the docstring. The way to do that is to use two different command names. Look at `advertised-undo', for instance. We could use that same technique to make sure that S-TAB is what appears in a doc string. This question of how to control which binding appears in a doc string when there are several has been brought up previously (probably more than once). It's a separate problem, and one that it would be good to address in some general fashion after the release. See, for instance, the emacs-devel thread "Qs on key-description, substitute-command-keys" from 2005-10-15 to 16. Stefan made a couple of alternative suggestions in that thread: 1. Have a `preferred-binding' property on a command symbol. It would contain a preferred binding or a list of preferred bindings to be used by `substitute-in-command-keys'. 2. Require the use of a menu item for the main binding, and then obey a Boolean `:preferred-binding' property placed on the menu item. Maybe we should define M-n and M-p for this, just to have a consistent set of commands that move in both directions. Or maybe we should settle for having S-TAB available only on graphics terminals. How about reserving M-n/M-p within an editable field for a value history (for that field) = Juri's suggestion? M-n/M-p outside an editable field could be used for something else, but navigation among fields is something you often do from within a field, so M-n/M-p probably shouldn't replace TAB/S-TAB for such navigation. (A poor workaround would be to navigate to just before the field etc.) For navigation, in addition to TAB/S-TAB (when available), what about reusing the global bindings of `forward-sentence'/`backward-sentence' (M-e, M-a) for navigation? Or those of `forward-paragraph'/`backward-paragraph' (C-up, C-down, M-{, M-})? Those aren't particularly useful in Customize anyway, are they? They might represent a good sacrifice, to obtain bindings that work on ttys too (not C-up, C-down, perhaps, but I assume the others work everywhere).