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 :)
Related
In org-mode, pressing M-S-RET (meta-shift-return) will create a new TODO on a new line. This key sequence sends M-RET to emacs through my terminal. I've checked this with C-h c ESC-S-RET, which returns M-RET is undefined in the mini-buffer.
I'm using Snow Leopard with Emacs 23.2.1 running in Terminal.app. There is no option to define a RET sequence in the terminal keyboard preferences.
Any idea what's causing the missing SHIFT? Workarounds?
You can get Emacs to pretend that it got S-RET with C-x # S RET (note uppercase S).
This also works for adding control, meta, alt, hyper or super modifiers; type C-x # C-h for the list of bindings. The Modifier Keys section in the Emacs manual mentions this as well.
In general, lots of keystrokes are simply impossible to send via a terminal, since terminals emulate an old protocol that only allowed 256 separate keys (or maybe only 128).
Chances are, when you press S-RET, Terminal.app does exactly the same thing as if you'd pressed RET. Thus Emacs has no way to distinguish those two cases.
Cross-linking to other Q&As:
If you are using an xterm, then the modifyOtherKeys option may facilitate that binding. See the following for details:
Send "C-(" to Emacs in VT100/xterm terminal (Mac OS X's Terminal)?
I suspect Emacs recognises those codes by default, but if not then also see input-decode-map as described here: Binding M-<up> / M-<down> in Emacs 23.1.1
See explanation and alternative shortcuts for TTY here.
Some of these have worked for me in a terminal in Ubuntu Linux (both locally and over SSH), but not all of them seem to work. For example, the alternative provided for S-RET (which I expected to run org-table-copy-down) instead seems to run org-clone-subtree-with-time-shift for some reason. However, I have found the list of alternatives useful, particularly those with the M- prefix. For example ESC UP for M-UP to move text around in tables.
I use file named Makefile.include as a GNU makefile. I am trying to get emacs use the makefile-mode to use for this file. Alt-X makefile-mode works. Is there a way to tell emacs to use this major mode for this file right after opening automatically?
I tried putting
# _*_ mode: makefile; _*_
in the file but that does not appear to have the right effect. Btw I could not find the list of allowed strings one can use after mode:, so I tried BDSmakefile and some other variations as well.
Thanks.
See this question: Setting auto-mode-alist in emacs, and use the pair ("Makefile\\.include\\'" . makefile-mode).
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
I'm using emacs23 on Ubuntu 32-bit 10.04/10.10 with GNOME and Compiz.
Pressing M-RET in an org-mode plain list in Emacs (GUI) inserts a new item. Pressing M-Up moves the item up in the list.
These keys don't work as expected in emacs -nw under Terminator and gnome-terminal. The M-Up key does nothing, whereas the M-RET key simply moves the cursor down one line and indents the position. The keys also don't "work" in xterm, which inserts \215 instead. Pressing ESC-RET or ESC-Up instead produces the expected functionality. The same problems exist if I run emacs -nw on a headless server accessed via ssh under Terminator, gnome-terminal and xterm.
I've searched both generally and on the org-mode Gmane list for an answer to this, but have not found anything. Is this a known issue with org-mode or is it related to the terminal emulator and/or the Window Manager?
In addition to the keys in my question, S-TAB, S-Left, S-Right, S-Up and S-Down were not working over ssh and PuTTY. Using certain keys on a TTY connection (ssh, screen, PuTTY) is a known issue.
Alternative keys are included in org-mode as detailed in 'Using Org on a TTY' in the org-mode manual.
Alternative key combinations exist
for equivalent to M-RET
M C-m
"<return>" is the Return ↩ key while emacs runs in a graphical user interface.
"RET" is the Return ↩ key while emacs runs in a terminal.
"RET" is also equivalent to "C-m" (【Ctrl+m】). (http://ergoemacs.org/emacs/emacs_key_notation_return_vs_RET.html)
as equivalents for M-<up/down> you can use
ESC-<up>
ESC-<down>
The menubar of terminal emulator is not letting the M key that is meant for Emacs be passed down to Emacs. For Emacs to receive the M key as it is supposed to, you could either use the Esc or disable the menubar and use M key in Emacs as usual.
ADDED:
For the xterm, if you do CTRL+Mouse Button 1, you will see "Meta sends Escape". You need to make sure that option is checked/enabled to make M work as it should in Emacs.
I'm using emacs (21.4.1) via PuTTY (0.60) connected to a CentOS5.3 box with a UK keyboard. Whenever I enter the £ symbol emacs locks hard, making the whole putty window unresponsive and loosing all changes.
Edit:
Futher to pajato0's suggestion, I get the following message:
à (translated from £) runs the command self-insert-command
which is an interactive built-in function in `C source code'.
which is an interactive built-in function in `C source code'.
It is bound to many ordinary text characters.
So it looks like I need to rebind the key. How would one do this?
To determine what role, if any, Emacs is playing in your scenario, I would suggest that you try C-h k # where # is your pound key. If it hangs, then Emacs is not getting the key at all and you have a Putty/Windows issue most likely. If Emacs tells you the function binding then you have some hope of fixing it by changing the key binding. My best guess is that Putty is capturing the key and sending it to Windows which is dropping the ball.
You could try another ssh client to see if it is putty-specific. I tend to just run
startxwin.sh # from a MinGW rxvt terminal
after which an xterm pops up in which I do
ssh -X some.unix.box # from the new xterm
after which I fire up a tabbed terminal emulator in which I keep several sessions 'forever'. And my US keyboard has no Pound sign so no way for me to test your issue...
I would look at the character set translation that putty is performing (window->translation in settings). It could be that the character code that is being sent for a pound symbol (don't have a UK keyboard...) locks up the terminal somehow, or that the character that is being returned in response to the keypress is causing some similar behavior (e.g. waiting for the completion of a code point).
You might want to try it with everything set to UTF-8 (charset/locale on linux side, and on Putty translation), to minimize the chances of confusion...
In response to your question "how does one rebind a key": use the define-key function, e.g.
(define-key global-map [S-Home] 'beginning-of-buffer)
The hard part is figuring out how to represent your key and then choosing a suitable function. For example, you might do something like:
(defun make-euro ()
"Euro")
(define-key global-map # 'make-euro)
But I would also suggest that you file a bug since if trying to self-insert your # key causes Emacs to hang, that is clearly Emacs breakage that should get fixed.