Re: gedit to gvim/vim teething issues

On 08/22/12 18:04, naphelge wrote:
> Thanks for the fast replies.

The list is pretty amazing like that :-)

> nnoremap ,cd :cd %:p:h<CR>:pwd<CR>

You might also want to check out

:help 'autochdir'

It's unset by default, but could make this even easier for you.

> nmap <silent> <leader>te :!/usr/bin/xfce4-terminal<CR>
> With these two mapped keys I can switch the current VIM window to
> the $PWD of the file I am currently editing and then execute the
> command to run a terminal in the directory. Almost perfect, but
> while in terminal the gVim file is unavailable. Is there a way to
> run the terminal concurrent with the opened file so I can edit
> the file, run commands in the terminal to edit the file and back
> and forth like that?

The old *nix trick of appending the ampersand:

:nnoremap <silent> <leader>te :!/usr/bin/xfce4-terminal &<cr>

to fork a process rather than run-and-wait-for-exit. You'll have to
hit <enter> after it has spawned, but at least you get Vim back in
your control.

> also, it seems like gVim gets hung up when I run a sed command

Could you detail how you're running sed? I occasionally forget to
pipe input to sed/grep and think I made some grievous error, only to
smack my forehead upon realizing that it's sitting there waiting for
me to feed it input on stdin.

> let's say on the file. I get a message box informing me the file
> has changed with the options to hit ok or load file. But often
> enough gVim gets hung up puking back an 814 error and I have to
> quit out and re-open my files.

This sounds awfully peculiar. If you call some external program
(such as sed) and it modifies the on-disk file in place, Vim should
pick up on that upon regaining the foreground. If you haven't
changed the file in Vim, it should offer you the choice you got
(reload vs. ignore). If you modified the buffer without saving the
changes, then modified the file on disk, you now have a quandary of
which modified file do you want. I'll often instruct Vim to ignore
the file on disk, yank the entire contents (":%y") and paste them in
a new buffer (":vnew", "PGdd"), go back to the original file and
force a reload of it (":e!") to get the other modified version, then
use Vim's diffing abilities to compare the two (":diffthis" in each
window). That allows me to have both versions and make sure I
eventually save what I really want.

That said, I've never had Vim hang up or crash on me in such a scenario.

> I had this sorta problem with gedit where it would crash
> frequently opening and editing large text (500K-5Mb+ on the
> extreme end). I turned to gVim hoping it will be better able to
> handle such large files.

That hardly qualifies as a large file for Vim.

:help limits

details the hard limits. Some larger files may be a bit less usable
(i.e. more sluggish) depending on your system/OS configuration, but
if you're editing such larger files, there are some tips for working
with them at

http://www.vim.org/scripts/script.php?script_id=1506

> Registers does sound like what I must be looking for and I will
> certainly check out yanking if that helps me to more visually
> access past copy/paste items.

You can yank/delete to named registers--I usually run out of my
ability to remember what I stashed in which register long before I
actually run out of the 26 named registers. You can get a list of
what's been stored by typing

:reg

> I did find the 1600 or so wikiTips that all look like they will
> be useful at some point.

Vim is thoroughly documented and there are plenty of tips--the trick
is to learn how to navigate the jungle to find what you need. So
the earlier suggestion about reading up on help-navigation is
surprisingly, well, helpful. Also, as you may have guessed by your
brief interactions with the list, some of us are a bit more prolix
than others, whether for better or worse. :-)

-tim



--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php