New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider making all top level bindings non-default #164

Closed
jasonm23 opened this Issue Sep 11, 2016 · 8 comments

Comments

Projects
None yet
3 participants
@jasonm23

jasonm23 commented Sep 11, 2016

There's a few top level bindings in markdown-mode e.g. C-<left> and C-<right>

These have annoyed me somewhat over the years, but I noticed people having issues with these bindings, so I think it's worth opening discussion at least.

While disabling some of these might cause problems for some existing users, a command or customizable setting to enable these top level bindings, could be provided.

Since markdown-mode otherwise does a fantastic job of keeping bindings on C-c ... it would be nice if it always avoided stepping on the top level keymap.

@syohex

This comment has been minimized.

Show comment
Hide comment
@syohex

syohex Sep 11, 2016

Collaborator

markdown-mode does not assign any commands to C-<left>, C-<right>. What commands did you say about ?

Collaborator

syohex commented Sep 11, 2016

markdown-mode does not assign any commands to C-<left>, C-<right>. What commands did you say about ?

@jasonm23

This comment has been minimized.

Show comment
Hide comment
@jasonm23

jasonm23 Sep 12, 2016

See my edit - M- & M-

But the suggestion isn't really about any specific binding.

Just suggesting to remove top level bindings, and have them enabled on demand instead.

jasonm23 commented Sep 12, 2016

See my edit - M- & M-

But the suggestion isn't really about any specific binding.

Just suggesting to remove top level bindings, and have them enabled on demand instead.

@syohex

This comment has been minimized.

Show comment
Hide comment
@syohex

syohex Sep 12, 2016

Collaborator

Hmm, I suppose top level bindings are inspired by org-mode. However org-mode does not have such configuration.

Collaborator

syohex commented Sep 12, 2016

Hmm, I suppose top level bindings are inspired by org-mode. However org-mode does not have such configuration.

@jasonm23

This comment has been minimized.

Show comment
Hide comment
@jasonm23

jasonm23 Sep 12, 2016

That shouldn't really have relevance to Markdown mode. It's supposed to be a text markup format, not a wide reaching app like Org

That said, there are certainly a few top level org-mode bindings which are also obtrusive. But given that Org has such a broad scope it's not so straight forward to know where to draw the line.

Markdown isn't ambiguous in that way, so it's best to avoid trying to draw tenuous parallels.

Uniformity of the users chosen editing experience, and default and user defined top level bindings should be respected.

On 12 Sep 2016, at 12:37 PM, Syohei YOSHIDA notifications@github.com wrote:

Hmm, I suppose top level bindings are inspired by org-mode. However org-mode does not have such configuration.


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

jasonm23 commented Sep 12, 2016

That shouldn't really have relevance to Markdown mode. It's supposed to be a text markup format, not a wide reaching app like Org

That said, there are certainly a few top level org-mode bindings which are also obtrusive. But given that Org has such a broad scope it's not so straight forward to know where to draw the line.

Markdown isn't ambiguous in that way, so it's best to avoid trying to draw tenuous parallels.

Uniformity of the users chosen editing experience, and default and user defined top level bindings should be respected.

On 12 Sep 2016, at 12:37 PM, Syohei YOSHIDA notifications@github.com wrote:

Hmm, I suppose top level bindings are inspired by org-mode. However org-mode does not have such configuration.


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

@syohex

This comment has been minimized.

Show comment
Hide comment
@syohex

syohex Sep 12, 2016

Collaborator

IMO, I disagree this suggestion. I think the user should disable such key bindings by himself/herself, if he/she annoys them.

Collaborator

syohex commented Sep 12, 2016

IMO, I disagree this suggestion. I think the user should disable such key bindings by himself/herself, if he/she annoys them.

@jasonm23

This comment has been minimized.

Show comment
Hide comment
@jasonm23

jasonm23 Sep 12, 2016

The problem with this is that there are extensive bindings on C-c etc. which is IMO where they belong.

Markdown is as close to plain text as we can be.

Please reconsider the suggestion thoughtfully.

jasonm23 commented Sep 12, 2016

The problem with this is that there are extensive bindings on C-c etc. which is IMO where they belong.

Markdown is as close to plain text as we can be.

Please reconsider the suggestion thoughtfully.

@jrblevin

This comment has been minimized.

Show comment
Hide comment
@jrblevin

jrblevin May 24, 2017

Owner

Sorry for the long delay in responding. Just a quick update...

When I added the keybindings in question, they were indeed inspired by Org mode. Until you opened this issue I didn't know that M-<left> and M-<right> were even bound (I've always used M-f and M-b). I'm closing in on a v2.3 stable release and after that I'm planning to add some new features which will involve re-thinking the existing keybindings anyway. So, I understand the concern and will either change the keybindings (e.g., by combining the functionality into other keys) or add a custom variable to enable/disable the toplevel keys.

Owner

jrblevin commented May 24, 2017

Sorry for the long delay in responding. Just a quick update...

When I added the keybindings in question, they were indeed inspired by Org mode. Until you opened this issue I didn't know that M-<left> and M-<right> were even bound (I've always used M-f and M-b). I'm closing in on a v2.3 stable release and after that I'm planning to add some new features which will involve re-thinking the existing keybindings anyway. So, I understand the concern and will either change the keybindings (e.g., by combining the functionality into other keys) or add a custom variable to enable/disable the toplevel keys.

@jrblevin jrblevin closed this in 9c7c0c4 Jun 21, 2017

@jrblevin

This comment has been minimized.

Show comment
Hide comment
@jrblevin

jrblevin Jun 21, 2017

Owner

The list/outline editing commands and the promotion/demotion commands have now been removed from the top-level positions. Previously they were at:

M-<left>    M-S-<left>
M-<right>   M-S-<right>
M-<up>      M-S-<up>
M-<down>    M-S-<down>

The commands have been consolidated so that they work on list or heading subtrees, depending on context, and are now bound under C-c:

C-c <left>
C-c <right>
C-c <up>
C-c <down>
Owner

jrblevin commented Jun 21, 2017

The list/outline editing commands and the promotion/demotion commands have now been removed from the top-level positions. Previously they were at:

M-<left>    M-S-<left>
M-<right>   M-S-<right>
M-<up>      M-S-<up>
M-<down>    M-S-<down>

The commands have been consolidated so that they work on list or heading subtrees, depending on context, and are now bound under C-c:

C-c <left>
C-c <right>
C-c <up>
C-c <down>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment