bug#5753: something, something, org-mode, shift-select, something

bug#5753: something, something, org-mode, shift-select, something

[Lars Ingebrigtsen]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> Shift-select in cua-mode does not work in org-mode although
> org-replace-disputed-keys is t, org-disputed-keys are set for shift
> arrow keys and org-support-shift-select is always

Is this problem still present in Emacs 24.3?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#5753: something, something, org-mode, shift-select, something

[N. Jackson]

The following message is a courtesy copy of an article
that has been posted to gnu.emacs.bug as well.

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Lennart Borgman <lennart.borgman@gmail.com> writes:
>
>> Shift-select in cua-mode does not work in org-mode although
>> org-replace-disputed-keys is t, org-disputed-keys are set for shift
>> arrow keys and org-support-shift-select is always
>
> Is this problem still present in Emacs 24.3?

Naturally I can't answer for the OP (and I don't know about disputed
keys) but I can report that in general this problem persists in Emacs
24.3.

On GNU Emacs 24.3.1 [1], shift select does not work in org mode. I'm not
certain this is a bug, as my understanding is that the org authors did
not design it to work with shift select?

In any case, I use a very simple workaround which makes shift select
work just fine in org mode; I've never had any problems with it. It
looks like this (Note: It is of unknown provenance, aside from the
attribution in the comment.):

;; This snippit from jisang-yoo on reddit to enable shift select in org
;; mode when cua-mode is on.
(eval-after-load "org"
    '(progn
       (eval-after-load "cua-base"
         '(progn
            (defadvice org-call-for-shift-select (before
            org-call-for-shift-select-cua activate)
              (if (and cua-mode
                       org-support-shift-select (not (use-region-p)))
                  (cua-set-mark)))))))
;; End jisang-yoo snippit

With this in my org settings, I have no problems with shift select
except that you cannot start a selection on a timestamp (because shift
with cursor keys adjusts timestamps), but I've learnt to automatically
start my selection from the end of the line above the timestamp so I
don't have any problems.

I hope this information is of some use.

[1] GNU Emacs 24.3.1 (x86_64-redhat-linux-gnu, GTK+ Version 3.8.2) of
2013-08-14 on buildvm-15.phx2.fedoraproject.org

bug#5753: something, something, org-mode, shift-select, something

[Lennart Borgman]

[-- Attachment #1: Type: text/plain, Size: 2314 bytes --]

On Sun, Feb 9, 2014 at 2:25 AM, N. Jackson <gentleundercurrent@gmail.com>wrote:

> The following message is a courtesy copy of an article
> that has been posted to gnu.emacs.bug as well.
>
> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
> > Lennart Borgman <lennart.borgman@gmail.com> writes:
> >
> >> Shift-select in cua-mode does not work in org-mode although
> >> org-replace-disputed-keys is t, org-disputed-keys are set for shift
> >> arrow keys and org-support-shift-select is always
> >
> > Is this problem still present in Emacs 24.3?
>
> Naturally I can't answer for the OP (and I don't know about disputed
> keys) but I can report that in general this problem persists in Emacs
> 24.3.
>
> On GNU Emacs 24.3.1 [1], shift select does not work in org mode. I'm not
> certain this is a bug, as my understanding is that the org authors did
> not design it to work with shift select?
>
> In any case, I use a very simple workaround which makes shift select
> work just fine in org mode; I've never had any problems with it. It
> looks like this (Note: It is of unknown provenance, aside from the
> attribution in the comment.):
>
> ;; This snippit from jisang-yoo on reddit to enable shift select in org
> ;; mode when cua-mode is on.
> (eval-after-load "org"
>     '(progn
>        (eval-after-load "cua-base"
>          '(progn
>             (defadvice org-call-for-shift-select (before
>             org-call-for-shift-select-cua activate)
>               (if (and cua-mode
>                        org-support-shift-select (not (use-region-p)))
>                   (cua-set-mark)))))))
> ;; End jisang-yoo snippit
>
> With this in my org settings, I have no problems with shift select
> except that you cannot start a selection on a timestamp (because shift
> with cursor keys adjusts timestamps), but I've learnt to automatically
> start my selection from the end of the line above the timestamp so I
> don't have any problems.
>
> I hope this information is of some use.
>
> [1] GNU Emacs 24.3.1 (x86_64-redhat-linux-gnu, GTK+ Version 3.8.2) of
> 2013-08-14 on buildvm-15.phx2.fedoraproject.org
>
>
> Thanks Jason. I can't test now myself.

