I have a random problem which I personally find quite irritating. I use the terminal alot and have installed a theme and even toyed around with what is displayed on the prompt. However if I write a particularly line of text it does not start a new line in the terminal instead it will begin overwriting what is displayed on the screen in the current terminal line. I wondered if anyone knew a way to solve this so that it does show a new line and all input would be visible.
PS1 value
export PS1="\r\n\e[1;32mdave:\w $\e[0;37m "
Well, thanks to the post by #Joni, I believe the solution is:
PS1="\r\n\[\e[1;32m\]dave:\w $\[\e[0;37m\] "
That is, here the color codes \e[1;32m and \e[0;37m are enclosed within \[ and \], as #Joni suggested they should be.
Non printing characters, like escape codes for color, have to be surrounded with \[ and \] so that bash knows to exclude them when calculating the length of the line.
http://www.tldp.org/HOWTO/Bash-Prompt-HOWTO/nonprintingchars.html
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.
So I'm attempting to print a show an image of a url using the 'image' command in shoes. The issue is that my url contains % characters. This would not be an issue most of the time since I could just escape it but Shoes does not behave like I would expect it to. I've looked through the manual and other sources from Shoes but none seem to mention how to print use special characters.
Essentially right now alert yields...
alert "%D" --> 2743522352
alert "\%D" --> 3439909232
but what I really want is
alert "%D" -->%D
how can I make this happen?
I am not able to reproduce this problem on red shoes. But I guess, to solve the problem, you should use single quotes instead of double quotes.
alert '%D' -->%D
Because in ruby, single quotes escape everything inside it.
Hope it helps :)
I found an annoying bug while coloring the prompt of my Terminal. If I set my prompt to a colored one, such as
export PS1='\e[1;34m[\e[0;31m\D{%Hh%M} \e[0;32m\u\e[0m#\e[0;35m\h\e[0m:\e[0;36m\w\e[1;34m]\e[0m $ '
then it starts to break when I get some size in the input line:
In other words, when my line reaches some limit, it starts over itself! Once I fill the same line again, then it works well, going to the next line.
Have anyone seen this problem, too? Do you have a solution? The problem also happens in iTerm.
This is a duplicate of Mac Terminal.app annoying bug - How to fix it? from StackOverflow. The problem is that you must surround terminal control characters in square brackets \[ … \] so that the bash shell doesn't count them when calculating the length of the command prompt.
Since this is a generic shell/terminal question and not specific to Mac OS X or Terminal, this should probably be migrated to StackOverflow and made a duplicate of the other question. (However, I don't have privilege to do either.)
When I'm typing a command longer than around 20 characters the text disappears and the cursor moves to a different location in the terminal. How do I stop this? I find it difficult to understand what I'm doing when this happens.
Your $PROMPT may have escape sequences in it that should be wrapped in %{...%} to keep them from being counted when zsh calculates the length of the displayed prompt.
There could be an incorrect TERM type, resulting in incorrect cursor positioning. For OS X Terminal.app, this term type works well for most curses-based apps:
$ echo $TERM
xterm-color
It should also work well in xterm.
Does not happen here so I suspect something in your setup probably of zsh.
Have you tried moving all your ~/.zsh* files and start with a blank environment?
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.