Briefly:
I would love to add a status bar that sticks to either the bottom or top of my terminal window that provides glancible information (e.g. battery life, signal strength, email count, $PROMT_COMMAND, etc.). Essentially, this will allow the terminal to be opened up to fullscreen and have all the information I could possibly want easily glancible while letting me continue all of my necessary terminal work as normal. I use a mac primarily, but would prefer a *nix compatible solution.
More detail (and what I already tried):
I am a big terminal user and only recently (within a day or two) started using tmux, so I understand that many of you may suggest that I try to use a multiplexer like screen or tmux. While tmux is starting to get very useful to me, it has it's limitations such as a limit to a single-row status bar, which is not ideal since I would want to keep the tab's bar clean without half of it being eaten up by information. Also, I would want to add $PROMPT_COMMAND which displays the current directory, and that could easily eat up most of the status bar depending on where I am in the system.
Also, I tried screen for a bit, which let's you have a hardstatus and a caption which is close to what I want, but it's development seems to have halted. Furthermore, the patch for vertical split panes messes up the graphics of a two-row status bar (very ugly).
Therefore, I think it would be preferable to have a background process running that updates a status bar on part of the screen above my multiplexer ... unless of course tmux has a multi-row status bar implementation that I haven't figured out yet.
I would love to hear about any of your possible solutions, or even your own personal setups if you think it works well for you. Thank you all for any possible help.
A couple of options:
You could run tmux inside tmux (with different configurations; you can use -f to specify a configuration file.)
You could use the tab title, though that's probably not wide enough to include everything you want. (Even if there's only one tab, you can show the tab bar in fullscreen mode). You need to tell tmux to pass the title through; see set set-titles and set set-titles-string.
I'd suggest you use both - put the current directory in the tab title and all the other status info in a separate line maintained by tmux, that way you can just skip the second part when you're not using a full-screen terminal.
I have battery info in mine,
You can get copies of the files you'll need at
https://github.com/richo/dotfiles/blob/master/tmux.conf
and
https://github.com/richo/dotfiles/blob/master/bin/battery
(Make sure that battery is executable and in your PATH)
It'll show you battery percentage in blue (charging), red (discharging) or not at all (fully charged)
Related
I have a kinda weird question. Sometimes in some of my long-lived tmux sessions I'll have a window where the history will get kinda "stuck"
So, to clarify, that's a (bash) shell, inside a pane, inside tmux, and that shell has been running for a while.
I have my scrollback set high and I use it all the time, so I know how to use it and how it works in tmux. But sometimes something will happen and I'll always get the same history when I scroll back no matter what I print.
So for example, I'll run something like seq 1 100 and I'll only see the numbers 76 to 100 in the pane, but when I scroll up I don't see 75, I'll see the result of some git command I ran a while back. No matter what I run, when I scroll up it's that same output of that same git command, or whatever happens to have been up there when it broke.
I can exit the shell and re-open it, that works, but I'd rather not. I'm wondering if there's some kind of term control character or something, or broken curses code, or something that maybe didn't clean up properly in my terminal that would have left me in this in-between state where new lines are shown, but not added to the history? Any idea? I tried running reset, but it doesn't seem to have fixed it.
Does this make sense to anybody? I'd love to learn something new about how shells communicate with terminal emulators that makes this make sense.
Thanks!
I am trying to create a program which will have live updates from some data source. And I also want to wait for user input just like a normal terminal. Right now, whenever there is update, I will print the content and print the prompt message for input again which create something like this:
Enter command >
This is a live update message
Enter command >
This is a multi-line li......
......ve update message
Enter command > quit
Bye bye!
The problem is that for every live message I received, I will print it and the "Enter command >" will be displayed again again and again, which is not desired. I want the live update to be update on the main part of the terminal, while the "Enter command >" always stay at the bottom
The closest package I can found on Github is https://github.com/gizak/termui but most of the examples inside is trying to display text, gauge and graphs. So I am not quite sure how to get started.
Is there any package or example of the termui package to achieve this? Thank you.
With github.com/gizak/termui you're heading in the correct direction.
To understand why you can't get that
I want the live update to be update on the main part of the terminal, while the "Enter command >" always stay at the bottom
part sorted out, a little excursion to the history of computing is due. ;-)
The thing is, the mode your teminal emulator¹ works by default originated
in how computers would communicate to the operator in the era which predated
alphanumeric displays — they would print their responses using a line printer. Now think of it: a line printer works like this: it prints whatever is sent to it on a roll of paper. What was output, was output.
The new output always appears physically below the older.
When alphanumeric displays (screens) came into existence they
naturally continued to support this mode:
the line text to be output was rendered at the bottom of the screen
with the text above it scrolled upwards.
That's what you see in your typical terminal emulator all the time when you're working in the command line of a shell (such as bash) running by the emulator window.
This, default, work mode of a terminal is called "canonical" or "cooked".
Then came more advanced displays, for which it was possible to change
individual positions on the screen — identified by their column and
row numbers.
This changed the paradigm of how the information was output: the concept
of a so-called "full-screen application" was born.
Typical examples of them are text editors such as Vim and Emacs.
To support full-screen text output, terminals (and terminal emulators)
were adapted by implementing certain extensions to their protocols.
A full-screen application first requests the terminal to switch into another
mode called "raw", in which the terminal sends most of what is input by the
user directly to the program running on the terminal.
The program handles this input and orders the terminal where and what
to draw.
You can read this good summary
of the distinction between the both modes.
As you are supposedly suspecting by now, to be able to keep some block
of information at a certain fixed place of the terminal's text screen,
you want your program to be a full-screen program and use the terminal's
raw mode and its special commands allowing you to directly modify
text at certain character cells.
Now the problem is that different terminals (and terminal emulators)
have different commands to do that, so there exist libraries to isolate
the programs from these gory details. They rely on the special "terminal
information databases" to figure out what capabilities a terminal has
and how to make it do what the program asks.
See man terminfo for more background.
The most widely known such library (written in C) is called ncurses,
and there exist native solutions for Go with supposedly the most visible
one being github.com/nsf/termbox-go.
The github.com/gizak/termui makes use of termbox-go but for you it might
suffice to use the latter directly.
¹ Chances are very high you're not sitting at
a real hardware terminal
connected to a UNIX® machine but are rather working in a GUI application
such as GNOME Terminal or xterm or Termial.app etc.
These are not "terminals" per se but are rather
terminal emulators —
that is, pieces of software emulating a hardware terminal.
Looking for a way to control text/cursor highlighting colors when in vi-mode in tmux. I can not seem to find many answers from googling around. I love tmux and use this feature quite a bit, and I have been living with this flaw for some time and still have not been able to find a solution. You can view my dotfiles here. Keep in mind that my master branch is my OSX setup, and I have an "arch" branch for my Arch linux setup. The issues occurs on both systems. Though the colors are slightly different, but not by much.
Here is current symptoms: (both systems) I am in a tmux session, I want to enter into vi-mode for either searching or copying some text. When copying text (hitting v while in vi-mode for visual) the highlighted text and background are both black. So I can't see the text I am highlighting. Or while searching (hit "/" while in vi-mode for searching) my background and text on the entire line where my prompt is for typing the text I want to search is all black. So I have no idea what text is actually in the search. If I mis-type something due to fat fingers and nothing returns in my search, it can be frustrating. One last symptom (which is a minor one, but would be nice to solve) When I do search, I get absolutely no highlighting over than my normal cursor. Not like my vim set up where it highlights currently found, and all other matches.
Here is what the desired fix would look like: Searches would highlight in some shade of yellow or orange on all matched text. Searching prompt to type in search text would be at least readable. Anything but Black on Black. Highlighting text while selecting what to copy in visual mode again anything readable, no Black on Black.
Other things to note: I typically have mouse-mode on in tmux to promote keyboard-driven approach and not allow any selection of text via mouse selection. But when I do toggle this feature off and can then select text via mouse, the highlighted text background is white and text is black. While readable, would still wish to know how to control this color as well. Also (not sure any vim settings actually carry over to tmux) but everything works as desired while actually in vim. Just in case vim settings here. Same note about branches.
Most of my tools are latest versions afaik. This includes Tmux 2.1. I do not have full list of versions of my tools as of right now. If this may play a part in debugging let me know and I'll reply with versions. For what its worth other tools that might be in conflict is my shell I use zsh with on-my-zsh. On my mac I am using iTerm2, on arch I'm using URxvt. Doubt any of my .Xresources matter since it also happens on OSX.
Any help is greatly appreciated. Thanks in advance.
I've got emacs in front of me.
I've run a find-grep, and it's got many hits, which are displayed in a window. The file names are displayed in green as hyperlinks.
I make that the only window, with C-x 1.
If I click on a file name, the window splits vertically, and the file with the found text is displayed in the other window.
If I click on further filenames, then the new file replaces the old file, which is what I want to happen.
So far, so good...
However if I resize the windows, then emacs will periodically (when I click) split one of the two windows again, rendering the display difficult to read. It will then cycle opening new files between the two new windows. Occasionally it will open more windows and make the situation worse. If I close any of these new windows they just get reopened again.
In fact sometimes this perverse behaviour happens even if I don't resize anything. It just seems to happen more often if I do.
I would like emacs to stop buggering around and just have one find-grep window and one 'display' window, and always replace the display window with the new file. I would also like to be able to set these windows to the sizes that seem most convenient.
Is there any way to achieve this?
Or can anyone point me to an essay on how the whole (replace the contents of this window/replace the contents of a different window/create another window by splitting) thing works, so I can go and hack it sane.
Short fix:
Try doing this
(setq split-height-threshold nil
split-width-threshold nil)
This will prevent Emacs from splitting windows automatically (horizontally or vertically). This might be undesirable in other situations, but this should do the job. Try it for a week or so and see if it disrupts your flow.
Also, I found that if the point was in one of the windows, and I clicked on a link, the file opened up in the next window (if any).
So, if you want to make the file open in the right window (when you have more than one window), you can ensure that the point is in the window before the window you want.
Longer answer:
OK. I was able to reproduce the problem. The thing is the window showing the files is pretty big (wide or tall) because you resized it and Emacs sees that the width or height is greater than the respective threshold and splits it likewise. So, we have to either make the threshold higher or disallow the behaviour completely.
And, just to answer the last few questions:
To get current window - (selected-window)
To get next window - (next-window)
To select a window - (select-window foo-window)
To get the buffer of the current window - (current-buffer)
To get the buffer of some window - (window-buffer foo-window)
To set a buffer for a window - (set-window-buffer foo-window bar-buffer)
I'm sure you can hack together decent window/buffer management functions using these functions.
You can use C-h f to get more details on each of these functions.
Also check out the Elisp manual - http://www.chemie.fu-berlin.de/chemnet/use/info/elisp/elisp_26.html
I'm having some issues with my Cygwin terminal when I run 'less'. 'less' works fine, but when I come out of it, all the screen buffer history of the terminal is lost. Any suggestions?
I'm running Cygwin on WinXP.
Try running as less -X, or set the LESS environment variable to -X.
It has nothing to do with bash. What's being erased is the text displayed by your terminal emulator.
Like other full-screen programs, less saves the terminal state (including any displayed text and the cursor position) when it starts, and restores it on exit.
It does this by printing the strings defined by the smcup and rmcup terminfo entries.
These depend on the value of the $TERM environment variable.
If these strings aren't printed, or if they're configured to something that doesn't save and restore your terminal state, then less will replace whatever was on your screen by the contents of the file you want to view, and then not restore it.
Using the -X option to less (as suggested by the answer you accepted tells less not to print the smcup and rmcup strings -- which I would expect to cause the problem you're trying to solve.
If you want to save and restore your terminal state (which means that the output produced by less will vanish when you quit), you need to make sure that your $TERM environment variable is set to something with proper smcup and rmcup settings. I find that setting it to xterm usually works.
If you're ambitious, you can create your own terminfo entry and use the tic command to "compile" it to the binary format used by the system.
Dawid Ferenczy's answer suggests another possible cause for the problem; it's not something I've ever run into myself.
(Opinions differ widely on whether saving and restoring the terminal state is a good thing. This blog entry was written by someone who intensely dislikes it. Personally, I like it; if I want to run a full-screen command and keep its output visible while I'm doing something else, I just launch it in another window.)
(The original poster hasn't been on the site in about 2½ years, so we shouldn't expect any feedback, but these answers are likely to be useful to others.)
I had the same issue on my new laptop. I have been using Cygwin on the 64bit Windows 7 for a long time and I never experienced this problem. But on the new fresh system (also 64bit Windows 7) the same Cygwin with the same configuration cleared the screen buffer whenever I quit LESS, MAN, VIM etc. And it bothered me very much. Because I'm using Cygwin inside ConEmu terminal emulator, I suspected ConEmu. After a lot of hours comparing everything what potentially could be the cause (environment variables, configurations, software versions etc.), I had a conversation with the ConEmu's author (and he was really great, exemplary support for the free software!). And we finally found the cause.
The only difference (or one of few) was in the display size. The old laptop has a screen resolution of 1366 x 768 pixels, while the new one has 1920 x 1080. And I'm using the whole screen for the terminal window. It's really strange, but if the terminal window height is greater than cca 62 lines, the screen buffer is cleared after quitting the LESS, VIM etc. No matters if Cygwin is executed inside the ConEMu or plain cmd.exe. Making the terminal window smaller solved the problem. Window height of 62 lines seems to be fine for me. Also, with some of greater height values, the LESS process sometimes crashed.
It seems that it's a problem of the Cygwin.
The whole story you can read here.
Maybe it could help somebody. It took me really a lot of time to solve that. While the solution (or rather workaround) is such damn stupid :)