Skip to content
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

ESC in layouts microstate and Org agenda buffer #4562

Closed
darkfeline opened this issue Jan 12, 2016 · 9 comments
Closed

ESC in layouts microstate and Org agenda buffer #4562

darkfeline opened this issue Jan 12, 2016 · 9 comments
Labels
Enhancement ☺ stale marked as a stale issue/pr (usually by a bot) Transient-state

Comments

@darkfeline
Copy link
Contributor

Exiting the layouts microstate (SPC l) using ESC while in the Org agenda buffer interprets the ESC as a regular Emacs ESC (as meta modifier).

I think it's because ESC isn't handled evilly in evilified state? Would this be considered a bug or desired behavior of evilified state?

System Info

  • OS: gnu/linux
  • Emacs: 24.5.1
  • Spacemacs: 0.105.7
  • Spacemacs branch: master (rev. 8a94bbf)
  • Distribution: spacemacs
  • Layers:
((auto-completion :variables auto-completion-enable-sort-by-usage t)
 better-defaults spell-checking syntax-checking semantic typography
 (chrome :variables edit-server-new-frame nil)
 dash elfeed erc finance gtags ibuffer mu4e org ranger
 (shell :variables shell-default-shell 'shell shell-default-term-shell "/usr/bin/zsh" shell-default-height 50)
 spacemacs-layouts version-control git github c-c++ clojure common-lisp emacs-lisp go html javascript latex lua markdown python ruby shell-scripts sql yaml evil-cleverparens mir-bbdb mir-magit-annex mir-pass mir-remind-to-diary mir-mpc)
@TheBB
Copy link
Contributor

TheBB commented Jan 12, 2016

This is an intended feature of all microstates: any key that is not recognized by the microstate exits it, and then that key does whatever it's supposed to do elsewhere.

@syl20bnr
Copy link
Owner

I think it's because ESC isn't handled evilly in evilified state? Would this be considered a bug or desired behavior of evilified state?

It is fixed for Magit buffers, maybe we could generalize this.

@syl20bnr
Copy link
Owner

@TheBB you are right but I guess the issue is not that it exit the micro-state but that ESC acts like Meta.

@darkfeline
Copy link
Contributor Author

Alternatively, could the layouts microstate be bound to SPC l . like many of the other microstates and have SPC l be a prefix for the layout commands? Having SPC l be a microstate and this current evilified behavior is doubly bad because one would do SPC l o o to switch to the Org layout and then either press C-g or (mistakenly) ESC C-g to exit the microstate.

In theory one could exit the microstate naturally without ESC but there's always the chance that the next key you press is actually bound in the microstate and performs undesired behavior, and tapping ESC a few times to return to a normalized state is natural Vim usage.

@StreakyCobra
Copy link
Contributor

I agree that SPC l shouldn't be a microstate by default. It exits when a non-existing key is pressed, and j/k are not mapped, but in bepo these up/down keys are t/s and both are bound to something in spacemacs layout micro-state..

Having SPC l . for the microstate would be consistent with the other concepts. #4225 will hopefully allows to let people define which keybindings should enter the micro-state.

@syl20bnr
Copy link
Owner

I don't agree with removing the micro-state from SPC l but I agree we may have to tweak it (1) and I'm open to an experimentation (2).

(1) What you propose here is to set the :persistent t keyword and add ESC :exit t to the layout micro-state.

(2) The micro-state provides an important thing which is the list of layouts. As far as I know, out of the box we don't have an easy way to display some text in the minibuffer when pressing a command prefix, i.e. pressing SPC l display a nice list in the minibuffer (or even in the header). BUT with @justbur knowledge about prefixes in which-key I am hopeful that we could provide such feature. So here is the picture:

  • SPC l is a prefix not bound to a micro-state
  • we have some package that allows to register functions to echo messages in the minibuffer or header when a given prefix is pressed, this package takes care of the dirty thing like hiding the echo of the current pressed keys and replace the minibuffer/header content with the result of the registered function
  • pressing SPC l 1 will then echo two messages:
    • SPC l display the list of layouts with the current one highlighted
    • 1 update the message with the new active layout (no need to use the package for 1 since it is directly bound to the switch function)
  • With this design I can stop at SPC l a little bit before deciding where to go, or I can rush to SPC l 1
  • Some sort of time out of the printed message would be cool
  • for example SPC l n is bound to a micro-state but only to cycle with n and p. Could use the same timeout value as the prefix message (require hydra for this).

cc @justbur :-D

@syl20bnr
Copy link
Owner

Maybe it could be a feature provided by which-key because the function result should be concatenated with which-key messages. Or we only use the header.

@justbur
Copy link
Contributor

justbur commented Jan 13, 2016

I don't use layouts yet, so I'm not really familiar with the issue, but if you dynamically bound a key to a map under SPC l which-key would show the layouts in the popup. Highlighting the current layout would be slightly more work, but not hard.

@github-actions
Copy link

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!

@github-actions github-actions bot added the stale marked as a stale issue/pr (usually by a bot) label Feb 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement ☺ stale marked as a stale issue/pr (usually by a bot) Transient-state
Projects
None yet
Development

No branches or pull requests

5 participants