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.
Related
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.
I am trying to install VIM Powerline on window, I found a comment which supposed to fix how it looks in Windows, but encoding of the comment is broken by itself...
The link to the blog post.
I had the same problem on windows. As an alternative to editing “vim-powerline-develop\autoload\Powerline\Functions.vim”, you can also add this to your vimrc:
let g:Powerline_mode_V=”V·LINE
let g:Powerline_mode_cv=”V·BLOCK”
let g:Powerline_mode_S=”S·LINE”
let g:Powerline_mode_cs=”S·BLOCK”
I don't know how to type the cdot operator in my keyboard (sorry for the name, I guess I am too much into Latex ...).
So, what am I supposed to do to make VIM behave under windows?
To get the middle dot, the easiest and pragmatic way would be just pasting it from the clipboard.
For direct text entry, you can enter by the character encoding's numerical value: <C-v>183, see :help i_CTRL-V_digit. On Windows, you often need to use <C-q> instead of <C-v>.
Vim also has a feature called digraphs for quick entry of special characters. The middle dot would be <C-k>.M.
For any of these to work, your text encoding must support the non-ASCII character. Best use a value of
:set encoding=utf-8
and ensure that your ~/.vimrc is UTF-8 encoded.
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.)
One of my application components produces some extremely hairy log files. They require a lot of poking and prodding before they produce useful information. I'm on the hunt for a text editor for windows that will let me enter text in either RegEx or Grep-style syntax, and automatically show/hide the relevant lines.
Does anyone know of a text editor that has this feature?
Thanks!
IVR Avenger
I know it's answered already, but http://glogg.bonnefon.org/ is the perfect answer for this. Couldn't live w/o it.
I would recommend Notepad++ as far as a good all-around Windows text editor is concerned - it is very extensible and includes just about every power feature you need to wade through data logs. If your log files are in a well-defined format, you can even use the built-in language editor to define a custom visual scheme for your logs - easier on the eyes.
-matt
GVim with for example, :g command. There are also plugins that allow entering search criteria, and they show relevant lines, and fold everything else.
Emacs, of course (occur), but I think pretty much every editor will do this.
Another option is SlickEdit using it's "Selective Display..." option
Although it wont show/hide based on a regex, Textpad will allow you to search and produce a hyperlinked result file with the lines that will allow you to click into the actual log. Consider the benefit: You can keep the filtered results up on your left monitor, and you can click into the full files and show them on your right monitor to see the context.
SPFLite is free and does just what you want. At least the IBM SPF and ISFP (used on IBM mainframes as part of the MVS operating system) that it emulates is just what you want.
From what I have tried, SPFLite will probably do the job. It can X (exclude) all lines from view, or eXclude lines with a given character or phrase (optionally starting in a certain column) from view. Or after eXcluding all lines, you can display, by Finding, characters or strings (optionally starting in a certain column). I think it also has a macro capability. The original does, and I think this Lite does as well. How robust I do not know. The original could create interactive screens and programs using the MVS TSO Command Language.
I found SPFLite at http://www.spflite.com/
I found that this interface is not so easy to use, but one gets used to about anything if necessary.
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.