Here is my tmux command
tmux send-key -t session:window.pane say 安安 enter
but the result is
root#debian:~# say
(There is no "安安", unicode characters.)
How can I send the non-ASCII Characters???
(my tmux version is 1.8)
This is a known bug in tmux 1.8 and earlier. It is fixed in the SVN version of tmux. See this thread for more information: https://www.mail-archive.com/tmux-users#lists.sourceforge.net/msg04478.html
Related
I'm trying to run a simple Zenity dialog where I catch user's input:
zenity --forms --title="Title" --add-entry="Comment"
When I write in ASCII characters it catches them just fine, however, I when I the input contains Unicode characters (namely Hebrew) it outputs them as question marks.
I know for sure that it's Zenity's fault, as if I try to change the title as following: --title="שלום" it would fail to launch altogether.
I'm running on Ubuntu Xenial with all latest patches. Zenity version is 3.18.1.1.
I found the culprit to be Ubuntu's locale settings.
All I had to do to fix this was:
$ sudo locale-gen "en_US.UTF-8"
$ sudo update-locale LANG=en_US.UTF-8 LANGUAGE=en.UTF-8
And reboot.
Edit
As suggested, I'll elaborate a little bit about this fix:
Before changing those values, running locale would show both LANG and LANGUAGE empty.
Typing in Hebrew in terminal would result in question marks.
Nothing in the system seems to have changed, except that now Hebrew can be used in terminal and Zenity.
Typing this command on regular cmd.exe or cygwin termal gives me results as expected:
$ ack hello
(I have ack.bat that execute ack.pl in my PATH)
However, when I run the same command from either shell or eshell in Emacs, it gives me this error:
c:\Users\Martin>"C:\cygwin\bin\perl" /cygdrive/c/Users/Martin/Desktop/ack.pl hello
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LC_ALL = (unset),
LANG = "ENU"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
I tried to fix it by SETENV both variable to en_US.UTF-8 but when I run it again, it gave me no result but froze.
Update: I have finally found the solution to this problem. All I need was to add < NUL to the end of the command since it parse Linux style NULL DEVICE as default.
Now if I type in this:
ack hello < NUL
It'll give me results as expected.
This problem doesn't have to do with ack per se, but pearl, the language Ack is written in. What perl reports is that your environment where you are running emacs does not have the locale settings set. Add the following lines to whatever environment you're running emacs in:
export LC_CTYPE=en_US.UTF-8
export LC_ALL=en_US.UTF-8
Note: running ack hello < NUL only masks the problem, it doesn't resolve it.
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.
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!
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