On Wednesday, August 22, 2012 2:26:36 PM UTC-5, naphelge wrote:
> I am trying to make the change from long-time gedit user to vim, er gvim and 
> having some teething problems I hope are just that.
> 

You've come to a good place for help. You can also try the #vim channel on 
Freenode, and the wiki: http://vim.wikia.com

The wiki has a nice collection of "Getting Started" tips in 
http://vim.wikia.com/wiki/Category:Getting_started

And of course, I hope you've discovered Vim's excellent built-in help files, 
which document pretty much everything you might need to know about any feature, 
if you know where to look. See http://vim.wikia.com/wiki/Learn_to_use_help

> two of the great things about gedit I find indispensable is the snippets and 
> ext tools plugins. Discovered UltiSnips plugin for vim and it is ok, far from 
> ideal. I can't seem to enter snippets without preceding them with a space 
> first, even though the previous character is generally a <> bracket. Are 
> there any snippet managers available that work more like gedit's, that allow 
> a snippet to tab forward immediately after a > bracket?
> 

There are a wide variety of snippet-related plugins. SnipMate looked pretty 
impressive to me when I saw a video on it once. Search www.vim.org for 
"snippet" and it will turn up several results. Also see the list at 
http://vim.wikia.com/wiki/Category:Automated_Text_Insertion

> gedit's ext tools is great for entering little bash scripts, but I cannot 
> seem to figure out how to do similar with vim. Do I need to port all of my 
> gedit ext tool scripts into individual bash scripts and run them from my 
> ~/bin dir?

I'm not familiar with gedit. Does it have a menu that simply runs a set of 
"bookmarked" bash scripts that actually exist on disk somewhere? If so, you 
could easily run those scripts from Vim. You could even set the path (within 
Vim) like this:

:let $PATH .= ':/path/to/scripts/dir'

And Vim has had the ability to add menus for quite some time. See :help 
creating-menus

> Because I have too many to remember and the menu in gedit listing all of the 
> scripts has always seemed rather convenient. Plus, running scripts from 
> within gedits ext tool menu, the script acts on the current file without any 
> need to bother specifying paths.
> 

You can pass the path to the file for the current buffer to an external script 
very easily, using the '%' character like this:

:!myscript.bash %

You can also "filter" text from an arbitrary line or range of lines through a 
external tool which takes input on stdin and outputs to stdout, replacing the 
filtered lines with the output. For example, to filter lines 7-42 through 
"myscript.bash":

:7,42!myscript.bash

To filter the entire file:

:1,$!myscript.bash

or with less typing:

:%!myscript.bash

> Like I said I hope most of my issues are simply teething probs. But I 
> generally edit a lot of text using sed from the terminal and somehow the :%s 
> option in vim seems less than adequate. I can't seem to figure how to invoke 
> the -r option for regex. Is that possible.

I assume you mean the -r documented here: 
http://www.gnu.org/software/sed/manual/html_node/Invoking-sed.html#Invoking-sed

...which will enable "extended regular expressions".

The short answer is "no" because Vim has its own unique regular expression 
dialect. You can't get strict Posix "extended regular expressions".

See :help pattern.txt for details on Vim's regex dialect.

It IS possible to use \v or \V anywhere in the pattern to allow you to use 
fewer backslashes, if that's what you're after. See :help /\v and :help /\V

> I would be just as comfortable, actually perhaps more so if I could just open 
> a terminal in the current dir of a file I am editing and run sed/perl scripts 
> that way. In gedit I have always remapped C-t (ctrl+t) to open a terminal in 
> the current directory of the current file. Is there any way to do that using 
> gvim?
> 

:help :shell
:help 'autochdir'

Also note that perl and sed are great examples of external tools which take 
input on stdin and print to stdout, so they'd be good candidates for using as a 
filter.

> Those seem to be my biggest caveats atm. I am enjoying the noticeable 
> performance efficiency of gvim over gedit, however my own editting efficiency 
> is taking a serious nose dive atm; but if I could get a few of these issues 
> resolved I think I might get back on track using gvim.
> 
> Oh yeah, one other thing. I got tabs sort of working in gvim...but, for some 
> reason, if I open a new nautilus/thunar session to open a new file then it 
> opens in a new gvim window and does not open in a new tab of the already 
> existing gvim window. Any ideas on that would be great also. I love tabs!
> 

First, be aware that tabs are really "workspaces" and not "a view onto a file" 
and trying to make Vim enforce a one-file-per-tab setup is only going to cause 
headaches.

Then, take a look at:

http://vim.wikia.com/wiki/Buffers
http://vim.wikia.com/wiki/Launch_files_in_new_tabs_under_Unix
http://vim.wikia.com/wiki/Category:Tabs

> I also forgot to ask about vim's clipboard. I seem to be getting it confused 
> with buffers. Does vim have a clipboard that stores multiple copy/yanks and 
> cuts? I use parcellite precisely because I like to keep a long buffer of 
> copy/cut stuff that I tend to need later on. Everytime I try to find info on 
> any functionality like this in vim I seem to get pointed to buffers, which 
> seem to be alternate simultaneously being managed by vim.
> 

Buffers are basically equivalent to files.

You're looking for registers.

See :help registers. You can specify specific registers to cut/copy/paste with 
by prepending " and the register name to the command, like:

"ayat

to yank the XML tag the cursor is in to the 'a' register, and

"aP

to put the text from register a, just before the cursor.

Also see the YankRing plugin (which I don't use), which provides some 
register-management functions. I'm not sure of the details.

-- 
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

Reply via email to