When ever I use the C-r history, and use the up/down arrows (or type), the first 2 characters from the line I am interactive with seem to prepend the rest of the line (see images below). I've tried updating my ZSH, which hasn't seem to have changed anything. This did just start happening out of nowhere as well.
Not sure where to go from here, any help would be super appreciated!
Changing ZSH from 5.8 back down to the included 5.7.1 fixed it.
Related
Recently I've discovered a wonderful terminal multiplexing tool called gnu-screen.
I'm satisfied with it completely. But I've encountered one inconvenience I'd like to improve.
'C-a H' command makes screen log everything to a log file called named 'screenlog.*'.
But encodes control characters in a weird way. For example if you open the log file with 'less' you might see some cryptic characters and the log file is unreadable. You have to run 'less -r' or 'less --raw-control-chars' which helps to encode those control characters correctly.
So far so good. But if you want to edit the log or read it with vim then you encounter the same problem with control characters.
I've googled this problem and looked up at SO but I've been overwhelmed because there's so much info about vim and screen. Unfortunately I haven't found the solution yet.
Perhaps you know the solution for this problem or some workaround.
UPD
Thanks to Frédéric Hamidi's comment I discovered those characters are the terminal escape sequences of font color, etc. Vim as an editor sees them and by default edits them. The plugin Frédéric suggested tells vim to interpret them.
To provide an answer here and finally mark this fixed: The AnsiEsc plugin adds syntax highlighting for ANSI color sequences. So instead of seeing ^[[30m; the following text will be highlighting in the corresponding color, just like when using less --raw-control-chars.
I have a problem that is my backspace works in the terminal but not in Vim. It sent '^?' instead of '^H' and I have been trying to figure it out. I have checked my .bashrc and there is stty erase '^?' to remove the '^?' but somehow it is not working.
I have this in my .vimrc:
set backspace=indent,eol,start
set backspace=2
fixdel
This is how I would normally fix it according to my knowledge but it doesn't work in this case. I'm using xterm on Arch Linux server if that helps, I know there is a bug for xterm but I don't think that's the case. It works in Unix command but not Vim, so just the Vim that isn't working.
Any help is greatly appreciated.
Edit:
Um to clarify, I just want my backspace to delete things. My backspace doesn't delete things right now and it is giving me ^? instead of deleting. The deleting is the same as any other system that is ^H but I want to make backspace to send ^H which is delete not ^?. So instead of having to type ^H to delete, I want to do it with backspace, on MobaXterm there is a function that makes backspace to send ^H. But how do I do that on SSH?
Thanks
There's two ways to go. To the left, you see the control-H character you crave. The path that way seems clear, just a little
echo xterm.vt100.backarrowKey: true >> ~/.Xresources; xrdb ~/.Xresources
followed by either restarting all of your xterms, or pressing control and your primary mouse button on each window to bring up the menu that lets you change it per window; the menu item itself is the second one in the third section, it's right under the 8-bit controls option. That way seems to be viable. Except, beware, there's a trap door under the control-H itself, as then backspace stops working properly everywhere else except bash itself. Of course, you have part of the way out of that maze already, with your stty fu. But I kind of recall running into all sorts of other issues with that path. One of them being that the Linux console also uses ^? instead of ^H, and that's not so easy to change.
Or, the other way is to get vim to be able to do what you're trying for, using ^?. Which I think is just
:map ^V^? x
Note that I mean control-V backspace, not caret V caret question. You would also want to add this to your ~/.vimrc if that does what you need. That having been said, you didn't say exactly where in vim isn't working quite right, so it's possible you're needing a different tweak instead.
When typing the beginning of a command in the fish shell the most recent (or frequently?) possible completion of the command is visible in dark grey.
Say I type:
fish
in dark grey: _config is appended.
at this time it is not yet evident, what I'm about to do. So the TAB key shows me all possible completions of 'fish'
I can keep on typing characters, until it's clear what I want. E.g: _con
Now there is only one option to which this could be completed. So I can hit the tab key to see fish_config. However: this was not indicated somehow. In other words: After typing fish_con nothing really tells me that I don't have to keep on typing. Is this the case? Wouldn't this be extremely helpful?
Second question: What is the actual sense of the grey characters? I'd only understand their purpose if there was a way to accept this propose. After typing f, I'd expect a key combination that immediately fully completes to the propose in grey: fish_config.
Even better would be the option let the grey letters cycle through all options, or possible completions based on the history.
The characters to the right of the cursor are called the autosuggestion. They are gray to indicate that they are not actually part of the command, just a suggested completion of what you've typed so far.
So I can hit the tab key to see fish_config. However: this was not indicated somehow. In other words: After typing fish_con nothing really tells me that I don't have to keep on typing
This sounds like you have an idea for an indication when the partial command is a unique prefix of another command. I am not sure what UI you have in mind - what would the indication look like? Please feel welcome to open an issue with your UI ideas.
However if your command is unique, the autosuggestion will always contain it.
Second question: What is the actual sense of the grey characters? I'd only understand their purpose if there was a way to accept this propose. After typing f, I'd expect a key combination that immediately fully completes to the propose in grey: fish_config.
You can accept the autosuggestion by hitting right arrow or control-F. Tab shows you all possible completions, and up arrow lets you cycle through matching history.
You may want to read the fish tutorial, which covers autosuggestions here: http://fishshell.com/docs/current/tutorial.html#tut_autosuggestions
Im facing some problems, I looked around in the forum and didnt find
any solutions discussed. Im sorry if these have been resolved earlier.
Is there someway I can make the VIM line break after 80 characters. I
dont want the text to wrap around but create a new line. And I wish it would
break off the complete last word. So instead of fo in the previous and o
in the next line, can it break with foo in the next line?
When I end my comment and press enter, I get a # in the new line. This is
cool but when I delete # and want to start a line of code, I dont get syntax
highlighting there. It still thinks what Im typing is a comment. Is this a
bug or am I doing it wrong?
One more thing is that I have set the shiftwidth to 4. But when I press
Ctrl+S to save the document, the cursor jumps to the beginning of the
sentence. I then need to manually go back to my original position to begin
the code. Is there a way I can resolve this?
Thank you for reading this. I am new to Ruby and Vim. I hope you guys help
me out.
Ctrl-S ? This is not known to me. In Vim/Gvim, a file is usually saved by
:w filename.ext (if none's been given yet)
or
:saveas filename.ext
(for all of these commands try ":help :w" or ... the same principle).
I don't know about the comment part, since I don't do Ruby, but it would be pretty wise for you to get yourself a nice commenter plugin (I think I use LineCommenter) - eases up on the commenting. Just write the comment, and add the #'s later (set it to work in normal and in visual mode; it works beautifully).
As for the breaking the text part, that could be solved by adding
:set tw=80
"wrapscan" is the vim feature that wraps a whole word to the next line; it might not be set by default in your configuration - probably isn't. So in addition to
:set tw=78 you probably want to try one of these:
:set wrapscan
:set wrap <- just a shorter version
:set nowrap <- to turn the wordwrap feature back off
Incidentally, rather than setting the text width (tw) to some number of characters (smaller than your window), you could instead set the margin you want to leave on the right side of the window like so:
:set wrapmargin=1
If wrapmargin is set to something other than 0, textwidth should be ignored.
I would use ":w" to save and continue editing (or ":w filename" if it's a new file) and "ZZ" or ":wq" to save-and-exit when you're done - none of those will move the cursor position.
I'm not sure where your "#" continuation is coming from, but I'd also make sure to set these if they aren't already (you can check what variables are set by just typing ":set" with no other options):
:set syntax=ruby
:set filetype=ruby
:syntax enable
If you started with an empty document and then added "#!/usr/bin/ruby" to it, vim won't notice you're editing ruby until you save&exit and reopen the file. There are other cases where syntax coloring isn't very bright or needs a nudge but yes, that sounds like a bug to me.
Using Terminal.app on OS X 10.5, often you see the commands get garbled when you do a reverse-search with Bash. Is there some kind of termcap or perhaps a bash shopt command that can fix this? It is very annoying.
Steps to reproduce: Open Terminal.app, reverse-search to a longish command. Hit <ctrl>-E once you've found the command. The cursor goes to the end of the line, but the display doesn't update.
I'm guessing this is some kind of problem with the readline library on OS X. It's more of a problem with updating the cursor position after a search than anything else. Basically, ctrl-a and ctrl-e tend to break the search output.
os x terminal failure image http://involution.com/images/osxterminal.png
In the above, the first part of the command should be displayed, and the cursor should be at the end of the line, but it isn't. You literally can't see what you're editing when this happens.
I was able to set my TERM to xterm instead of xterm-color and it solves the problem. (export TERM=xterm).
You may want to look at this post.
bash-prompt-in-os-x-terminal-broken
I had the same problem and it had to do with the PS1 variable. Let me know if this helps.
If the prompt has colors, then this is an acknowledged bug.
See bug report msg#00019.
I've encountered this bug, and while I don't know how to solve it, you can work around it by pressing <down><up>
Not sure whether this is the problem here, but a very common cause of a messed up screen in bash (with any terminal emulator, not just Terminal.app) is the window being resized.
Bash will read the window size when it starts up, and then assume it hasn't changed. When the window is resized a signal will be sent to whatever app is currently reading from the console. If this isn't bash (because you're running a text editor at the time, perhaps), then bash won't know about it.
Solution in this case is to resize the window again so that bash gets the signal and notices the new size.
I can't reproduce this, hitting either Ctrl+E, Ctrl+A or the arrow keys updates the command line correctly. Are you running 10.5.4? Is it perhaps a bug in earlier versions?
In worst case, you could launch the X server (somewhere under utilities) and launch a real xterm.