I use OSX and prefer a dark BG and light text in my terminal. A problem is that the mouse pointer is almost invisible. Its the I shaped pointer, its black with an extremely faint white glow. I often can't see where the pointer is.
If the terminal does not have focus and I'm hovering the mouse pointer over the terminal window I can see it fine. But once the terminal has focus the pointer practically disappears.
Please note, I'm asking about the mouse pointer not the terminal keyboard cursor, which is easily customisable.
Holding down the alt key on Mac OSX changes the cursor to a black cross that has a white border which makes it far easier to spot than the default text bar.
A better term to look for is "mouse pointer". Here are some places where it has been discussed:
Change default mouse cursor on OSX Mavericks
Can I make the mouse hairpin in the terminal more visible?
Terminal app mouse-pointer invisible
More than one solution is suggested, including add-ons (which you may or may not find useful).
Following the links in Thomas Dickey's answer, I saw many references to iTerm2.
While this won't be the solution for everyone, it's definitely worth a try - GPL2, easy to install and configure.
Out of the box, no contrast issues with the text cursor or mouse pointer against a black background. I just adjusted font size and switched on window borders.
Related
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
Looking for a way to control text/cursor highlighting colors when in vi-mode in tmux. I can not seem to find many answers from googling around. I love tmux and use this feature quite a bit, and I have been living with this flaw for some time and still have not been able to find a solution. You can view my dotfiles here. Keep in mind that my master branch is my OSX setup, and I have an "arch" branch for my Arch linux setup. The issues occurs on both systems. Though the colors are slightly different, but not by much.
Here is current symptoms: (both systems) I am in a tmux session, I want to enter into vi-mode for either searching or copying some text. When copying text (hitting v while in vi-mode for visual) the highlighted text and background are both black. So I can't see the text I am highlighting. Or while searching (hit "/" while in vi-mode for searching) my background and text on the entire line where my prompt is for typing the text I want to search is all black. So I have no idea what text is actually in the search. If I mis-type something due to fat fingers and nothing returns in my search, it can be frustrating. One last symptom (which is a minor one, but would be nice to solve) When I do search, I get absolutely no highlighting over than my normal cursor. Not like my vim set up where it highlights currently found, and all other matches.
Here is what the desired fix would look like: Searches would highlight in some shade of yellow or orange on all matched text. Searching prompt to type in search text would be at least readable. Anything but Black on Black. Highlighting text while selecting what to copy in visual mode again anything readable, no Black on Black.
Other things to note: I typically have mouse-mode on in tmux to promote keyboard-driven approach and not allow any selection of text via mouse selection. But when I do toggle this feature off and can then select text via mouse, the highlighted text background is white and text is black. While readable, would still wish to know how to control this color as well. Also (not sure any vim settings actually carry over to tmux) but everything works as desired while actually in vim. Just in case vim settings here. Same note about branches.
Most of my tools are latest versions afaik. This includes Tmux 2.1. I do not have full list of versions of my tools as of right now. If this may play a part in debugging let me know and I'll reply with versions. For what its worth other tools that might be in conflict is my shell I use zsh with on-my-zsh. On my mac I am using iTerm2, on arch I'm using URxvt. Doubt any of my .Xresources matter since it also happens on OSX.
Any help is greatly appreciated. Thanks in advance.
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.
The short version is that I've turned the brightness way down on my monitor and now I'm having problems finding the mouse cursor in eclipse (the text cursor). When it's a pointer cursor it's fine, but when it goes to the text cursor I can barely see it. Half the time I'm guessing where it is.
To be quite honest this is for all of Windows, but it's really a problem for me in eclipse where I spend a lot of time.
Update: I have looked at the windows settings, specifically the "Text Select" under "Pointers", but I'm not sure what to replace it with. I don't know anything about the .cur file it requires.
I am not sitting at a Windows box right now, so I can't try, but you can set the mouse cursor in the system settings / mouse settings. You can set specific cursors, like the text cursor. Windows ships (at least: shipped) with cursor themes that are much better visible. The same problem can occur when you need the "precision select" cursor - a small negative cross, invisible on grey background. But there are replacements with strong contours that are easily visible. So you don't have to change the whole pointer theme, if you don't want to, but can change just this one or two problematic.
I did this when using Windows XP, I hope it still is valid for 7.