I think this problem illustrates very well why cua-mode must be made a
first class citizen in Emacs. Without that problems like this are showing
up for beginners.

[-- Attachment #2: Type: text/html, Size: 3850 bytes --]

bug#5753: something, something, org-mode, shift-select, something

[Lennart Borgman]

[-- Attachment #1: Type: text/plain, Size: 1056 bytes --]

On Sun, Feb 9, 2014 at 12:05 PM, Lennart Borgman
<lennart.borgman@gmail.com>wrote:

> On Sun, Feb 9, 2014 at 2:25 AM, N. Jackson <gentleundercurrent@gmail.com>wrote:
>
>> The following message is a courtesy copy of an article
>> that has been posted to gnu.emacs.bug as well.
>>
>> Lars Ingebrigtsen <larsi@gnus.org> writes:
>>
>> > Lennart Borgman <lennart.borgman@gmail.com> writes:
>> >
>> >> Shift-select in cua-mode does not work in org-mode although
>> >> org-replace-disputed-keys is t, org-disputed-keys are set for shift
>> >> arrow keys and org-support-shift-select is always
>> >
>> > Is this problem still present in Emacs 24.3?
>>
>> Naturally I can't answer for the OP (and I don't know about disputed
>> keys) but I can report that in general this problem persists in Emacs
>> 24.3.
>>
>> Thanks Jason. I can't test now myself.
>
> I think this problem illustrates very well why cua-mode must be made a
> first class citizen in Emacs. Without that problems like this are showing
> up for beginners.
>
>
Oh, sorry. I mean Jackson, of course.

[-- Attachment #2: Type: text/html, Size: 2916 bytes --]

bug#5753: something, something, org-mode, shift-select, something

[Bastien]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Lennart Borgman <lennart.borgman@gmail.com> writes:
>
>> Shift-select in cua-mode does not work in org-mode although
>> org-replace-disputed-keys is t, org-disputed-keys are set for shift
>> arrow keys and org-support-shift-select is always
>
> Is this problem still present in Emacs 24.3?

With Emacs from trunk:

~$ 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-<right>

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-<right>

will also select correctly instead of switching the TODO keyword.

So I'm not really sure what is the bug here.  Lennart, can you
be more specific?

Thanks!

-- 
 Bastien

bug#5753: something, something, org-mode, shift-select, something

[Lennart Borgman]

[-- Attachment #1: Type: text/plain, Size: 1023 bytes --]

On Sun, Feb 9, 2014 at 3:06 PM, Bastien <bzg@gnu.org> wrote:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
> > Lennart Borgman <lennart.borgman@gmail.com> writes:
> >
> >> Shift-select in cua-mode does not work in org-mode although
> >> org-replace-disputed-keys is t, org-disputed-keys are set for shift
> >> arrow keys and org-support-shift-select is always
> >
> > Is this problem still present in Emacs 24.3?
>
> With Emacs from trunk:
>
> ~$ 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-<right>
>
> 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-<right>
>
> will also select correctly instead of switching the TODO keyword.
>
> So I'm not really sure what is the bug here.  Lennart, can you
> be more specific?
>
> Thanks!
>
> It would be very nice if the bug was gone, but please ask Jackson!

[-- Attachment #2: Type: text/html, Size: 2392 bytes --]

bug#5753: something, something, org-mode, shift-select, something

[Bastien]

Hi Jackson,

can you tell me what exactly the bug is wrt cua-mode and org-mode?

See my previous recipes in this thread for references.

If the bug is here for Emacs 24.3, can you try downloading and
installing the latest Org stable version (http://orgmode.org)
and see if the bug is still there?

Thanks in advance for your help,

-- 
 Bastien

bug#5753: something, something, org-mode, shift-select, something

[N. Jackson]

Bastien <bzg@gnu.org> writes:

> can you tell me what exactly the bug is wrt cua-mode and org-mode?

Hi Bastien,

Well, I can tell you the symptoms; I'm sorry to report that I know
nothing of the internals.

I have this snippet of code in my configuration files and with it
everything works fine and has been working fine for a few years:

    ;; This snippet from jisang-yoo on reddit to enable shift select in
    ;; org mode when cua-mode is on.
    (eval-after-load "org"
        '(progn
           (eval-after-load "cua-base"
             '(progn
                (defadvice org-call-for-shift-select (before
                org-call-for-shift-select-cua activate)
                  (if (and cua-mode
                           org-support-shift-select (not
                           (use-region-p)))
                      (cua-set-mark)))))))
    ;; End jisang-yoo snippet

If I comment out that snippet and restart Emacs, then shift selection no
longer works in org-mode unless I turn off cua-mode.

When I say shift selection doesn't work, I mean that when I hold down
the shift key and move the cursor with the arrow keys I don't get any
highlighting of the text I'm trying to select. And it's not just a
failure to highlight the selection, there seems to be no selection
happening because a cut or copy of the imaginary selection doesn't do
anything.

If I toggle off cua-mode (from the menu for example), then shift
selection immediately starts working in org-mode. If I leave cua-mode
tuned on and M-x fundamental-mode, then shift selection immediately
starts working in the buffer with org file. That is to say, the symptoms
are simple and 100% reproducible.

> If the bug is here for Emacs 24.3, can you try downloading and
> installing the latest Org stable version (http://orgmode.org) and see
> if the bug is still there?

I am currently using Org-mode version 8.2.5h-6-g8e1386-elpa of
2014-02-03 on GNU Emacs 24.3.1. If you need me to try a newer version of
Org, I can do so, although I do prefer to use the version from Elpa as
it seems it would be easier to uninstall it if it breaks my Emacs.

> Thanks in advance for your help,

You're welcome. Please let me know if you need me to install the latest
Org stable version or do any specific testing.

N.

bug#5753: something, something, org-mode, shift-select, something

[Bastien]

Hi Jackson,

thanks for your thorough reply.

Can you try the two recipes I gave here:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5753#26

and tell me where it does not produce the expected output?

Thanks in advance,

-- 
 Bastien

bug#5753: something, something, org-mode, shift-select, something

[N. Jackson]

Bastien <bzg@altern.org> writes:

> Can you try the two recipes I gave here:
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5753#26

Wherein Bastien <bzg <at> 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-<right>
>> 
>> 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-<right>
>> 
>> 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-<left>    ; 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-<left> 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.

bug#5753: something, something, org-mode, shift-select, something

[N. Jackson]

This post is for the sake of completeness, and to summarise / add to my
previous posts on this bug, namely:

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5753#17
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5753#35
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5753#41

In GNU Emacs 23.3.1 [1] and 24.3 [2], either of the settings

    (setq org-support-shift-select t)

or

    (setq org-support-shift-select (quote always))

will enable shift selection in org-mode, as described in

    C-h v org-support-shift-select RET

_only if_ cua-mode is turned off. But if cua-made is turned on, shift
selection fails everywhere in org mode -- no selection gets made. Adding
the following workaround fixes the problem:

;; This snippet from jisang-yoo on reddit to enable shift select in org
;; mode when cua-mode is on.
(eval-after-load "org"
    '(progn
       (eval-after-load "cua-base"
         '(progn
            (defadvice org-call-for-shift-select (before
            org-call-for-shift-select-cua activate)
              (if (and cua-mode
                       org-support-shift-select (not (use-region-p)))
                  (cua-set-mark)))))))
;; End jisang-yoo snippet

In GNU Emacs GNU Emacs 24.3.50.1 [3] org-support-shift-select works
essentially as documented, and the workaround is not required. :)

---

[1] GNU Emacs 23.3.1 (i386-mingw-nt5.1.2600) of 2011-03-10 on Windows XP
(5.1.2600) with Org-mode version 7.9.2 (7.9.2-48-gb7c5cf-elpa) of
2012-10-15.

[2] GNU Emacs 24.3.1 (x86_64-redhat-linux-gnu, GTK+ Version 3.8.2) of
2013-08-14 on Fedora 19 with Org-mode version 8.2.5h
(8.2.5h-6-g8e1386-elpa) of 2014-02-03.

[3] GNU Emacs 24.3.50.1 (Repository revision: 116400) of 2014-02-10 on
Fedora 19 and Org-mode version 8.2.5c (release_8.2.5c) of unknown date.

bug#5753: something, something, org-mode, shift-select, something

[Bastien]

nljlistbox2@gmail.com (N. Jackson) writes:

> 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.

Yes, sorry, I meant "emacs -Q" in my recipes.

I can't reproduce the bug with GNU Emacs 24.3.50.6, so it has probably
been fixed between 24.3.50.1 and 24.3.50.6.

I'll close it when you have a chance to build Emacs from current
trunk.

Thanks again for the detailed reports!

-- 
 Bastien

bug#5753: something, something, org-mode, shift-select, something

[N. Jackson]

Bastien <bzg@gnu.org> writes:

> nljlistbox2@gmail.com (N. Jackson) writes:
>
>> 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.
>
> Yes, sorry, I meant "emacs -Q" in my recipes.
>
> I can't reproduce the bug with GNU Emacs 24.3.50.6, so it has probably
> been fixed between 24.3.50.1 and 24.3.50.6.

Bastien, you misunderstood what I wrote (sorry).

I _did_ build 24.3.50(.1) from the current (yesterday's) trunk from
Bazaar.

And, assuming the failure of shift selection in cua-mode _is_ the bug
the OP was reporting (I was never clear about that), then the bug _is_
fixed using that build, as I wrote here:

>> In any case, with both recipes, Org behaves correctly in 24.3.50.1. 

and here:

>>     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-<left>    ; 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-<left> 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. :)
                                         ^^^^^^^^
> I'll close it when you have a chance to build Emacs from current
> trunk.

Lennart, I believe you were the original poster? Is the one above the
bug you intended to report? (I was confused by the discussion of
org-replace-disputed-keys, which doesn't seem to be a factor here.) And
if so, do you want to test on 24.3.50, or are you satisfied that the bug
is fixed?

> Thanks again for the detailed reports!

You're welcome, but clearly I need to improve my clarity! Thank you for
being there to do something about them.

Regards,
N.

bug#5753: something, something, org-mode, shift-select, something

[Bastien]

nljlistbox2@gmail.com (N. Jackson) writes:

> Bastien, you misunderstood what I wrote (sorry).
>
> I _did_ build 24.3.50(.1) from the current (yesterday's) trunk from
> Bazaar.

I was confused because my Emacs version is 24.3.50.6 so I thought
you had an much older one...

> And, assuming the failure of shift selection in cua-mode _is_ the bug
> the OP was reporting (I was never clear about that), then the bug _is_
> fixed using that build

Good, closing it now.

> You're welcome, but clearly I need to improve my clarity!

Well, I'm not a native english speaker and I sometimes read too
hastily, no problem!

-- 
 Bastien

bug#5753: something, something, org-mode, shift-select, something

[Lennart Borgman]

[-- Attachment #1: Type: text/plain, Size: 933 bytes --]

On Tue, Feb 11, 2014 at 6:12 PM, N. Jackson <nljlistbox2@gmail.com> wrote:

> Bastien <bzg@gnu.org> writes:
>
> > nljlistbox2@gmail.com (N. Jackson) writes:
> >
>
>> In Emacs 24.3.1 (as, I believe, in Emacs 23), the S-<left> 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. :)
>                                          ^^^^^^^^
> > I'll close it when you have a chance to build Emacs from current
> > trunk.
>
> Lennart, I believe you were the original poster? Is the one above the
> bug you intended to report? (I was confused by the discussion of
> org-replace-disputed-keys, which doesn't seem to be a factor here.) And
> if so, do you want to test on 24.3.50, or are you satisfied that the bug
> is fixed?
>

Thanks for notifying me, Jackwon. I believe it was that bug. (And if it was
not it will float up again. ;-) )

[-- Attachment #2: Type: text/html, Size: 2408 bytes --]