From mboxrd@z Thu Jan 1 00:00:00 1970 From: nljlistbox2@gmail.com (N. Jackson) Subject: bug#5753: something, something, org-mode, shift-select, something Date: Mon, 10 Feb 2014 17:29:55 -0400 Message-ID: <87mwhy4pws.fsf@moondust.localdomain> References: <87d2j5avwl.fsf@building.gnus.org> <878utkgz36.fsf@bzg.ath.cx> <87wqh4fjfu.fsf@bzg.ath.cx> <87ppmwx8mp.fsf@moondust.localdomain> <877g938loa.fsf@bzg.ath.cx> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:44119) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WCyRX-0004IG-75 for emacs-orgmode@gnu.org; Mon, 10 Feb 2014 16:31:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WCyRS-0007qt-I8 for emacs-orgmode@gnu.org; Mon, 10 Feb 2014 16:31:07 -0500 Received: from debbugs.gnu.org ([140.186.70.43]:34011) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WCyRS-0007qp-Fn for emacs-orgmode@gnu.org; Mon, 10 Feb 2014 16:31:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WCyRR-0007tT-W0 for emacs-orgmode@gnu.org; Mon, 10 Feb 2014 16:31:02 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <877g938loa.fsf@bzg.ath.cx> (Bastien's message of "Mon, 10 Feb 2014 08:35:33 +0100") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Bastien Cc: Lars Ingebrigtsen , Lennart Borgman , 5753@debbugs.gnu.org Bastien writes: > Can you try the two recipes I gave here: > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5753#26 Wherein Bastien gnu.org> writes: >> With Emacs from trunk: Ah, that sounds like the start of a new adventure... ... which went _far_ more smoothly than I expected! I am now testing with GNU Emacs 24.3.50.1 Repository revision: 116400 and Org-mode version 8.2.5c. >> ~$ emacs RET >> C-x C-f test.org RET >> M-x cua-mode RET >> M-: (setq org-support-shift-select t) RET >> M-: (insert "blahblah") RET C-a >> S- >> >> will select correctly here. >> >> ~$ emacs RET >> M-: (setq org-support-shift-select t) RET >> M-: (setq org-replace-disputed-keys t) RET >> M-: (insert "* A headline") RET >> C-a >> S- >> >> will also select correctly instead of switching the TODO keyword. > and tell me where it does not produce the expected output? The first recipe is ambiguous because M-x cua-mode RET toggles the on/off or off/on state of cua-mode, so it depends on how it is set in one's configuration files. In any case, with both recipes, Org behaves correctly in 24.3.50.1. The first recipe fails in 24.3.1 when cua-mode is not enabled in one's configuration files (i.e. when you turn it on at the beginning of the recipe). Here's a simpler recipe: emacs -Q M-: (org-support-shift-select t) RET M-x cua-mode RET ; Turn _on_ cua mode C-x C-f new-test.org RET a S- ; Expected: "a" is selected / highlighted C-x ; Expected: "a" is removed to the clipboard In Emacs 24.3.1 (as, I believe, in Emacs 23), the S- just moves the cursor, no selection is highlighted, and the C-x fails to remove the "a" to the clipboard. This defect is fixed in Emacs 24.3.50.1. :) As far as shift selection over headlines, todos, and datestamps is concerned, in general, shift selection behaviour in Emacs 24.3.50.1 (unlike in Emacs 24.3.1) now seems to behave as it is described in the doc string: C-h v org-support-shift-select RET as follows: org-support-shift-select is a variable defined in `org.el'. Its value is always Original value was nil Documentation: Non-nil means make shift-cursor commands select text when possible. In Emacs 23, when `shift-select-mode' is on, shifted cursor keys start selecting a region, or enlarge regions started in this way. In Org-mode, in special contexts, these same keys are used for other purposes, important enough to compete with shift selection. Org tries to balance these needs by supporting `shift-select-mode' outside these special contexts, under control of this variable. The default of this variable is nil, to avoid confusing behavior. Shifted cursor keys will then execute Org commands in the following contexts: - on a headline, changing TODO state (left/right) and priority - (up/down) on a time stamp, changing the time in a plain list item, - changing the bullet type in a property definition line, switching - between allowed values in the BEGIN line of a clock table - (changing the time block). Outside these contexts, the commands will throw an error. When this variable is t and the cursor is not in a special context, Org-mode will support shift-selection for making and enlarging regions. To make this more effective, the bullet cycling will no longer happen anywhere in an item line, but only if the cursor is exactly on the bullet. If you set this variable to the symbol `always', then the keys will not be special in headlines, property lines, and item lines, to make shift selection work there as well. If this is what you want, you can use the following alternative commands: `C-c C-t' and `C-c ,' to change TODO state and priority, `C-u C-u C-c C-t' can be used to switch TODO sets, `C-c -' to cycle item bullet types, and properties can be edited by hand or in column view. However, when the cursor is on a timestamp, shift-cursor commands will still edit the time stamp - this is just too good to give up. XEmacs user should have this variable set to nil, because `shift-select-mode' is in Emacs 23 or later only. You can customize this variable. This is very very helpful stuff, clearly presented, and I feel it ought to be in the info manual as well. [The only part that I don't see working properly is the changing of bullet types. As far as I can tell, this doesn't happen -- but it's not something I've ever tried to do and maybe I'm not using it right.] I just did a cursory look at the effect of org-replace-disputed-keys, because I don't use this. Was an issue with this reported in the original bug? If so, I can test it more thoroughly. I hope the above report is of some use. Regards, N.