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.
Related
In the Alternate Screen Buffer mode in XTerm-like terminal emulators, when the cursor is on the last row and the terminal window is resized so that it has less rows, all text in the terminal is shifted upwards.
Can anyone point me to what is going on here? I can't find any related escape sequences to turn this behavior off, or any way to intercept SIGWINCH to move the cursor before the shift happens. It seems like it may be related to scrolling to keep the cursor on the screen.
I'd really like the screen display to not change, even if the cursor is no longer on screen after a resize.
I'm not using ncurses or other libraries, just escape sequences and system calls.
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.
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 text is highlighted in vim, for example using the 'em' tag when writing a HTML document, I find that in some color schemes the cursor becomes invisible, making it difficult to correctly place the closing tag. Is there a way to have the cursor change color over highlighted text?
Change color of cursor in gvim
Look at both answers sir, I think you'll have your answer in there....
You'd have to hook into the CursorMoved,CursorMovedI events and then determine the highlight group under the cursor with synIDattr(synIDtrans(synID(line("."), col("."), 1)), "name"). If it's one of those diffcult-to-see groups, you can issue a :highlight Cursor ... command to change it (or else change it back).
But this is rather complicated. Why don't you simply modify the colorscheme and choose a color that is easily recognized under all circumstances?! (The :hi command lists all colors and helps you choose one.)
This problem led me down quite a rabbit hole and caused me to learn a lot more about how syntax highlighting works than intended.
I learned that the reason my, supposedly italic, text was highlighted in the first place, is because the Mac terminal doesn't support italics ("Enabling italics in vim syntax highlighting for mac terminal")
I realised, thanks to "Colour colour everywhere! 256 colour-mode for Linux consoles", that due to the color profile I had chosen in Terminal's preferences, my "bright" and "normal" colors showed no difference, and for that reason my color profiles never looked like the screenshots.
And, finally, I solved my cursor getting lost problem by changing the cursor color in the Terminal preferences.
I finally figured out how to split panes in Xcode, and I even finally found out that if I hold option when I split panes, I can do a vertical split too.
But I seem to have run into a bug. When I spawn a separate text editor and split panes within it, I can split panes horizontally, or vertically, but not both. Has anyone else run into this?
However, if I split within the main project window, which includes Groups & Files pane, I can split both ways.
What's the deal?
Oh how I wish I could just do Cocoa in emacs. C-x 0,2,3, and my favorite C-x C-f.
While I'm at it, how do I jump down a block, like I would do with ctrl-down in emacs?
That certainly seems to be a bug; you should file it with Apple.
Oh how I wish I could just do cocoa in emacs
What's stopping you? Cocoa code is just made up of text files like anything else. I've certainly never had any problems editing Objective-C in vi.