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
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.
The thing is I have printed something in the terminal, but when I accidentally resize the terminal, the printed contents at the bottom of my terminal disappear. Why is that? Is there anyway to recover these printed messages since the program runs a long time each time.
When you resize a terminal window, the terminal has to paint or repaint part of the window. If you lost text at the bottom of the window, that sounds as if you shrank the window when using one of the terminals which leave the upper-left corner of the window in a fixed position, while adjusting the rest of the window. Offhand, that could be rxvt, putty, konsole. xterm (which is configurable) defaults to the other direction.
If the window shrinks, then the location of the "bottom" row of text should be moved up (to match user's expectations). But there is a complication: GNU screen will besides redrawing the window, attempt to wrap long lines so that they fit the new margins. Developers for a few terminals have imitated that in the past few years, and you may notice some bug reports when that new feature does not work well.
For instance, if you shrank the window vertically, but changed its width, then a miscalculation of the wrapped lines could cause text to vanish. Then again, resizing it again might get the text back into view. But if that does not work, then it's gone.
When I scroll with the touch pad with two fingers in Visual Studio Code, I often scroll to the sides a little by accident. This is a bit annoying.
I'd be happy to have it scroll only up and down.
A partially satisfying solution, is to simply press Alt + z, to have the lines wrapped, and then it doesn't scroll to the side.
You can also make wordWrap default as described here How do I turn on text wrapping by default in VS Code
If you have this problem because of Gitlens (blame lines), the solution i found is to disable gitlens.currentLine.scrollable (or set it to false in the settings json file.
Pressing alt + z to disable horizontal scrolling, works fine for a current single file. If you want permanent solution then for every file you visit? then follow:
Settings > Text Editor > Diff Editor > Word Wrap to on
Note: in case you don't know where is this Settings, just go
1. Via MENU
File > Preferences > Settings > Text Editor > Diff Editor > Word Wrap
2. Via shortcut Keys
On Windows
ctrl + , (control + comma)
On Mac - correct me if I am wrong
command + , (command + comma)
Just want to add that some plugins, like GitLens, may mess this setting up.
E.g., with GitLens, it can add git blame information inline, at the end of each line of code, showing you who is responsible for that line's current version, and when.
Unfortunately, this information will not only be to the right of the wrap column, e.g. 80, it'll also "unlock" the horizontal scrolling, even when no GitLens blame annotation is there.
I haven't found any fix for this other than disabling such features.
Just press ALT + Z -> To enable/disable the horizontal scroll
Config: MBP 2018 | Using Magic Mouse 2.
For me, I had accidentally set the 'Scroll Beyond Last Column' to 80 chars. Just resetting it to default settings is what worked for me. Hope it does for you all!
Update (6th Feb, 2021): Enabling the mini-map again causes the problem. So disabled it to get rid of the issue.
⌥ + z
the shortcut for Mac. you welcome
February 2020 (version 1.43) update adds an option called: Scroll Predominant Axis
Scrolling predominant axis
When trying to scroll vertically using a modern touchpad, it oftentimes happens that the file scrolls horizontally as well. There is now a new setting, editor.scrollPredominantAxis (which is set to true by default) which blocks "diagonal" scrolling. This forces scrolling gestures to be either vertical or horizontal (based on the highest absolute scroll delta), but never diagonal.
When enabled,it prevents any diagonal scrolling.
It guesses your scrolling to either vertical scroll or horizontal scroll.
It says by default it is enabled. If not then you can enable in Scroll Predominant Axis in settings.
Screenshot: Editor: Scroll Predominant Axis
Or in settings.json
"editor.scrollPredominantAxis": true
Use Ctrl + E, then Ctrl + W for disable horizontal scrolling.
For more details, you can refer this cite: https://developercommunity.visualstudio.com/t/disable-horizontal-scrolling-in-visual-studio-2019/612873.
I have gnuscreen on with multiple "tabs" open. Emacs is on tab 0.
When I tab to a different screen and return to Emacs, the lines do not wrap properly anymore. They blend into each other. If I have a vertical split open in Emacs, the two views blend into each other as if the bar in the middle fails to constrain the line wraps.
How do I prevent this? This is in Terminal.app and the only solution I've found is to force a redraw by dragging the corner slightly. That's not a good long term solution.
I've got emacs in front of me.
I've run a find-grep, and it's got many hits, which are displayed in a window. The file names are displayed in green as hyperlinks.
I make that the only window, with C-x 1.
If I click on a file name, the window splits vertically, and the file with the found text is displayed in the other window.
If I click on further filenames, then the new file replaces the old file, which is what I want to happen.
So far, so good...
However if I resize the windows, then emacs will periodically (when I click) split one of the two windows again, rendering the display difficult to read. It will then cycle opening new files between the two new windows. Occasionally it will open more windows and make the situation worse. If I close any of these new windows they just get reopened again.
In fact sometimes this perverse behaviour happens even if I don't resize anything. It just seems to happen more often if I do.
I would like emacs to stop buggering around and just have one find-grep window and one 'display' window, and always replace the display window with the new file. I would also like to be able to set these windows to the sizes that seem most convenient.
Is there any way to achieve this?
Or can anyone point me to an essay on how the whole (replace the contents of this window/replace the contents of a different window/create another window by splitting) thing works, so I can go and hack it sane.
Short fix:
Try doing this
(setq split-height-threshold nil
split-width-threshold nil)
This will prevent Emacs from splitting windows automatically (horizontally or vertically). This might be undesirable in other situations, but this should do the job. Try it for a week or so and see if it disrupts your flow.
Also, I found that if the point was in one of the windows, and I clicked on a link, the file opened up in the next window (if any).
So, if you want to make the file open in the right window (when you have more than one window), you can ensure that the point is in the window before the window you want.
Longer answer:
OK. I was able to reproduce the problem. The thing is the window showing the files is pretty big (wide or tall) because you resized it and Emacs sees that the width or height is greater than the respective threshold and splits it likewise. So, we have to either make the threshold higher or disallow the behaviour completely.
And, just to answer the last few questions:
To get current window - (selected-window)
To get next window - (next-window)
To select a window - (select-window foo-window)
To get the buffer of the current window - (current-buffer)
To get the buffer of some window - (window-buffer foo-window)
To set a buffer for a window - (set-window-buffer foo-window bar-buffer)
I'm sure you can hack together decent window/buffer management functions using these functions.
You can use C-h f to get more details on each of these functions.
Also check out the Elisp manual - http://www.chemie.fu-berlin.de/chemnet/use/info/elisp/elisp_26.html