I'm having trouble getting 256 colors to work using emacs 23.1.1 connecting using PuTTY and screen. Server is running CentOS 5.6.
In my PuTTY config, my terminal-type string is set to xterm-256color. In my .screenrc I have term xterm-256color Once in screen tput colors gives me 256, echo $TERM gives me xterm-256color, but once I start emacs M-x list-colors-display only gives me 8 colors.
Not sure what the problem is.
Thanks.
I hit the same problem.
To fix this problem, just add this to ~/.bashrc (yes,I use bash)
# -----------
export TERM=xterm-256color
export TERMCAP=
# ------------
run screen and emacs in an screen window. it's ok now.
versions:
bash-4.2.45
emacs-24.3_10
Screen version 4.00.03 (FAU) 23-Oct-06
Your ~/.screenrc should read:
term screen-256color
(this shouldn't be mixed up with xterm-256color)
Putty has a setting to allow 256 color mode. It's under Window/Colours, labeled "Allow terminal to use xterm 256-colour mode". Make sure it's checked.
After you load emacs, you can confirm the TERM value emacs is using with:
(assoc 'tty-type (frame-parameters (car (frame-list))))
It should be (tty-type . "xterm-256color").
Looking at your post and your responses to others, it sounds like your problem is... screen. To test my hypothesis, try this ...
$ wget http://www.frexx.de/xterm-256-notes/data/256colors2.pl
$ chmod 755 256colors2.pl
$ ./256colors2.pl
... if you see 256 colors in the shell, but not in screen, the problem is screen. And, even if there are other problems, you are going to have to fix screen in order to have any hope of seeing 256 colors in emacs ;)
I recently fixed this situation for myself on a system where I don't have sudo by building a personal copy of screen. Screen is small and it is no big deal to do ... and, IMHO, emacs w/256 colors is well worth the bother.
On Linux 2.6.x I did this:
$ wget ftp://ftp.gnu.org/gnu/screen/screen-4.0.3.tar.gz
$ tar -xf screen-4.0.3.tar.gz
$ cd screen-4.0.3
$ ./configure --prefix=$HOME --enable-colors256
$ make
$ make install
Test the new screen out with ...
$ ~/bin/screen
$ ./256colors2.pl
... if it works, put this in your ~/.bashrc:
PATH=~/bin:$PATH ; export PATH
The screen I ended up with reports being an earlier version ...
$ ~/bin/screen -v
Screen version 4.01.00devel (GNUdf0777e) 2-May-06
... than the version on my system:
$ /usr/local/bin/screen -v
Screen version 4.00.03 (FAU) 23-Oct-06
But while they both claim to support 256 colors...
$ tput colors
256
Only the new build really does. Yeah!
I had similar difficulties, I believe both of these lines were required for screen, putty, and emacs to get along with 256 colors.
termcapinfo xterm 'Co#256:AB=\E[48;5;%dm:AF=\E[38;5;%dm'
term xterm-256color
You may also need this line too.
defbce "on"
Speak up if that's still not enough.
Try using emacs in daemon mode instead (emacs --daemon), and open emacsclients (emacsclient -t) instead of using screen/tmux. This will give you one less variable to handle in debugging this.
I was having a similar problem with putty and screen, though not using emacs. Following ataylor's response, I went to Window/Colours in Putty. In there I found and checked 'Use system colours'. This fixed my issue.
Related
I have a source code that runs perfectly fine on Ubuntu, it does some copumtations, and at some points it beeps like this
system("beep -f 400 -l 500");
On Ubuntu I had to do
apt-get install beep
However, I migrated to OpenSuse (not my choice) and now I get this message "sh: beep: command not found", as the command and package are obviously different.
Does anybody know hot to trigger the system beep sound and define the duration and frequency? I have been able to find only one way to change the parameters
setterm -bfreq 500 -blength 500
, but no way to actually trigger the system bell (beep). The following things don't work
echo ^G
echo -e "\a"
PS - the system Bell is enabled at
Configure Desktop -> Application and System Notifications -> System Bell
and you can actually play with this
So, I did what #fvu proposed.
However, one needs to have sudo rights, to do so, otherwise (e.g. at my work-place we don't have sudo rights) there is this output message
Could not open /dev/tty0 or /dev/vc/0 for writing open: No such file or directory
In this case, you should:
sudo chmod 4755 /usr/bin/beep
as proposed here
I noticed that on my OpenSuse 12.3 system, the bell is working in xterm or gnome-terminal, but not in konsole or xfce4-terminal.
If the same applies to your system, then maybe a work-around could be creating a shell script called "beep" which calls xterm and rings the bell:
#!/bin/sh
xterm -e "echo -e '\a'; sleep 1"
I use gdb-many-windows in emacs as normal user. But the program need to run as root. Can i change to root in emacs before run gdb-many-windows? Is there other way to solve this problem?
Update: Thanks all.
When you do Meta-X gdb, emacs allows you to change the gdb command it will invoke.
Just change it to sudo gdb --annotate=3 ...
Update: as matt comments, this is still quite insecure. Better make it
sudo /usr/bin/gdb -ex 'set auto-load-scripts no' --annotate=3 ...
An even better approach might be to change your setup such that the program you are debugging does not need to run as root in the first place. Perhaps you could use fakeroot instead?
Update 2: sudo appears to interfere with emacs terminal handling. In particular, it tries to read password from /dev/tty and doesn't get input from emacs mini-buffer.
The solution is to allow yourself to invoke GDB without password via sudo. Something like this (in /etc/sudoers) should work:
your_user_id ALL = NOPASSWD: /usr/bin/gdb
A solution not mentioned here is to have your build script set the setuid bit on your binary and set the ownership to root
chmod u+s binaryname
chmod g+s binaryname
chown root:root binaryname
that's probably more secure then either of the two answers (although it'll let anybody that has execute permission run the file as root, that may not be what you want...)
One possible solution is to run emacs as root, which will cause gdb (and any other process you spawn) to run as root.
It seems there is a way to do this with emacs 25 without tinkering with sudoers. You need to got to any buffer in emacs (I usually use a file from my project), do 'M-x cd', select '/sudo::/' - this changes the default directory. Then, when you run 'M-x gdb', gdb will run under sudo (you will be prompted for your password). See also here: https://groups.google.com/forum/#!topic/gnu.emacs.help/DdAev2pWJMw
How do I consistently control window focus after running emacsclient?
Currently, focus depends on if I already have an emacs server running. When emacsclient invokes an alternative editor, focus is shifted to the new emacs window. When emacsclient connects to an existing emacs server, focus is not shifted (ie. it stays on my putty client).
I would like to consistently focus on the emacs window, since I usually go to emacs after opening a file.
Any help would be greatly appreciated!
Notes
Version Info
emacs: 21.4.1
emacsclient: 21.4
client os: Windows XP Service Pack 3
x server: Exceed 11.0.0.0
Relevant section of my .bash_profile
# a wrapper is needed to sandwich multiple command line arguments in bash
# 2>/dev/null hides
# "emacsclient: can't find socket; have you started the server?"
emacs_wrapper () {
if [ 0 -eq $# ]
then
emacsclient -n -a emacs ~/notes.txt 2>/dev/null &
else
emacsclient -n -a emacs $* &
fi
}
alias x="emacs_wrapper"
Also, at the end of my .emacs I have
(server-start)
My current workaround is a simple autohotkey script, which focuses on my first Exceed window
^+x::
If WinExist("ahk_class EXCEEDW:MWCLIENT0")
WinActivate
return
As a side note, it seems my redirection to /dev/null confused the syntax-highlighter :(
How about:
emacsclient -e "(select-frame-set-input-focus (selected-frame))"
works for me on emacs 23.1
To unfocus (lower-frame) might be useful.
Would the "--create-frame" option to emacsclient work for you? You'd get a new frame for each file you opened this way, but at least it would be focused (I think).
For some unknown reason, the issue fixed itself. Opening files now consistently changes focus to the emacs frame with the corresponding file. I'm honestly unsure what changed the behavior, but I'm happy.
Thanks to everyone for their comments and suggestions!
I use an emacs daemon to preserve my emacs session even if I have to reboot the machine that I run my X server on or if I want to access the same session from a different machine. This works very well but when restoring a session I'd quite like to just run "emacsclient --create-frame --no-wait" to connect to the daemon without opening a new file. It won't let me get away without specifying a filename.
I've tried using --eval to execute a function rather than open a file but the window just goes away when the evaluation is complete.
(Emacs 23.1 via backports on Debian GNU/Linux 5.0.)
From the help provided by emacsclient, you have a few options. First, is the one mentioned already which is emacsclient -c. That will try to create a frame associated with the emacs daemon. The advantage to this is that if DISPLAY is not set, then it will open emacs in the terminal.
Which brings us to the next best option (especially if you are logging in remotely): emacsclient -t which forces emacs to open up in terminal mode even if DISPLAY is set.
Also keep in mind that you can set the display from the command-line as well. I use this often when logging in remotely from VNC. The full command would be emacsclient -d DISPLAY -c
emacsclient -c works for me.
emacsclient -n -e "(make-frame)"
The -n flag means that the emacsclient doesn't wait, and the emacs instance doesn't destroy the frame.
If you are using emacs from the command line, you might also want to consider emacsclient -t
When working on a linx CShell u get the option to press the up / down arrows to select the last command/s typed or the Command Buffer. This even works on Windows.
However this is not functional when working on Solaris, to which i recently switched. I am guessing that the shell is also a CShell.
Please tell me what key combination is required to have this feature on Solaris ?
The default shell in Solaris has command history, but you can also use Bash instead, it's more user friendly. Just type 'bash' (no quotes) at the command line. You can also edit /etc/passwd to make bash your default shell.
The "official" default shell for Solaris is actually sh, the original Bourne shell (see Chapter 10 of the Advanced User Guide for Solaris for more info). If you'd like to change it to csh or tcsh—and you're not root (it's generally considered bad practice to use anything but sh as root's default)—just issue passwd -e /path/to/shell_of_your_choice <loginname>. I'm guessing this would probably look like passwd -e /bin/csh <loginname>, but you'd probably want to make sure it exists, first.
It may be that it's the Korn shell in which case try <ESC>k.
bash at least will allow you to switch modes with "set -o vi" or "set -o emacs".
Maybe you can use the !! command, to repeat the previous one.
Use "echo $SHELL" to see what your login shell is. If it's ksh or bash, try "set -o emacs". If that works, you'll be able to use ^P to go back a command. ^R lets you search for a command, ^F and ^B to move around within the command.
If you can´t change your default shell, or you just want to try out one that works, you can kick off any other shell from your command line. I recommend you tcsh, which will have good command line editing and history using the arrow keys. Type /bin/tcsh at your prompt to try it out. You can use the earlier responses to change your default shell if you like tcsh. Make sure your have the following in your $HOME/.cshrc file:
set filec
set history=1000 # or some other large number
set autologout=0 # if you are logging in remotely under your account.
I hope this helps.
You enable history temporarily if you use BASH by typing
HISTSIZE=1000
which will enable up and down keys and store 1000 commands. After termal disconnetion all history will be gone.
This works on solaris 10.
For permanent solution add these lines to ~/.bashrc
HISTSIZE=1000
HISTFILESIZE=1000