From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stephen Berman Newsgroups: gmane.emacs.devel Subject: Window splitting deactivates the mark? Date: Tue, 13 Dec 2005 00:17:27 +0100 Message-ID: <87r78hvraw.fsf@escher.local.home> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1134430788 16251 80.91.229.2 (12 Dec 2005 23:39:48 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 12 Dec 2005 23:39:48 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 13 00:39:46 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1ElxGJ-000126-JR for ged-emacs-devel@m.gmane.org; Tue, 13 Dec 2005 00:39:20 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ElxGi-0008CN-VV for ged-emacs-devel@m.gmane.org; Mon, 12 Dec 2005 18:39:44 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Elwyu-0007RN-NL for emacs-devel@gnu.org; Mon, 12 Dec 2005 18:21:20 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Elwyt-0007Qx-MV for emacs-devel@gnu.org; Mon, 12 Dec 2005 18:21:20 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Elwyt-0007Qq-GU for emacs-devel@gnu.org; Mon, 12 Dec 2005 18:21:19 -0500 Original-Received: from [80.91.229.2] (helo=ciao.gmane.org) by monty-python.gnu.org with esmtp (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.34) id 1Elx0g-00086n-Hy for emacs-devel@gnu.org; Mon, 12 Dec 2005 18:23:11 -0500 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1ElwvQ-0004x9-QK for emacs-devel@gnu.org; Tue, 13 Dec 2005 00:17:44 +0100 Original-Received: from i5387dd1b.versanet.de ([83.135.221.27]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 13 Dec 2005 00:17:44 +0100 Original-Received: from Stephen.Berman by i5387dd1b.versanet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 13 Dec 2005 00:17:44 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-To: emacs-devel@gnu.org Original-Lines: 68 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: i5387dd1b.versanet.de User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) 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:47575 Archived-At: Is splitting the window supposed to deactivate the mark sometimes? I don't see in the source where it does, but I may not understand all of the splitting code. I ask, because I have been observing behavior involving the mark being deactivated when the window is split, but only under certain conditions. So far I have only seen this behavior when tabbar-mode is enabled. This mode is from tabbar.el, which is not part of Emacs (but I would be in favor of adding it!). Nevertheless, I'm asking about this here, because (i) the behavior obtains under Emacs 22 but not under Emacs 21 using the same version of tabbar.el (the current version, available at ), and (ii) I've corresponded with the author of tabbar.el, David Ponce, and he could not immediately find the cause of the problem in tabbar.el but did find a possible workaround and he also suggested I post here about the matter. Here are the minimal steps to reproduce the behavior (using tabbar.el v1.67 and current CVS Emacs): 1. emacs -q 2. Type either `C-x 2' or `C-x 3' to split the window, and then type `C-x b', so that one window contains the *Messages* buffer and the other contains the *scratch* buffer. 3. (Sanity check:) In *scratch*, using the mouse, drag across or double click on a word to highlight it, then type C-w to delete the highlighted word. Undo the deletion to restore the original state. 4. Load tabbar.el and type M-x tabbar-mode to enable tabbar-mode. 5. Repeat step 3: you will now find that upon typing C-w the highlighted word is not deleted and is no longer highlighted, and in the echo area the message "The mark is not active now" appears. 6. Now do any one of the following: (i) type `C-x 1' to remove the window splitting, (ii) keep the splitting but have the same buffer in both windows, (iii) keep the splitting but have buffers from two different tab bar groups in the windows, e.g. *scratch* and a *Help* buffer (this holds for this particular case, and for some other modes I tried, but I can't say whether it's really true in general), or (iv) disable tabbar-mode. Now you can repeat step 3 and deleting the highlighted word works again. Also note that, in step 5, if you mark the word not with the mouse but with the keyboard (C-SPC etc.), then deletion can happen and in *Messages* "Mark activated" appears. In correspondence David Ponce added the following observations: > I just noticed that the same scenario works [i.e., behaves as in > step 3, not as in step 5] in Emacs 21.4. Also, it works in Emacs 22 > after enabling CUA mode. And even after disabling it! And he discovered an apparent workaround: > I found that setting `mark-even-if-inactive' to non-nil seems to fix > the tabbar problem. I also found that CUA mode set it to non-nil > when enabled and don't restore it when disabled. That explains why > your scenario works after enabling CUA mode. I've confirmed these further observations and the workaround. Assuming the problem doesn't lie in tabbar.el (and if it does, it has yet to be found there), does the window-splitting code do something that deactivates the mark in the circumstances described above? Or could it be due to something in the mouse code, in view of the difference between mouse and keyboard selection noted above? Any advice, also about how to go about investigating this further (instrumenting tabbar.el and stepping though it with edebug didn't reveal anything to me), would be appreciated. Steve Berman