From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Shift selection using interactive spec Date: Sun, 16 Mar 2008 23:31:54 +0000 Message-ID: <20080316233154.GD1544@muc.de> References: <87prtxpekk.fsf@kfs-lx.rd.rdm> <87abl11ilo.fsf@stupidchicken.com> <874pb9koyw.fsf@stupidchicken.com> <87od9gzqv9.fsf@stupidchicken.com> <87bq5gytbi.fsf@stupidchicken.com> <8763vndi0r.fsf@kfs-lx.rd.rdm> <47DC38AD.5010400@emf.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1205709502 24305 80.91.229.12 (16 Mar 2008 23:18:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 16 Mar 2008 23:18:22 +0000 (UTC) Cc: Chong Yidong , Dan Nicolaescu , emacs-devel@gnu.org, Stefan Monnier , "Kim F. Storm" To: Thomas Lord Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 17 00:18:50 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Jb27s-0000bD-07 for ged-emacs-devel@m.gmane.org; Mon, 17 Mar 2008 00:18:48 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jb27I-0007Pi-BE for ged-emacs-devel@m.gmane.org; Sun, 16 Mar 2008 19:18:12 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Jb26Z-0006rm-L1 for emacs-devel@gnu.org; Sun, 16 Mar 2008 19:17:27 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Jb26Y-0006rO-Ps for emacs-devel@gnu.org; Sun, 16 Mar 2008 19:17:27 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jb26Y-0006rL-NJ for emacs-devel@gnu.org; Sun, 16 Mar 2008 19:17:26 -0400 Original-Received: from colin.muc.de ([193.149.48.1] helo=mail.muc.de) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Jb26Y-0006jd-24 for emacs-devel@gnu.org; Sun, 16 Mar 2008 19:17:26 -0400 Original-Received: (qmail 95503 invoked by uid 3782); 16 Mar 2008 23:17:23 -0000 Original-Received: from acm.muc.de (p57AF5659.dip.t-dialin.net [87.175.86.89]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Mon, 17 Mar 2008 00:17:19 +0100 Original-Received: (qmail 10232 invoked by uid 1000); 16 Mar 2008 23:31:54 -0000 Content-Disposition: inline In-Reply-To: <47DC38AD.5010400@emf.net> User-Agent: Mutt/1.5.9i X-Delivery-Agent: TMDA/1.1.5 (Fettercairn) X-Primary-Address: acm@muc.de X-detected-kernel: by monty-python.gnu.org: FreeBSD 4.6-4.9 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:92784 Archived-At: Hi, Thomas! On Sat, Mar 15, 2008 at 01:59:25PM -0700, Thomas Lord wrote: [ .... ] > The region between tenative-mark and point is called the > tentative-region. > save-excursion should save and restore the value of tentative-mark, > setting it to nil when running its body. Maybe. > Low level functions (in C) that insert text into a buffer should > unconditionally delete the tentative region first, if there is one, and > set tentative-mark to nil. No, I disagree. Philosophically, this is a mixup of levels. A low-level function which is inserting text should NOT be messing around with tentative regions. This will surely cause pain, in some as yet unclear way. Surely higher level defuns should be built which call the C primitives, allowing these primitives to remain primitive. Also, can't we make Emacs a bit better? A tentative region should be _killed_, not deleted - i.e., there should be an easy way of recovering it when it's accidentally de-regioned. > Conceptually, this is a generalization of the notion of a "point". A > point is an index naming a theoretical "space between" two adjacent > characters in a buffer, or the space at the beginning or end of buffer. > A "tentative region" is like having a pseudo-point which indicates a > conceptual "space between" in a hypothetical buffer that results from > deleting the contents of the tentative region. > That is the essential functionality that delete-selection-mode is > aiming for but, by adding the concept of a tentative-mark, that > essential functionality is simplified enough that it can reasonably be > built-in as unconditional behavior of a few insertion commands. That unconditionality would make the concept of a "tentative region" less flexible and less useful, wouldn't it? The user should be able to customize when his tentative regions are killed by insertion commands; for example, by major mode. > There should be a a second and third variable: > maybe-preserved-tentative-mark and preserved-tentative-mark. These > are, again, either nil or a mark. These are used to control which > commands preserve the tentative mark vs. which set it back to nil (the > default behavior): You've completely lost me, here. I can't see how the first two sentences connect with the last one. I'm also getting lost in the sheer complexity of the proposal, and feel that three "tentative-mark" variables is a bad idea - there will be too much confusion between them. > When a command returns to a command loop, the value of > preserved-tentative-mark should be copied to tentative-mark, > unconditionally. Both maybe-preserved-... and preserved-... should be > set to nil. So, by default, commands implicitly "clear" the > tentative mark. Presumbaly, there would be customization commands to tailor this default. For example, C-l is the sort of thing you'd want to do _without_ losing a tentative region. > Before a command loop invokes a command, it should first copy > tenative-mark to maybe-preserved-... That way, if a command wants to > preserve the tentative mark if it is already present (the default > interpretation of "shifted keysequences") then it can simply copy > maybe-preserved-... to preserved-tentative-mark. When the command > returns, that saved mark will be copied back to tentative-mark. This sounds like the tail waggging the dog. If a command wants to preserve a tentative mark, it merely needs to do nothing. Why should the command loop be complicated for this purpose? I really don't think we should be messing with the command loop for this facility; that's a horrible kludge. The mechanics of executing one command after another should be kept separate from what these commands do; conceptually, the "tentative region" mechanism has no connection with the command loop, any more than scrolling, fontification or indentation has. [ .... ] > So: > three new variables > one new display feature (clone of an existing feature) > a couple unconditional variable copies in the command loop > a few new functions > unconditionally delete the transient region in some C code > modify some core functions like yank and replace-string > fix obscure commands that work similarly to yank or replace-string on-demand > lots and lots of code that doesn't have to be modified at all > a very simple "state machine" model of the behavior > a behavior that highly agrees with "all those other GUIs" and how about a name for this new editor? ;-) > For extra special featurefulness, you could build on that > by adding a "transient region ring" -- a circular buffer that > remembers the last N transient regions whenever some > command nillifies the transient region at the top level. > A "remembered" transient region is a pair of marks: > the transient-mark and a marker at what was then the > point. Something like this is utterly required. > N should probably be small but the idea is that recent > transient regions are cached so that if the region is > accidentally cleared by some command then a user > can likely restore it, easily. YES!!! > So, in terms of "pronouns" again -- "addressing modes" for users -- the > mark stack gives you a set of pronouns for recursing while the > transient region ring gives you augmented short-term memory about "fat > cursors". > I'm really surprised, as I've been led to think about these features by > the recent discussion, just exactly how complementary "GUI-style > shift-select" and Emacs' user model and command interaction loop turn > out to be. They fit together like hand and glove, if only Emacs will > actually implement it that way. Hmm... Do they really? One good reason I've stayed with Emacs is that it doesn't impose this (to me) ghastlily inefficient and nerve-wrackingly fragile shift-select mechanism on me. Please make sure that ALL the features you're talking about are optional, even if they do become the default. > I'm one of those users who is both an Emacs power user *and* make > pretty heavy use of GUI-style apps. I constantly have the low-level > frustration of how selection, cut, paste, etc. work differently between > these environments: often typing or mousing into some app as if it > were Emacs or into Emacs as if it were some other app. So, I feel > pretty viscerally the pain that work on shift selection is trying to > address. > I'm pretty convinced the little state machine model I've been > developing here is a really good model for the desired functionality. > So, I'm skeptical that all the hair of trying to use > transient-mark-mode for this stuff is a good idea. I rather think that these things are more flavour of the decade rather than permanent; in ten or twenty years time, shift-select may well have gone the way of autoexec.bat. So lets not embed it too firmly inside Emacs, below the level of individual commands. > -t -- Alan Mackenzie (Nuremberg, Germany).