Emacs 23.1.1 Ediff 2.81.2 on CentOs 6
Prior to any customization, Ediff would, by default, split the windows horizontally (one on top of the other).
I wanted them side by side so I tried adding the following lines to my .emacs
(setq ediff-split-window-function 'split-window-vertically)
(setq ediff-merge-split-window-function 'split-window-vertically)
This had no effect - the windows were still split horizontally. I also tried using the Emacs Customization interface for Ediff to get the vertical split by default - same story.
Note that I tried this in a comparison with two buffers that were vertically split. I also tried it with no files open in buffers and asked Ediff to compare two files - same result.
Then I tried specifying split-window-horizontally as the split window function for both ediff-split and ediff-merge.
(setq ediff-split-window-function 'split-window-horizontally)
(setq ediff-merge-split-window-function 'split-window-horizontally)
This caused the windows to split vertically (next to each other). This was also true when I commented out these lines and used the Emacs Customization interface to set these options.
And yes, I've seen this question but I don't want to eliminate horizontal splitting on a global basis - I just want Ediff to do it by default.
Am I losing my mind or has someone switched the meaning of "horizontal" and "vertical" (and by the way, I'm taking the definition of "vertical" and "horizontal" splitting from my copy of the O'Reilly book "Learning Gnu Emacs")?
I used emacs variable customization, invoked with C-h v ediff-split-window-function to change the value. After clicking Save for future sessions the following was written to my .emacs:
(custom-set-variables
...
'(ediff-split-window-function (quote split-window-horizontally))
...)
And it does exactly what I want: putting the two buffers side-by-side. And yes, emacs uses horizontal/vertical in the opposite of what you had in mind.
If you read this question again, you will see the explanation, others were confused, too.
Hitting "|" when you are in ediff mode with the 2 files loaded switches from horizontal to vertical.
"?" gives a little ediff help menu.
(I'm on Debian Wheezy with emacs 23.4+1-4)
While it doesn't quite answer your problem, you could also use a function to specify whether to split vertically or horizontally depending on window dimensions:
(setq ediff-split-window-function 'split-window-sensibly)
split-window-sensibly is built-in.
Related
The object: In terminal, on start, in one frame, restore emacs workspace. i.e. restore all "windows", to the state before C-x C-c.
Descriptions: The window restoration could be simply done in emacs GUI, by adding (desktop-save-mode 1) to the init.el file.
However, when running emacs as a Daemon, emacsclient does not perform the same way. With the same setup, it still remember the major mode of the file, as well as other buffers before exiting, but the window layout will not be restored. Only 1 major window is displayed depend on the default settings.
I did some research, poked into some functions/variables using the elisp build-in documentation. I checked (desktop-save-buffer 1), framset-save, framset-restore and none of them seems to work. Also I checked similar questions posted before, and I found someone's answer using the following script:
(setq desktop-restore-forces-onscreen nil)
(add-hook 'desktop-after-read-hook
(lambda ()
(frameset-restore
desktop-saved-frameset
:reuse-frames (eq desktop-restore-reuses-frames t)
:cleanup-frames (not (eq desktop-restore-reuses-frames 'keep))
:force-display desktop-restore-in-current-display
:force-onscreen desktop-restore-forces-onscreen)))
However this script is buggy, it opens a "GUI" frame, and could not be closed properly(reopen automatically whenever closed, and if possible, I prefer to open the frame in terminal, so that a terminal 'texteditor' setting is possibe, with some other minor merits).
Sorry for the tedious question, any help would be appreciated.
I don't really know the right way to do this, but I was able to restore a frameset created in a GUI frame into a terminal frame. The new frame must be big enough or it will throw an error. I did (setq foo (frameset-save (frame-list))) and (pp foo (get-buffer "*scratch*")) to dump a readable representation of the frameset to the *scratch* buffer. Then I edited it by hand to get rid of (display . ":0.0"). That seemed to be enough to get it to not force a GUI frame. Then I did (frameset-restore [frameset ...]) on the edited frameset.
If you look at frameset.el, there are filtering functions to edit a frameset programmatically. Also, if you look at the comments, the display parameter is treated specially. You should look at the details there.
I'm editing python code using emacs, elpy and magit. When starting emacs using the -nw option (from bash and gnome-terminal in gnome 3). When started this way, emacs highlight the indented blocks of code using a black background single character; when using a graphic display (without the -nw option), the same character is a light gray. Please check out the two attached screenshots:
Is there a way to modify the darkness of the face in order make it less prominent?
I found a solutions that works. I'm not sure if it's the best one: if anybody knows a better way to do this, please comment!
In short:
Place the cursor on the indented block;
M-x customize-face;
Select the default value (highlight-indentation-face);
Select Show all (the face inherit from fringes);
Tick Background (this will overwrite the fringe background color);
Choose the white color (which is aliased to #e5e5e5)
Press Apply and Save
The last step will write few lines to the ~/.emacs file (on linux) to preserve the customization values. In my system, the lines that were added are:
(custom-set-variables)
(custom-set-faces
'(highlight-indentation-face ((t (:inherit fringe :background "white")))))
When I upgraded to (vanilla) emacs 24.1 on OSX, using iswitch for switching buffers seems to behave differently.
When I press ctrl-x b to switch buffers, instead of restricting the list of buffers to 1 line, it shows every single buffer by expanding the mini-buffer to be several lines long, then progressively removes buffers as I type in the buffer name I'm switching to.
I find having the status bar and mini buffer bumping up and down whenever I switch buffers to be visually distracting, so I want to recover the previous behavior, which cuts off buffer names which after 1 line. How do I do this?
If you want to globally restrict the number of lines the minibuffer uses to a single line, this should work:
(setq max-mini-window-height 1)
Additional info from documentation:
The variable max-mini-window-height controls the maximum height for
resizing the minibuffer window. A floating-point number specifies a
fraction of the frame's height; an integer specifies the maximum
number of lines; nil means do not resize the minibuffer window
automatically. The default value is 0.25.
However, if you just want to limit the number of minibuffer lines used by iswitchb, the documentation for iswitchb-minibuffer-setup-hook suggests:
Iswitchb-specific customization of minibuffer setup.
This hook is run during minibuffer setup if `iswitchb' is active.
For instance:
(add-hook 'iswitchb-minibuffer-setup-hook
(lambda ()
(set (make-local-variable 'max-mini-window-height) 3)))
will constrain the minibuffer to a maximum height of 3 lines when iswitchb is running.
I do not think this behavior has changed between Emacs 23 and Emacs 24, so I'm not sure why you only see this now. Maybe you had some customization to get this behavior, and it now fails to work in Emacs 24? If so, please report it so we can fix it.
Also note that with Emacs 24, the behavior of the default (non-iswitchb) buffer switching is very close to the behavior of iswitchb. The most visible difference is the display of potential completions which you can also get with M-x icomplete-mode, which does not affect the actual behavior, only the display, but also affects other completions. Also icomplete-mode does try to limit the completion list it displays to about one line (additionally to the actual minibuffer's content, so you will still get some line-wrapping, but less so).
I'm running Emacs 23.3.1 on Mac OS X. When I have linum-mode enable some lines are not numbered. Sometimes when my cursor scrolls past a line that is not numbered its number will appear and then sometimes it will disappear again. Is there away to prevent this from happening?
From your screenshot, it looks like lines with only comments are not numbered. Dunno why.
Perhaps there is another overlay at such positions, and it has a higher priority, thus masking the line-number overlay. Try turning off font-lock temporarily, to see whether that affects things. Then try increasing the priority of the line-number overlays. For a quick test, do this:
(defun foo ()
(dolist (ov linum-overlays)
(overlay-put ov 'priority 2000)))
(add-to-list 'post-command-hook 'foo t t)
If that helps, then instead of that, do the overlay-put (but try with a ower priority, say, 200) in function linum-update-window. IOW, add the priority when the overlay is put on the text.
In setting up my personal Linux command line development environment, I want to use term inside emacs b/c then I can switch to 'line mode' and copy/paste the output into any other buffer.
However, when I run mysql inside term inside emacs, the pretty sql tables still word wrap according to the width of that emacs window :(. I was hoping that emacs would truncate the bash output.
Is there a way to do this?
EDIT:
toggle-truncate-lines is on, so "word wrap" is off, but the problem is that before emacs even does anything with the text, the underlying bash process itself manually adds newlines to wrap text according to the width it's told it's using. That's at least how it acts. toggling truncate lines on/off doesn't change anything for me in the term buffer
I think what you probably want is "M-x toggle-truncate-lines". That toggles between wrapping or requiring you to scroll right and left to see the entire line.
You probably want to add something to the sql hook to turn off the wrapping:
(add-hook 'sql-interactive-mode-hook '(lambda () (toggle-truncate-lines 1))
I think Emacs might be setting the COLUMNS environment variable to indicate when the shell should wrap lines. Try setting it to a very large value and see if that helps.
I have no idea what other things this will break though.
Meta-X auto-fill-mode
This will toggle auto-fill mode and stop the line wrap.
The function term--unwrap-visible-long-lines is called by term-reset-size whenever the window is resized and appears to be responsible for the unwanted wrapping, and is not configurable. I hack this by advising the function to fix the wrapped width to a large value.
(defun my-prevent-term-unwrap (original-function height width)
(apply original-function (list height 10000)))
(advice-add 'term-reset-size :around 'my-prevent-term-unwrap)