I have clean install of spacemacs. When I press escape to enter normal mode then immediately press u it will uppercase a word. If I wait a second, it will undo last action.
I'm assuming this is evil-mode or emacs key-chord feature in action. How can I change that behavior?
Spacemacs, particularly the develop branch should just work right out of box without the delay. However, I have found that this delay happens when I am running emacs inside of tmux. You should see if you are trying to run this inside tmux or screen, and if you are, see if this problem happens when you run emacs directly inside a terminal, without a terminal multiplexer.
If tmux is your problem, you can fix this with:
set -s escape-time 0
You'll have to find the equivalent in screen if that is what is happening.
See: https://bitbucket.org/lyro/evil/issue/69/delay-between-esc-or-c-and-modeswitch
Zeroing out my delay as Ho-Sheng Hsiao suggested has served me well, but as Wesley Baugh pointed out, that has the consequence of preventing the use of ALT-key modifiers in your editors.
The Emacs-evil FAQ addresses the problem, but not very succinctly, and without a concrete recommendation.
The Neovim FAQ has a more succinct explanation, and a specific recommendation:
set-option -sg escape-time 10 # millisecond delay
Related
I tried adding the below to ~/.tmux.conf so that i could use Shift+arrow keys to jump across windows, but doesnt work.
bind -n S-Left previous-window
bind -n S-Right next-window
This is not under vim as I saw in other qns answered in stackoverflow. Even if I tried to use this for navigating across panes it doesnt work. However, if I use the Alt+arrow keys it works like a charm.
Any way I could get the Shift+arrow mappings work?
Although PuTTY sets the TERM variable to xterm, its behavior does not in fact match xterm's behavior link
There is a bug in PuTTy which causes binding of shift key to not work link
Your can switch to KiTTy, a fork of PuTTY, which solves the problem you are facing,
Maybe something is wrong with my configuration, but when I search my tmux scrollback by typing:
prefix-[
/
<search target>
instances of search target that are interrupted by line breaks (because the tmux pane or terminal window is too narrow or search target is very long, or it's just bad luck) are not found. If I resize the pane so that an instance of search target is not interrupted by a line break, then tmux finds it.
Is there a way to perform a search with tmux that finds stuff in wrapped lines?
By the way, this is a pretty bad bug and reduces my confidence in tmux. It should not be possible to perform a search, regardless of method or configuration, that fails to finds instances of the search target. Searches are often used to confirm the presence or absence of something, and in a way tmux is providing a false negative test result. I guess I should stick with grepping files to be safe. I know there is a way to put the tmux scrollback in a file.
Kind of sad.
I might just be thick this morning but I cannot seem to get html2haml with the -s or --stdin option to work.
Running html2haml or html2haml -s on the command line looks like I get put into some input mode but with no way to escape but ^c. This causes an interrupt and nothing more happens.
You need to use Ctrl+D to send end of file so html2haml knows the input is finished, rather than Ctrl+C which interrupts the process. (These keys are actually the defaults and may vary, but are probably right for you).
I use tmux and find one problem of it.
For example, I make 2 panes within 1 window under tmux.
In one pane, I compile Linux kernel and as you know it will output a lot of message there.
During the compilation, in another pane of tmux, when I tried to input some command, it will react very slow.
How to solve this?
Thanks!
BR
With two panes, tmux has to update two portions of the screen at once. My suggestion is to let the compile running in a separate window, so that tmux doesn't need to render so much output to the visible screen, and configure some sort of monitor on the compile window so you will be notified when it is finished.
As chepner says, tmux has to send a lot more characters to update a bigger part of the screen. In my case, enabling ssh compression reduced this kind of slowness quite a lot. You can give it a try with:
ssh -C user#host
or put Compression yes into your ~/.ssh/config to make it permanent.
Question asked in June.. 2012?! ^^
If you are using X11, try a different terminal. Besides those based on xterm there are KDE's konsole and it's variants (like yakuake drop-down terminal) and GNOME's VTE and offsprings (like guake drop-down terminal :)), display update speed can be very different.
Furthermore, a rate limiting feature was implemented in march which will be in the 1.7 release out soon.
I am implementing my own shell. But to supprt for command history, I need to use monitor up/down arrow key as in standard shells. Please tell me how to handle arrow keys as input or does these keys generate signals? Please elaborate.
Arrows and other special keys send you special strings that depend on the terminal being used or emulated. To deal with this most simply, you could use a library such as termcap. Even simpler, given your stated purpose (command history support), would be to use readline, which basically does it for you (and lets the user customize aspects of their preferred mode of working across the many applications that link to the same library).
It depends on how gnarly you're expected to go. Worse case, you're writing the keyboard interrupt handler. Best case, something like readline.
Check with your prof for direction here. Also check your course materials to see if the prof has given links/examples regarding this.
Does the assignment specifically say you need to have a "cursor key driven" command history?
Simple option is to mimic the shells fc e.g.
$ ls
... file listing ...
$ fc -l
1 ls
2 fc -l
$ fc -r 1
... file listing ...
and (while I'm presenting established ideas as my own, might as well go all the way) to be able to edit the command line you could use
fc -e start end
to write the history from start to end into a file, launch an editor and then execute the resulting file as a script. This way your shell is not using a library, but launching commands and executing scripts, which is what shells are supposed to do anyway.