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.
Related
Program that I write often crashes leaving terminal in a S-Lang library state (similar to ncurses). I would want to add a check into development's branch Makefile main all target for such an improper state and and an automatic invocation of reset command. How to approach this task?
reset does two things; you can write a shell script which detects one of them:
it resets the terminal I/O modes (which a shell script can inspect using stty)
it sends escape sequences to the terminal (which more often than not will alter things in the terminal for which there is no suitable query/report escape sequence).
For the latter, you would find it challenging to determine the currently selected character set, e.g., line-drawing. If the terminal's set to show line-drawing characters, that's the usual reason for someone wanting to run reset (e.g., cat'ing a binary file to the screen).
There happens to be a VT320 feature (DECCIR) which can provide this information (which xterm implements):
but with regard to other terminals, you're unlikely to find it implemented:
(iTerm2 doesn't do it)
(nor does VTE). You can read an extract from the VT510 manual describing the feature on vt100.net
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
The program that I am trying to run takes the form program_name --arg=/some/path/goes/here, but zsh cannot perform tab completion on that path when it is in the argument flag. I end up having to type progra<TAB> /so<TAB>/pa<TAB>... to complete the path and then go back to add the --arg= part of the command. Is there a more efficient way to go about doing this?
It's likely that zsh is still trying to do file completion in your situation, it's just considering the --arg= to be the initial part of the file name causing it to not find any matches. Since there aren't any universal rules for how commands will interpret their arguments the safest option is for the shell to not make any assumptions about those arguments.
Many commands which use that type of syntax will work the same if you use a space rather than the = sign, such as program_name --arg /some/path/goes/here. Since that would be a separate argument the shell should be able to do file completion without issues.
Depending on how you have zsh configured, it may also work to use setopt MAGIC_EQUAL_SUBST. I normally have that option set and get the behavior that you are looking for, but get the behavior that you currently experience if I unset that option. But, if I use zsh -f to skip loading my configuration just enabling that option isn't sufficient so there is apparently something else in my config that was necessary, possibly just the enabling of the completion system which you would likely have done already. There could be cases where this would result in undesirable behavior, but I haven't run into any in the many years that I've been using zsh with that option set.
A more complicated option would be to write a completion function for that command which tells zsh that that option takes a file name as the argument.
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.