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.
Related
there is this annoying behavior in emacs which I don't know how to get rid of it.
lets say the current cursor position is on line 10 column 15.
now I need to quickly look up something far down the same buffer, I scroll down to that location and as I scroll down (or up) the cursor keeps moving and it loses its original location.
many people suggest to set a marker before scrolling but that is not a good solution, because you have to be always mindful of this fact before scrolling (which is impossible)
I know there should be a simple solution but I have not found it yet.
I'll appreciate your suggestions
As far as I know, Emacs doesn't allow you to scroll in such a way that your point disappears. I just took a quick look at xdisp.c and it looks like this is a fundamental assumption in the C code. This is different from some more recent editors (Sublime Text, VSCode etc).
However, the "many people" you mention actually have a reasonable point. If you're moving through the file by searching (C-s the-thing-im-looking-for) then Emacs will set a marker for you automatically.
I guess you could try adding a hook that set a marker at point whenever you scrolled? It wouldn't be trivial because you'd have to cope with things like not setting a load of markers through the file as your scroll dragged the cursor down. But my recommendation is probably to alter your workflow to match how Emacs wants to do things. In this case, it's probably a better approach than the modern editors it sounds like you're used to.
An option that might or might not be useful is scroll-preserve-screen-position. The description is somewhat hard to understand, but a net result is that if you mainly scroll using C-v/M-v, the point will visually stay at the same place on the screen (so if you do e.g. C-v C-v M-v M-v, the point will come back to its original position.
However, note that many commands do push a mark before they jump: isearch, end-of-buffer, imenu, xref-find-definition ... In all those cases, you can then press C-u C-SPC (the same command that you use to set the mark but called with a prefix argument) to pop the mark (concretely, jump to the last mark). If you need to jump back more than once, you can set the variable set-mark-command-repeat-pop to t, so that you only need to do C-u once and then repeatedly press C-SPC to pop more and more marks from the mark ring.
In general, there are better ways to navigate a buffer than scrolling in the wild; the cases where you do need to scroll, starting from "your current" point are (or should/could be ...) sufficiently rare that you know beforehand that you will be spending a possibly long time "looking around" in the buffer. It is then quite fast to set a mark, do your stuff somewhere else, and C-u <mash C-SPC as often as needed> until you get back to your initial point.
I can't get emacs to scroll horizontally!
To replicate the problem:
Open the *scratch* buffer.
Write a long line.
Make the long line exceed the window width with M-xtoggle-truncate-lines. The left hand text (column 0) will now be off the left of the window.
Try M-xscroll-left or its shortcut C-x < to scroll left.
Type y to enable the disabled commands.
NOTHING HAPPENS!
I also tried C-a to go to the beginning of the line.
I also tried M-xtoggle-horizontal-scroll-bar but got the error message "Horizontal scroll bars aren't implemented yet".
There seems to be no way to scroll horizontally!
I need this because I have many wide CSV files to read.
I'm using the latest prelude on emacs 24.5 on Windows 10.
I filed an issue on the prelude project in case it is a genuine bug and could be fixed there.
You seem not to understand how horizontal scrolling works. It's not intuitive, that's why the command is disabled by default.
When I press C-x< at the end of the long line, the line disappears to the left. When I press C-x> there, nothing happens.
Pressing C-x< at the beginning of the long line, though, shows the second part of the long line.
Consider using visual-line-mode or even the csv-mode instead.
There is new a feature in Emacs 26. You can customize mwheel-tilt-scroll-p and use mouse to scroll.
M-x customize group RET mouse
Then set mwheel-tilt-scroll-p to t
No need to handroll it yourself. This is provided out of the box in emacs 27, and it probably was available for longer:
This feature is off by default; the variable mouse-wheel-tilt-scroll turns it on, if you customize it to a non-nil value.
(setq mouse-wheel-tilt-scroll t)
Sounds like xemacs have horizontal scroll in a 'natural' way.
As far as I can see it there is a [Options] button in the menubar, when clicking on it there is a [Frame Appearance] sub menu and there, there are 2 button []scrollbars, [] Truncate Lines
When these 2 buttons are checked in, long line are truncated and scrolling is smooth.
May be xemacs is non standard though.
I use it, I find it easy to cut/paste even rectangular areas, selection is faster and more precise to me that what I could achieve with keyboard meta-ctrl-shift stroke alone.
Cheers
Phi
I
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).
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.
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)