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: Preserving sanity in Emacs [Re: rampant region highlighting] Date: Sun, 6 Apr 2008 23:00:56 +0000 Message-ID: <20080406230056.GB5362@muc.de> References: <47F945C3.1060103@harpegolden.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1207521899 30728 80.91.229.12 (6 Apr 2008 22:44:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 6 Apr 2008 22:44:59 +0000 (UTC) Cc: Glenn Morris , emacs-devel@gnu.org To: David De La Harpe Golden Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 07 00:45:29 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 1Jidc6-00042Q-WA for ged-emacs-devel@m.gmane.org; Mon, 07 Apr 2008 00:45:27 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JidbT-0005Hx-V4 for ged-emacs-devel@m.gmane.org; Sun, 06 Apr 2008 18:44:48 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JidbM-0005FT-Nb for emacs-devel@gnu.org; Sun, 06 Apr 2008 18:44:40 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JidbM-0005EZ-0f for emacs-devel@gnu.org; Sun, 06 Apr 2008 18:44:40 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JidbL-0005EQ-MG for emacs-devel@gnu.org; Sun, 06 Apr 2008 18:44:39 -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 1JidbL-0008Cu-15 for emacs-devel@gnu.org; Sun, 06 Apr 2008 18:44:39 -0400 Original-Received: (qmail 59044 invoked by uid 3782); 6 Apr 2008 22:44:37 -0000 Original-Received: from acm.muc.de (p57AF4C77.dip.t-dialin.net [87.175.76.119]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Mon, 07 Apr 2008 00:44:34 +0200 Original-Received: (qmail 6533 invoked by uid 1000); 6 Apr 2008 23:00:56 -0000 Content-Disposition: inline In-Reply-To: <47F945C3.1060103@harpegolden.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:94522 Archived-At: Hi, David! On Sun, Apr 06, 2008 at 10:50:59PM +0100, David De La Harpe Golden wrote: > This is a bit disjointed, sorry: ;-) > This is likely immediately "due" to transient-mark-mode being on, but > this is IMO NOT a case against t-m-m, it's a case for making emacs point > handling during scrolling more like other editors. I think we're gradually sinking deeper and deeper into a tarpit of kludges. Transient Mark Mode, getting shifty to mark regions, .... I think backing off and thinking what we're actually turning Emacs into, before we get mired any further, would be a good idea. > How is emacs point handling during scrolling different? > See this thread: > http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg01892.html PLEASE STOP DOING THIS!!! This is a _mailing_ _list_, not a web forum. Quote the Subject:, Date:, and Message-Id: at the very least, please, for heaven's sake! Better still, summarise what you're so aggravatingly referring to. Please! I haven't gone to the trouble of looking up that web reference. > Unusual in Emacs is that the point is always kept on-screen by point > warping during scrolling. This is something of a long-standing emacs > feature really, but means that if you scroll, the region as defined by > mark->point changes shape. Yes. Point is the place on the screen you're looking at. That's part of the point. At least one end of the region is on the screen. > Other editors typically preserve point position during scrolling. > Martin Rudalics wrote a hack to address this as shown in the above > thread*. So, point disappears off your screen. How are you supposed to get back there? What key sequence would you suggest for the new command `scroll-to-pont'? The "booby trap bomb" solution implemented by lesser editors (you touch certain random keys, like an arrow or a self-insert key, often by accident, and the screen goes BOOOOMM!!!, completely losing your mental context) isn't acceptable to Emacs, where minimal disturbance of the user is an overriding principle. > When t-m-m is OFF, point movement after a mouse selection by mouse > dragging deactivates the mouse drag overlay, so you don't notice > anything amiss, but when t-m-m is on, mouse dragging defines /and > activates/ the "real" mark-point region, and it is not deactivated by > subsequent point movements (This also ties in to the shift-selection > discussion, as it could be deactivated by unshifted movements in those > cases, say). That's too complicated for me at this time of night. Notice just how remote all this is from the beautiful, compelling, effective simplicity of the traditional Emacs point and mark. Why are we in this tarpit? > If you make the mouse-drag-overlay and the region use different faces > you can see better what's going on. line 751 ish of mouse.el, change > (overlay-put ol 'face 'region) to (overlay-put ol 'face highlight) > in the (defconst mouse-drag-overlay ...) > Then try mouse selection with t-m-m on, and off. As you can > see, what you might have thought was a transient region is actually > a sort of separate thing... > But if point position wasn't warped by scrolling, then it would all be > okay... The point is the place on the screen that you're looking at, where new text appears when you type. Are you suggesting that when you type, you shouldn't see anything, because "point" isn't on the screen? > Note that most text editors have a transient region. Thomas Lord's talk > of "fat cursors" notwithstanding, in practice these are implemented by > their point (cursor) defining one edge of the region in those editors, > as you can see in kde's editor (cos they don't bother hiding their line > cursor), and you can infer in GNOME's (since when you move the cursor > after demarcating a region, it moves from one end of the region) - when > something affecting the point/region happens, the area is jump-scrolled > to visibility. That counts as cruel and unusual treatment, and violates the Geneva convention of hackers' rights. > * Thinking about it, mostly emacs seems to be using explicit calls to > change point position, I'm wondering is a neater solution to martins to > just take/conditionalize some of the repositioning out of the code > paths, and just allow the point to go offscreen... No. -- Alan Mackenzie (Nuremberg, Germany).