Do we need to bind to both RET and <return> variants?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Do we need to bind to both RET and <return> variants?

Kaushal Modi
Hello,

For the return key (for Emacs GUI) and the C-m variant RET (in nowindow
mode, terminal) to both work, should we be binding to both RET and <return>
variants?

I am sure that this issue comes up now and often, but I cannot find an
older thread with a definitive answer.

Recently this came up on Org mode thread. Earlier the <return> variant of
bindings were used, but then S-<return>, etc. did not work for a user using
Emacs in terminal mode, so the binding was changed to S-RET. But now ..
that doesn't work for Emacs GUI users :)

Ref: https://lists.gnu.org/r/emacs-orgmode/2019-01/msg00318.html

So what solution would make everyone happy?

--
Kaushal Modi
Reply | Threaded
Open this post in threaded view
|

Re: Do we need to bind to both RET and <return> variants?

Stefan Monnier
> For the return key (for Emacs GUI) and the C-m variant RET (in nowindow
> mode, terminal) to both work, should we be binding to both RET and <return>
> variants?

No, if you don't care about the difference, then bind only RET (which
will also apply to `return` because `return` is remapped to RET if
there's no binding specifically for it).

Same with TAB vs `tab`.

It's important to follow this convention, otherwise you mess up every
other package which does follow the convention (since your `return`
binding will then take precedence even if it's in a low-precedence map).


        Stefan


Reply | Threaded
Open this post in threaded view
|

Re: Do we need to bind to both RET and <return> variants?

Kaushal Modi
On Wed, Jan 23, 2019 at 5:53 PM Stefan Monnier <[hidden email]>
wrote:

>
> No, if you don't care about the difference, then bind only RET (which
> will also apply to `return` because `return` is remapped to RET if
> there's no binding specifically for it).
>

But it did not work that way for me.

Earlier I did not have a S-<return> binding in my config. So once the
binding changed to S-RET (in org-mode-map) upstream in Org, S-<return>
stopped working for me altogether (Emacs GUI).

Then C-h k and typing S-<return> should say interpret that as just RET:

    RET (translated from <S-return>) runs the command
modi/org-return-no-indent

I have bound modi/org-return-no-indent to C-m.

So to fix this I had to add the <return> bindings manually to my config:

    (bind-keys
     :map org-mode-map
     :filter (org-at-table-p)
     ("S-<return>" . org-table-copy-down))

    ;; https://lists.gnu.org/r/emacs-orgmode/2019-01/msg00312.html
    ;; Add the <return> variant of bindings so that they work on Emacs
    ;; GUI too.
    (bind-keys
     :map org-mode-map
     ("M-S-<return>" . org-insert-todo-heading)
     ("ESC S-<return>" . org-insert-todo-heading)
     ("M-<return>" . org-meta-return)
     ("ESC <return>" . org-meta-return))

Any tips on what could be causing S-<return> to be auto-translated to just
RET, and not use the upstream Org source defined S-RET binding?
Reply | Threaded
Open this post in threaded view
|

Re: Do we need to bind to both RET and <return> variants?

Stefan Monnier
> Earlier I did not have a S-<return> binding in my config. So once the
> binding changed to S-RET (in org-mode-map) upstream in Org, S-<return>
> stopped working for me altogether (Emacs GUI).

This applies to RET/TAB/DEL but not when modifiers are applied to them
(hysterical raisins and all).


        Stefan

Reply | Threaded
Open this post in threaded view
|

Re: Do we need to bind to both RET and <return> variants?

Kaushal Modi
On Wed, Jan 23, 2019 at 8:51 PM Stefan Monnier <[hidden email]>
wrote:

> > Earlier I did not have a S-<return> binding in my config. So once the
> > binding changed to S-RET (in org-mode-map) upstream in Org, S-<return>
> > stopped working for me altogether (Emacs GUI).
>
> This applies to RET/TAB/DEL but not when modifiers are applied to them
> (hysterical raisins and all).
>

So for the Modifier + RET bindings, we need to define the Modifier +
<return> bindings too, right?

If so, I can convey this to the Org mailing list and get the bindings
fixed.. have not just S+RET, but also S+<return>, and so on for all
modifier + RET bindings.
Reply | Threaded
Open this post in threaded view
|

Re: Do we need to bind to both RET and <return> variants?

Stefan Monnier
> So for the Modifier + RET bindings, we need to define the Modifier +
> <return> bindings too, right?

Actually, for most modifiers <mod> + RET simply doesn't exist (in the
sense that the terminals will typically simply send the same byte
sequence as if you had typed RET).

And AFAIK for M-RET (which is also known as `ESC RET`) we do have
a corresponding remapping from M-return to M-RET, so you only need to
bind M-RET and not M-return.

If you find this messy, it's because it is.

Other messy details include the fact that M-RET is the same as `ESC
RET`, but M-left is not the same as `ESC left`.

If someone wants to straighten this out, it'd be great.


        Stefan