I found that if I run :set nonumber in terminal buffer, the option only applies to that terminal buffer, not window I run the command.
Neovim's help doc says that 'number' is a window-local option, But it doesn't seem right when dealing with terminal buffers.
Is the option 'number' can be treated as buffer-local option or terminal-local option?
If so, how can I set terminal-local options?
Related
When I use the Command in Auctex C-c C-c, it brings up a list of possible commands. It will usually select a reasonable default (e.g. Command: (default View)), however, when I press RET, it selects whatever is selected in the list below. I suspect this behavior is caused by one of the following packages I have installed
flx-ido
ido-ubiquitous
ido-vertical-mode
smex
To be honest, I used pieces from others' .emacs, so I'm not sure which of the customizations are causing this.
You do not have to deactivate it. You can type C-j to accept the current entry. If the current entry is empty, it will select the default.
It was ido-ubiquitous. Deactivating fixed it
Every time I start the interpreter for a programming language (lets consider python in this case) emacs opens the interpreter in the window which is not current. Note that I have two windows open, so the interpreter is always opening in the opposite window that I am currently in. This is annoying because then I always have to switch windows after I open an interpreter...
How can I get the python interpreter to open in the current window inside emacs?
Can I solve this problem generally for other programs/shells/buffers that do not open in the current window?
I note that this also happens frequently with other emacs commands (such as C-h v and the description of the variable opens in the window that is not current)
All help is greatly appreciated!
Interpreter-buffers connect with a process. If not already there, it must be a different one than the buffer called from - otherwise the current buffers contents is lost.
You might be interested in org-mode, org-babel, which provides a way to insert results in current buffer when executing source-code.
With python-mode.el, set py-switch-buffers-on-execute-p to non-nil. After M-x py-shell, cursor is in new shell.
If py-split-windows-on-execute-p is nil, M-x py-shell should switch to Python shell without splitting the window. See more options if re-using an existing py-shell etc.
With python.el, M-x run-python switches into the Python-shell.
See also customizable variable pop-up-windows.
I use gdb-many-windows in emacs for my debugging.
Recently, I discovered how to move a buffer to another X window using C-x 5 2.
I find it convenient: since I use multiple displays, I can have one window with source and variables, and gdb's command line in another window.
But my problem is when I perform a step-by-step in gdb: when it opens another source file, it does that in the same window where the command line is located, while I expect it to be updated in the other window.
Does anybody know how to tweak gdb or emacs to do that? Thanks,
The value display-buffer-reuse-frames does address exactly this "issue". Session-wide setting in configuration file:
(setq-default display-buffer-reuse-frames t)
I've found that terminal emacs does not render the correct colors unless I explicitly set TERM=xterm-256color. I use gnome-terminal, and from what I understand, TERM should be set to gnome-256color. Similarly, I tend to use tmux a lot, which advises against any TERM setting other than screen-256color. Unfortunately, both of those settings (within their respective context - gnome-terminal or tmux) result in emacs having wrong colors, whereas vim displays colors correctly. However, if I export TERM=xterm-256color, the colors work just fine in emacs.
Can anyone explain what's going on, or offer a solution?
Update
Here's what I'm dealing with:
I can get the colors to look correct in the terminal by adding the following to my init.el:
(defun terminal-init-gnome ()
"Terminal initialization function for gnome-terminal."
;; This is a dirty hack that I accidentally stumbled across:
;; initializing "rxvt" first and _then_ "xterm" seems
;; to make the colors work... although I have no idea why.
(tty-run-terminal-initialization (selected-frame) "rxvt")
(tty-run-terminal-initialization (selected-frame) "xterm"))
This feels really, really wrong though. There has to be a logical explanation for this...
P.S.
I have very little knowledge of terminfo and the precise role that $TERM plays in the process of color terminal behavior. If it's safe to always use xterm-256color (even when $TERM "should" be gnome-256color or screen-256color), I'll go with that.
Maybe I'm not understanding something, buy why don't you run emacs like this:
TERM=xterm-256color emacs -nw
This way Emacs has its own TERM setting that you know works. You can also make an alias or wrap this in shell-script.
Terminals are a special type of device. When a process sends special byte sequences (called control sequences) to the terminal, it performs some action (like cursor positioning, change colors, etc).
You can read the ANSI terminal codes to find more detail about control sequences.
But terminals come from 70s, when hardware was limited in its capabilities, and a terminal cannot provide info about its capabilities (ie. which sequences it supports).
$TERM was used to resolve this issue - it allows programs to know what to send to the terminal to get the job done. termcap and terminfo are databases that store info about terminal capabilities for many $TERM names. If your $TERM is not in the db, you must ask an administrator to add it.
All terminal emulators inherit these limitations from old hardware terminals. So they need a properly set $TERM, and the terminfo/termcap DB MUST have data for this terminal. When a virtual terminal starts it sets the $TERM variable for you (and inside programs like bash). If $TERM is not in the terminfo/termcap you can quickly define an alias from $TERM to xterm-256color (you can find examples in the termcap file on how to do that).
This behavior has to do with the logic EMACS uses to determine whether the terminal background is dark or light. Run M-x list-colors-display with TERM set to either xterm-256color or screen-256color and you'll see that the exact same colors are listed. As you pointed out in the comments, the difference in color schemes that you've observed is due to the frame background mode. To see this, with your TERM set to screen-256color, compare the colors in
emacs -Q -nw --eval "(setq frame-background-mode 'light)"
and
emacs -Q -nw --eval "(setq frame-background-mode 'dark)"
The function frame-set-background-mode (in frame.el) checks to see whether the terminal type matches "^\\(xterm\\|\\rxvt\\|dtterm\\|eterm\\)" if it can't deduce the background color otherwise.
Within a running session, you can change the color scheme to 'light by evaluating
(let ((frame-background-mode 'light)) (frame-set-background-mode nil))
I am not that familiar with how emacs handles different terminals exactly. But looking at lisp/term directory in emacs sources, I found out that the existence of a function terminal-init-xxx allows you to add support for different terminals. For example, I've got:
(defun terminal-init-screen ()
"Terminal initialization function for screen."
;; Use the xterm color initialization code.
(xterm-register-default-colors)
(tty-set-up-initial-frame-faces))
in my .emacs, which adds support for screen-256color. You may try defining a similar function for gnome by renaming the above function to terminal-init-gnome.
NOTE: If you are interested, you can try to track down the calls from tty-run-terminal-initialization code. It first gets the terminal type using tty-type function, then looks at certain locations to load a relevant terminal file, then tries to locate the matching terminal-init-xxx function, and finally calls it. It may help you figure out the correct name for gnome-terminal.
It looks like unless your TERM indicates that your terminal has 256 colors, emacs will only use 8. Changing TERM to gnome-256color allowed the color registration functions to work.
There is a way to cheat, after all. When I run gnome-terminal, my terminal is set to xterm by default. Instead of changing TERM variable, it is possible to redirect xterm to another terminal, say, gnome-256color. Simply create the directory $(HOME)/.terminfo/x, then run ln -s /usr/share/terminfo/g/gnome-256color ~/.terminfo/x/xterm. I think this is better than setting TERM manually in .bashrc, because it only redirects a particular terminal to something else. A console login would still leave TERM as linux, and not xterm-256color.
Add this to your ~/.emacs:
(add-to-list 'term-file-aliases
'("st-256color" . "xterm-256color"))
It tells emacs that if it sees TERM=st-256color then it should initialize the terminal as if it had seen TERM=xterm-256color.
Longer answer:
Emacs is showing strange colors because it thinks your terminal can only support 8 colors. In Emacs, run M-x list-colors-display to see the colors it thinks are available. The correct number of colors is detected during terminal-specific initialization. It says, in part:
Each terminal type can have its own Lisp library that Emacs loads when run on that type of terminal.
On my machine, the terminal-specific initialization files are in /usr/local/share/emacs/25.*/lisp/term. It has files for xterm, rxvt, screen, etc. but nothing for st. We need to help Emacs find the right initialization file. The documentation further says:
If there is an entry matching TERM in the term-file-aliases association list, Emacs uses the associated value in place of TERM
So that association list is a recommended way to handle unknown terminals. It works without you having to manually override the TERM environment variable.
On ubuntu 10.04 I too had noticed that running emacs -nw inside byobu/tmux/screen was using different colours from emacs -nw in the regular gnome-terminal.
I found that this is because byobu was setting TERM to screen-bce. Then setting TERM to xterm (for me, in the normal gnome-terminal TERM=xterm) gave me the same syntax highlighting when not running through byobu/screen.
So still not sure what the proper solution is.
See also this post:
Emacs Python-mode syntax highlighting
So, i'm running emacs over a crappy ssh connection and I have it set up to use cscope. I can not use X because of this...hence I'm running emacs inside putty. However, when I search for something with cscope and it opens up the other buffer, I can not
follow the links where cscope tells me which file and line number the item is on. When I go t a line number and hit enter, emacs tells me 'buffer is read-only' (it is trying to actually put in a new line instead of following the link). anyone know how I can follow those links?
I don't know about cscope for sure - but you should be able to find out the appropriate key binding by doing a "Ctrl-h m" in the buffer with all the links. This should open another buffer showing you help/key bindings on all the active modes.
E.g. if you do the same thing in a grep result buffer it indicates the key binding "C-c C-c compile-goto-error" which is used to open file at the grep line number (so it may be the same keys for cscope).
As a workaround, I'm pressing <space> key on the cscope result line. It shows the code in the other frame, although it doesn't position the cursor there.
Changing this line in xcscope.el fixed the problem on my computer.
-(define-key cscope-list-entry-keymap [return] 'cscope-select-entry-other-window)
+(define-key cscope-list-entry-keymap (kbd "RET") 'cscope-select-entry-other-window)
Could you use cscope with Tramp mode? I'm not familiar with cscope, but I've had great results using tramp mode to read/write files remotely over an SSH connection.
I believe GNU find version 4.2 and above supports -L to follow symbolic links. Hence,
find -L . -name *.[ch] > cscope.files
cscope -b -R -q -i cscope.files
might work well
Another workaround. Just type 'o' to select what you want. It means cscope-select-entry-one-window :)