I am working through Learn Vimscript the Hard Way" by Steve Losh. In chapter 32 we build a grep command that puts results in the quickfix window. It looks like this:
:nnoremap <leader>g :silent :exe "grep! -R " . shellescape(expand("<cWORD>")) . " ."<cr>:copen<cr>
It basically works, but when I run it, it will cause characters to become (temporarily) invisible. If I close and re-open the file, the characters come back. Also, if I search for the invisible characters, they appear.
For example, if I run the command with my cursor on ``thedude'' on a block of text like this:
thedude#abides.org
print foo(bar)
print foo(bar)
The two ``print foo(bar)'' lines become invisible. Can anybody guess why this might be happening? I'm using the system default Vim v7.3 on OSX Mountain Lion.
This sometimes occurs when using an external command with the :silent command. You can read about it at :help :silent in the second to last paragraph. There it tells you that you can work around the problem by redrawing the screen after you execute the command or using CTRL-L to clear it manually.
:nnoremap (yadda yadda):copen<cr>:redr!<cr>
Related
TL;DR?
How can I change every instance of one character (e.g. 'E') in a terminal window to another string of characters (e.g. '~E'), moving all other characters along in the window in the process? So:
abcdEfghij
becomes:
abcd~Efghij
This should work in the gnome-terminal and work with whatever output is on that terminal, from whatever program. Ideally it will be a script or other program I can run within that terminal emulator.
The context
I am using a Braille display (the Canute 360) with a Braille screen-reader (brltty), which at present does not support capital letters. They show up in Braille the same as lower-case letters. Until this is developed for BRLTTY I sometimes need to be able to force showing which letters are capitalised in order for me to, for example, write code.
The proposed solution
N.B. The below proposed solution is not intended to be elegant; it is a quick and dirty way of letting me and other Braille-using developers continue to program with this display for our work until the proper solution is forthcoming in the screen-reader proper.
I am trying to essentially 'wrap' the output of the terminal emulator (in this case gnome-terminal to force a certain character in front of every capital letter so on the Braille display it can be identified. I am going to assume that character is tilde (~). I am not concerned about this breaking vertical alignment, or forcing the line off the edge of the display. I am assuming a 40 character wide terminal (width of the Canute).
So this normal output:
$ echo ${string}
A Quick Brown Fox
Jumps over the lazy
Dog. Etc.
$
Becomes this:
$ echo ${string}
~A ~Quick ~Brown ~Fox
~Jumps over the lazy
~Dog. ~Etc.
$
That would then be viewable on the Canute (in US Computer Braille) as this:
$ echo ${string}
~a ~quick ~brown ~fox
~jumps over the lazy
~dog. ~etc.
$
It is fine for this to be a command that has to be called first, like screen. So:
$ caps-hack
$ nano
[doing my thing, then quit nano]
$
[ctrl-x to quit caps-hack]
$
Or alternatively it could launch a new terminal window, or it could be tied to specific TUI applications (like nano). I will primarily be using it for working inside vi, nano, micro and other editors, so if it cannot capture all terminal output the solution is still valuable.
Example use case: Micro/nano text editor
When I need to see capitals whilst editing text using micro or nano I would first launch caps-hack, then I could use the TUI editor, exit it, be back on the terminal, then cancel caps-hack if I wanted to revert to usual behaviour.
This is what nano normally looks like:
GNU nano 4.8 New Buffer Modified
This is a nonsense file for
Stackoverflow.
^G Get Hel^O Write O^W Where I^K Cut Tex
^X Exit ^R Read Fi^\ Replace^U Paste T
I'm looking for a solution that would then make it look like this:
~G~N~U nano 4.8 ~New ~Buffer ~Modi
~This is a nonsense file for
~Stackoverflow.
^~G Get ~Hel^~O ~Write ~O^~W ~Where ~I^~
^~X ~Exit ^~R ~Read ~Fi^\ ~Replace^~U
(Note that I have cut it off at 40 characters.)
The effect would be the same (inserting tildes, cutting off at 40 characters) whether I was in the terminal itself, in mc, or watching a ping stream.
This active use case means that so far as I can see I cannot simply pipe the output of programs to a bash script (like the one below), as that wouldn't work with a TUI. So I cannot do: $ nano myfile.txt | caps-hack
What I have tried so far
I have not worked out how to essentially capture the output, modify it and write it back to the terminal window. However I have the following shell snippet which I believe could be used for it, if I know where to put it.
# Repeat for all visible lines in the terminal
moddedline1=$( echo ${originalLine1} | sed -E -e 's/\([A-Z]\)/~\1/g' )
moddedline1="${moddedline1:0:40}"
tput cup 1 0 && printf "${moddedline1}"
So I'm browsing a file in vim. I realize the function I am looking for is another file. So I do :! ack-grep "function tracking" ../ to look for it, and I see I need to examine file "../../tracking/api/ etc etc" some really long file name. what I'm doing now is trying to remember this file, type fg to get back into vim, and then :e "that really long file name". I'm wondering if there's an easier way to do this?
For instance, can I do something like vim -addtab <some file> from the command line once I've used ack-grep to find what I'm looking for, and then when I do fg to get back to vim, the file will be open in one a tab?
Awesome, lots of suggestions. I'll try them all out and in comments as I do. Then I'll pick what worked best for me once I've tried them all.
So this is the function that I settled on:
function! s:NewTabGrep(...)
let args=split(a:1)
if len(args) == 2
let dir=args[1]
else
let dir='.'
endif
echom args[0] . " " . shellescape(dir)
tabnew | execute "r ! ack-grep ". shellescape(args[0]) ." ". shellescape(dir)
endfunction
com! -nargs=? GrepTab call s:NewTabGrep('<args>')
This performs the search, and opens the results in a new vim tab. Then I can use CtrlP to open whichever file seems most interesting. Thanks to Merlin2011 for inspiration.
You can do :r ! ack-grep "function tracking" ../ to pull the output directly into the vim buffer, and then use gf to navigate to the file under the cursor.
If you want to open the file in a new tab instead, you can do Control-W, gf in normal mode.
Update: If you want the output of the command to appear in a new tab, you can do the following, which opens a new tab, and then immediately pulls the output of the command into it.
:tabnew | r!ack-grep "function tracking" ../
:vimgrep does this by default! it's the best! in fact, it's so cool, that you can even use :vim to invoke it hahaha
e.g. search all python files for "function tracking" (works best if you keep your vim working directory in your source code's root folder)
:vim /function tracking/ **/*.py
^ this will go to the first search result, and then open the quickfix window with a list of search results. I use a binding like nmap <silent> \` :QFix<CR> to quickly toggle it open and off. See... http://vim.wikia.com/wiki/Toggle_to_open_or_close_the_quickfix_window
--
however, there's a better way for navigating to the function: using CTRL-] which does an instant jump to the definition! Combined with CTRL-O and CTRL-I (jump backwards/forwards), you have an unstoppable move-around files-efficiently combo which will make you forget why you ever used IDE's =D
I googled this wiki page: http://vim.wikia.com/wiki/Browsing_programs_with_tags. One other thing you have to do is download Exuberant Ctags and build a tags file in your working directory: ctags -R ...then you're all set! (note that on Macs/BSD, it has its own ctags which wont work, you gotta use the exuberant one)
Vim has the :grep command that runs grep and stores the results into the quickfix list(you can also use :lgrep to load them to the location list). :grep also jumps to the first result, but if you don't want that you can use :grep! to just load the results to the quickfix list.
Once the results are loaded, you can use :copen to open the quickfix list(or :lopen to open the location list) and navigate between the results, or use :cfirst, :cnext, :cprevious and :clast(or :lnext, :lfirst, :lprevious and :llast) for navigation.
So, if you want to open the result in a new file, you have three options:
:grep! "function tracking" ../**/*, :copen to open the quickfix list, put cursor on the first result, ctrl-W Enter to open the result in a new window, ctrl-W T to move the window to a new tab.
:grep! "function tracking" ../**/*, :tabnew to open a new tab, :cfirst to jump to first result.
:tabnew to open a new tab, :grep "function tracking" ../**/* to perform the search and open the first result automatically.
You might find it easier to just use the quickfix list for navigation instead of opening new tabs.
:grep uses grep by default, but you can set the grepprg option to make it use ack-grep instead(you might also need to set grepformat to recognize the output). You can also use :vimgrep to do a search with Vim's regular expression without using an external program, but it will be slower.
:exec 'tab split '.fnameescape(system('ack-grep "function tracking" ../'))
should do the trick. (Make it into a function!)
I recommend you to use the ack plugin., Note that if you have vim-dispatch installed, you can search with ack.vim asynchronously(You need to write: let g:ack_use_dispatch=1 in your vimrc file). Also I recommend ag to replace ack since it's really fast.
I've just started using Terminal (the CLI for Mac OS X).
When I run a command, get some information back, run another command, get more info etc., it is hard (on the eyes) to find a certain point on the screen (e.g. the output for the command before last).
Is there a way of adding a vertical empty space to the end of each output/ after each command is run that has no output?
Each new command that you enter is preceded by a "prompt", and these can be customized (though the exact way to customize depends on the shell). Since you mention Mac OS X I'm assuming you are using the default bash shell, in which case the absolute simplest way to add a blank line is like this: PROMPT_COMMAND=echo. You can run that command to try it out, or add it to a startup file (like .profile in your home folder) to have it done automatically each time.
If you use Bash 4.4 and you want a blank line after your prompt, you could set the PS0 prompt to a newline:
PS0="\n"
Now, this will be inserted every time you run a command:
$ echo "Hello"
Hello
Wondering this too, I've looked at the menu options in Terminal & most of the control characters one can type in and nothing does this on a keystroke. You can however enter an echo command, it alone to leave a single blank line below it before the next prompt. echo \n will add an extra blank line to that, echo \n\n to do 2 extra, ie. 3 blank lines, etc. (you can also do echo;echo;echo getting the same effect)
You can create a shell alias like alias b='echo;echo' (i couldn't seem to get the \n notation to work in a alias), then entering b on a prompt will leave a double-blank line, not bad. Then you gotta figure out how to save aliases in your .profile script.
I tried making an alias for the command ' ' ie. space character, which I though you could type like \ (hmm, stack overflow not formatting this well, that's backslash followed by a space, then return to execute it), but the bash shell doesn't seem to allow an alias with that name. It probably wouldn't allow a function named that either (similar to alias), though I didn't check.
I often use the fish shell, and I found that it does allow a function with that name! Created with function ' '; echo \n; end and indeed it works; at the shell prompt, typing the command \ (again backslash space) leaves a double blank line.
Cool, but.. I tried saving this function using funcsave ' ' (how you save functions in fish, no messing with startup scripts!) and afterwards the function no longer works :^( This is probably a bug in the fish shell. It's in active development right now though, I think I'll report this as a bug since I would kind of like this to work myself.
One could also send Apple a feature request through their bug reporter for an Insert Blank Line menu/keyboard command in Terminal. If someone pays attention to your request it might be implemented in a year maybe.
I wanted to solve exactly the same, and for anyone interested in doing the same, I used what tripleee said in his comment here - I created a .bash_profile (see details here) with the line export PS1="\n\n$ ".
Hopefully that helps someone else too!
I have a .txt (Mac OS X Snow Leopard) file that has a lot of text. At the end of a paragraph, there is a hard return that moves the next paragraph onto another line. This is causing some issues with what I am wanting to do to get the content into my db, so I am wondering if there is anyway I can remove the hard returns? Is there some sort of script I can run? I am really hoping I don't have to go through and manually take the hard returns out.
To recap, here is what it looks like now:
This is some text. Text is what this is.
And then this is the next paragraph that is on a different line.
And this is what I would like to get to:
This is some text. Text is what this is. And then this is the next paragraph that is on a different line.
For all several thousand lines in my .txt file.
Thanks!
EDIT:
The text I am dealing with in my txt file is actually HTML:
<span class="text">1 </span> THis is where my text is<br/>
And when I run the cat command in terminal like mentioned below, only the first is there. Everything else is missing...
In a terminal:
cat myfile.txt | tr -d '\r' > file2.txt
There's probably a more efficient way to do this, since the "tr -d '\r'" is the active ingredient, but that's the idea.
I normally just use an editor with good Regular Expression support. TextWrangler is great.
An end of line in TextWrangler is \r, so to remove it, just search for \r and replace it with a space. TBH, I always wondered how it handles CRLF-encoded files, but somehow it works.
I believe you can do this with Applescript. Unfortunately I'm not familiar with it however the following should help you to acomplish this (it's for a different problem but it will lead you in the direction you need to go): http://macscripter.net/viewtopic.php?id=18762
Alternatively if you didn't want to do this with Applescript and have Excel installed (or access to a machine with it) then the following should help: http://www.mrexcel.com/forum/showthread.php?t=474054
In Linux terminal cat file.txt | tr -d "\r\n" | > new file.txt will do. Modify \r\n part to remove desired charters.
I'd like to have a blank line after my bash prompt and before the output on my Mac. It should look like this would:
echo; ls
Can I add a newline to my bash prompt and then go back up one line to wait for user input? Is there something obvious I'm missing?
I know this is old but for someone like me who came across this while googling for it. This is how you do this...
It's actually pretty simple!
Check out this link --> Cursor Movement
Basically to move up N number of lines:
echo -e "\033[<N>A HELLO WORLD\n"
Just change the "< N >" to however many lines you want to go back...
For instance, to move up 5 lines it would be "/033[5A"
To my knowledge this is not possible unless you delve into more low-level stuff like full-screen emulators like curses.
This is a bit of a stab in the dark, but you may be able to use VT102 terminal codes to control the cursor without having to use Curses. The relevant VT102 commands that you'd be interested in all consist of sending ESC, then [, then the specific command parameters.
For instance, to move the cursor up one line, one needs to output:
ESC [ 1 A
0x1B 0x5B 0x31 0x41
Be warned that the VT102 documentation generally uses octal, so keep an ascii table handy if you're using hex.
All of this advice is given without having tested it -- I don't know if VT102 commands can be embedded into your bash prompt, but I thought it might be worth a shot.
Edit: Yeah -- looks like a lot of people use VT102 formatting codes in their bash prompts. To translate my above example into something Bash would recognize, putting:
\e[1A
into your prompt should move the cursor up one line.
This is very possible. If your bash has C-v set as the readline quoted-insert command, you can simply add the following to your ~/.inputrc:
RETURN: "\C-e\C-v\n\C-v\n\n"
This wil make bash (readline, actually) insert two verbatim newlines before a regular interpreted newline. By default, only one is inserted, which is what causes output to start on the line after the prompt.
You can test if C-v is set to quoted-insert by typing it in bash (that's Ctrl+V) followed by e.g. an up arrow. This should print ^[[A or something similar. If it doesn't, you can bind it in ~/.inputrc too:
C-v: quoted-insert
RETURN: "\C-e\C-v\n\C-v\n\n"
~/.inputrc can be created if it doesn't exist. The changes will not take effect in running bashes unless you issue a readline re-read-init-file command (by default on C-x C-r). Be careful though. If you do something wrong, enter will no longer issue commands, and fixing your mistake could prove to be difficult. If you should do something wrong, C-o will by default also accept the line.
Adding a newline followed by moving the cursor back to the regular prompt (like you described) is possible, but will not have the effect you intend. The newline you inserted would simply be overwritten by the application output, since you moved the cursor back in front of it.
This works:
trap echo DEBUG
It doesn't add an extra newline if you hit return at an empty prompt.
The command above will cause a newline to be output for every member of a pipeline or multi-command line such as:
$ echo foo; echo bar
\n
foo
\n
bar
To prevent that so that only one extra newline is output before all command output:
PROMPT_COMMAND='_nl=true'; trap -- '$_nl && [[ $BASH_COMMAND != $PROMPT_COMMAND ]] && echo; _nl=false' DEBUG
The DEBUG trap is performed before each command so before the first command it checks to see if the flag is true and, if so, outputs a newline. Then it sets the flag to false so each command afterwards on the line doesn't trigger an extra newline.
The contents of $PROMPT_COMMAND are executed before the prompt is output so the flag is set to true - ready for the next cycle.
Because pressing enter on an empty command line still triggers the execution of the contents of $PROMPT_COMMAND the test in the trap also checks for those contents as the current command and doesn't perform the echo if they match.
I believe (but haven't tried) if you put '\n\b' in the prompt string it would do that.
In general, if you want to find out the codes to do anything a terminal can do, read the terminfo man page.
In this case, the cursor up one line code can be determined by:
tput cuu1
If you redirect the tput output to a file, you can see what control characters are used.
Bash also supports the PROMPT_COMMAND variable, allowing you to run arbitrary commands before each prompt is issued.