When I start Emacs, its windows and its minibuffer start up floating on the main frame, leaving a lot of empty space (see: here and here). Any idea of what is going on and how to fix it?
I'm using emacs version 23.1.1 on Xmonad
Thanks!
I get the same thing occasionally when doing a TAB expand in shell mode. I don't end up with an empty mini-buf, it usually has all the contents from the shell expand. The only solution I've found so far is to kill the current shell buffer
You might try C-l (recenter-top-bottom). I've used this over the years as a pretty reliable "repaint" operation that will clear up various detritus that occurs on the frame. It is even more helpful when you do not have a window system.
It looks like an odd interaction between Emacs and your window manager. It's as if Emacs is configuring itself to have a certain number of lines and columns in its active window, but the frame the window manager has allocated it is larger.
Can you try running X without Xmonad (ie. just run startX) and then run Emacs? You won't get frame decorations, but you can still use xterm to start it and see what 'natural' size it gets allocated. With the same Emacs configuration, that would narrow it down to some issue with Xmonad.
It's not obvious from the screenshots, as one is definitely in GUI mode, but the other (green on black) looks like it is in text mode. If you force it to run in text mode (emacs -nw), does it take up the same size? Within the shell, do normal commands take up the entire size of the allocated window?
Are the shell variables COLUMNS or LINES set correctly? Do they match the window dimensions? Assuming you are running bash, is shopt checkwinsize turned on? Do regular commands such as ls wrap at the expected margins and scroll to use the entire window?
It is worth ensuring that text mode is being configured correctly before getting GUI mode to work. I have a hunch the way that Xmonad is managing its window sizing may be the culprit, if it is 'forcing' windows to tile in certain arrangements, and the correct X hints aren't being sent. But - that's all just supposition for now...
This partially works (taken from here):
(defun fullscreen ()
(interactive)
(set-frame-parameter nil 'fullscreen
(if (frame-parameter nil 'fullscreen) nil 'fullboth)))
(add-hook 'emacs-startup-hook 'fullscreen)
The windows get corrected, although the mini-buffer is still larger than the usual.
Sounds like a bug, to me. Consider reporting it: M-x report-emacs-bug. Try to provide a recipe starting from emacs -Q.
Related
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
when I use term inside emacs ( M-x term), I found that if I maximize the window, then the display in quite good (when I am doing something like apt-get install full-texlive or something will give me a lot of message). But if I resize the Emacs window or the size is not maximal when I open Emacs, then the display is very awful.....(when there are a lot of message in the terminal); But if I use terminal directly (not run in emacs), the display is very well however I resize it (maximal or not maximal), it adjust the output display.
I would like to know if there is a way to improve the display of term inside emacs.
I think you may be looking for a way to keep long lines from wrapping.
Try
M-x toggle-truncate-lines
Also very useful for shell mode (not term) is to make emacs interpret ANSI codes:
M-x ansi-color-for-comint-mode-off
Occasionally when I'm compiling, I have to scroll up my compilation buffer to see the details of an error. At this point, emacs stops "following" my compilation buffer, i.e., scrolling to automatically display new output.
I'm using Aqumacs on OS X. Any idea how I can "reattach" or re encourage the compilation buffer to follow again?
Regards,
Chris
Put in your ~/.emacs file
;; Compilation output
(setq compilation-scroll-output t)
or even
(setq compilation-scroll-output 'first-error)
to make it scroll to the first error.
Try using M-x auto-revert-tail-mode or M-x auto-revert-mode. Taken from official documentation:
One use of Auto-Revert mode is to
“tail” a file such as a system log, so
that changes made to that file by
other programs are continuously
displayed. To do this, just move the
point to the end of the buffer, and it
will stay there as the file contents
change. However, if you are sure that
the file will only change by growing
at the end, use Auto-Revert Tail mode
instead (auto-revert-tail-mode). It is
more efficient for this. Auto-Revert
Tail mode works also for remote files.
So, as Chmouel already noted, just moving point to end of buffer will also work.
I am not sure about aquamacs but for me (Emacs 23/Debian) I just go in the compilation window and place my cursor at the end of the window which will attach and follow (you can go to another window and it will still follow).
I have some processes that run from functions, i.e.:
M-x run-proc1
M-x run-proc2
I would like to know what command to issue from the command line to run emacs with run-proc1 running in the upper window and run-proc2 running in the lower window.
Thanks!
You might get better answers later, but appending this to your ~/.emacs.d/init.el might work.
(split-window-vertically)
(run-proc1)
(other-window)
(run-proc2)
(other-window)
Alternatively (for another approach), see this link.
I've done this before, years ago, so I know the answer is out there. However the google-space is heavily polluted with namespace collisions, especially new user guides.
This is what I'd like to do in Emacs 21:
Split the screen on a given file buffer (C-x 3).
As I page through the first screen (C-v), the next page of the file is automatically displayed on the second.
To be clear, the next line in the file after the last line on the left screen should be the first line on the right screen, always.
Any help?
You might be looking for follow-mode
It is minor mode that combines windows into one tall virtual window.
You want scroll-all-mode
scroll-all-mode is an interactive compiled Lisp function in `scroll-all.el'.
(scroll-all-mode &optional arg)
Toggle Scroll-All minor mode.
With arg, turn Scroll-All minor mode on if arg is positive, off otherwise.
When Scroll-All mode is on, scrolling commands entered in one window
apply to all visible windows in the same frame.
Set up the windows appropriately, and then turn on scroll-all-mode, and from then on all windows scroll together
If follow-mode doesn't work, you could define your own macro, something like
(defun align-windows ()
(set-window-start (other-window) (window-start))
(scroll-other-window))
Then either use this (along with scroll-down) instead of C-v, or rebind C-v to that, or add
advice to scroll-down.
You can start Follow mode and setting up a basic two-window layout using
M-x follow-delete-other-windows-and-split RET.
it is from http://www.emacswiki.org/emacs/FollowMode