Re: [help]How to auto complete "(),[]"?

[Winfred Lu]

Please search before you ask.

http://tech.groups.yahoo.com/group/vim/message/29162

Re: suggestion

[Yongwei Wu]

Hi David,

On 4/18/07, David Howland <[EMAIL PROTECTED]> wrote:

A.J.Mechelynck wrote:
> You mean if the buffer is displayed it would do nothing?

No.  Delete the buffer, but keep the window open.

I often find myself in this situation:
- Split window, two buffers open.
- Open a new file, look at it, then want to close it.
- i would expect to ":bd" to delete the current buffer, leaving the
remaining two open, one for each window.  But for some reason, it also
removes my split.  Why should deleting a buffer change how I have my
splits set up?


I do not think Vim remembers the history of a window. Do you expect it
to do so (like a browser)?

Best regards,

Yongwei

--
Wu Yongwei
URL: http://wyw.dcweb.cn/

Re: suggestion

[David Howland]

A.J.Mechelynck wrote:

You mean if the buffer is displayed it would do nothing?


No.  Delete the buffer, but keep the window open.

I often find myself in this situation:
- Split window, two buffers open.
- Open a new file, look at it, then want to close it.
- i would expect to ":bd" to delete the current buffer, leaving the 
remaining two open, one for each window.  But for some reason, it also 
removes my split.  Why should deleting a buffer change how I have my 
splits set up?


-d

Re: suggestion

[Edward L. Fox]

On 4/18/07, A.J.Mechelynck <[EMAIL PROTECTED]> wrote:

David Howland wrote:
> Dear Vim gods,
>
> Please consider adding the following command to Vim:
> :bc  (for buffer close)
> It acts just like :bd , except that if the buffer is in a split window,
> it does not remove the window.
> Thank you.
>
> Sincerely,
> dave
>

You mean if the buffer is displayed it would do nothing?


I think he meant that the (:bc)ed buffer should be removed, and a new
*untitled* buffer should be opened in the position of the previous
buffer. So the windows layout would not be changed.




Best regards,
Tony.
--
You will lose your present job and have to become a door to door
mayonnaise salesman.

Re: suggestion

[A.J.Mechelynck]

David Howland wrote:

Dear Vim gods,

Please consider adding the following command to Vim:
:bc  (for buffer close)
It acts just like :bd , except that if the buffer is in a split window, 
it does not remove the window.

Thank you.

Sincerely,
dave



You mean if the buffer is displayed it would do nothing?


Best regards,
Tony.
--
You will lose your present job and have to become a door to door
mayonnaise salesman.

Re: how to enable mouse in vim of cygwin

[A.J.Mechelynck]

sun wrote:

hello,

I know that both vim and gvim can jump from one window to another by
clicking the mouse, also many other easy facilities.
Here I am using cygwin under XP and my gvim works fine with mouse, but
the vim doesn't in both cmd.ext environment and xterm cases.

Please help me.

Best Regards,
sun



If it's a Cygwin build, you may need to make sure that Cygwin can get mouse 
actions (which may need running the gpm daemon, or something) and that Vim has 
the corresponding feature (such as +mouse_gpm or +mouse_xterm) compiled-in.



Best regards,
Tony.
--
The debate rages on: Is PL/I Bachtrian or Dromedary?

how to enable mouse in vim of cygwin

[sun]

hello,

I know that both vim and gvim can jump from one window to another by
clicking the mouse, also many other easy facilities.
Here I am using cygwin under XP and my gvim works fine with mouse, but
the vim doesn't in both cmd.ext environment and xterm cases.

Please help me.

Best Regards,
sun

Re: Cscope find: help

[Gary Johnson]

On 2007-04-17, Ashwin Bharambe <[EMAIL PROTECTED]> wrote:
>  Hi,
> 
>  I would like to filter the results that cscope find sends using some
>  pipe. For example, here's what I would like to do
>:cs find e word | grep -w word
> 
>  This way I can easily add in some things which cscope find doesn't do,
>  sadly. What would be the best way to achieve this? Changing vim code?
>  Or writing vim functions? Sorry, I am new to hacking vim, but I have a
>  lot of experience using vim...

I'm in a little bit of a hurry, so this will be short on details.  
You can run cscope like grep, executing it once for each search 
instead of having it run in the background as it does when you use 
the :cs commands.  Using it that way, you can set 'grepprg' to a 
pipeline something like this:

cscope  $* | grep $*

and just invoke it within vim as:

:grep word

See

:help grepprg

I did something like this for a while to get the output of certain 
cscope commands into the quickfix list before the 'cscopequickfix' 
option was added to vim.  On the machine I was using, I didn't even 
notice any performance degradation over the equivalent search using 
":cs find".

HTH,
Gary

-- 
Gary Johnson | Agilent Technologies
[EMAIL PROTECTED] | Mobile Broadband Division
 | Spokane, Washington, USA

[help]How to auto complete "(),[]"?

[陈方荣]

Hi all,
When type '(',how to autocommplete ')'?And move the cursor in the (_).
Also the '{', autocommplete the '}' in a new line. And insert the 
cursor in a new line.
Like this:
{
_
}
Thanks.
---
Best regards
陈方荣

Cscope find: help

[Ashwin Bharambe]

Hi,

I would like to filter the results that cscope find sends using some
pipe. For example, here's what I would like to do
  :cs find e word | grep -w word

This way I can easily add in some things which cscope find doesn't do,
sadly. What would be the best way to achieve this? Changing vim code?
Or writing vim functions? Sorry, I am new to hacking vim, but I have a
lot of experience using vim...

Thanks!
Ashwin
--
Buxfer - Track Your Money. Effortlessly.  http://www.buxfer.com

Re: A nice efm for javac

[Michael F. Lamb]

> I like to keep the name in, so that when later changes
> are suggested we know who wrote the original.

I don't mind that either :)

>>after the pointer line. That way, the unused error
>>text between doesn't break vim's notion of a
>>"multi-line message" and also doesn't force us to
>>include it as a "continuation of a multi-line
>>message."
>
> Thanks for the update.  Only the last two items changed,
> right?

Correct. (Erm, I must have thought I was about to make many
more changes... sorry, the pedantry was unintentional.) :)

Re: Search for complex regex

[Tim Chase]

i have a html-file with footnotes converted to plain text and
like to replace the footnotes in the text with the
footnotetext many pages later, eg. the occurrence of [12] with
the later definition (many pages later) like [12] "bla bla
bla." Does anybody has an idea, how to achieve this?


Without deeper detail about your file, I'll take a shot.  Some 
assumptions include that a footnote is on one line, that a 
footnote can be found with "^\[\d\+] as a regexp


My basic thought would be to do something like the following logic:

1) use a ":g" command to perform an action on each of my known 
footnotes, as identified by some regexp


2) compose a ":s" command as a string that searches for 
references to the given footnote


3) :exec the resulting string.


My first pass would look something like this 100% untested shot:

:g/^\[\d\+]/exec
'%s@'.
substitute(
escape(
getline('.'),
'@[\\.*&'
),
'\(\[\d\+]\).*',
'\1@&',
''
)

(broken into multiple lines to make it easier to parse, though it 
should all be on one line).  I'm sure I forgot some of the 
characters that need to be escaped, and the resulting regexp 
might not be quite what I expected it to be, but it should be 
pretty close.  You can proof it by changing the "exec" to "echo" 
so it doesn't actually change anything.


You might want to specify ranges, if your footnotes (or rather 
"endnotes") begin at line 3141 in your file, you might alter the 
above to


:3141,$g/^\[\d\+]/exec
'1,3140s@'.
...

so that you're not changing the footnote itself (assuming they're 
end-notes rather than foot-notes)


Another method might be to assume that footnotes are sequential 
and do something like:


:let fn=1
:while search('^\['.fn.']', 'w') > 0 | let fn_text = getline('.') 
| exec '[EMAIL PROTECTED]'.fn.']@'.escape(fn_text, '@[\\.*&') | let fn+=1 | 
endwhile


Neither is particularly pretty, elegant, robust, or 
comprehensible (more like "reprehensible" :) but they're a first 
pass at ideas on how I'd tackle it.


There are problems when an in-line footnote happens to have found 
its way to the beginning of a line and thus get confused for 
being the actual footnote contents, but otherwise, the above 
should be enough to get you started.


-tim

Re: Annoying insertion.

[fREW]

On 4/17/07, Tim Chase <[EMAIL PROTECTED]> wrote:

>> With that knowledge, I'd go spelunking in the $VIMRUNTIME/
>> folders for the tex-related plugins/syntax/filetype files to see
>> if there are "map" commands that should be "nnoremap" commands.
>> Or perhaps you have some of your own additions under $HOME/.vim/
>> that might be bunging matters.
>>
>> -tim
> And what is the difference between map and nnoremap?

Well, there's "map", "nmap" and "nnoremap".  I tend to use
"nnoremap" rotely because it's usually what I mean.

map applies pretty much anywhere

nmap applies only in normal mode

nnoremap also applies only in normal mode, but prevents recursive
expansion.  Thus, if you did something like

   :nmap  g

you'd likely have problems because the  on the right-hand
side (RHS) of the mapping again gets expanded to make it "gg"
which would then be expanded to "ggg", ad infinitum.

   :nnoremap  g

prevents things on the RHS from expanding as additional mappings.
  The same applies to any of the "*noremap" commands.

When I create a mapping, I generally mean "do this list of things
as if they are actual Vim commands, even if I accidentally
overwrite one of its constituent parts with a new mapping".

Each has its uses, but for my general uses, "nnoremap" is almost
always what I mean, so I just type it and think later...or not at
all :)

:help recursive-mapping

has more details on the matter.

> I inserted several map commands. Here is my list:
>
> :syntax on
> imap  :!pdftex book.tex
> map  :!pdftex book.tex
> imap  :!texexec book.tex >/dev/null
> map  :!texexec book.tex >/dev/null
> imap  :!acroread book.pdf
> map  :!acroread book.pdf
> map  1GgqG
> imap1GgqGi
>
> Do you see any that could be causing trouble?

I noticed those in your *vimrc files, but didn't see anything
among them that would have triggered the exact text you had in
your original example (something about "wqa" or "update" or
something like that).  However, if some of the above text appears
in your text at "random", perhaps they are of a problematic ilk.
  There's no harm in changing them to more precise mappings
("inoremap" and "nnoremap") to eliminate one possible source of
problems.

-tim


I noticed your mappings  for help with TeX stuff, and I thought you
might want to check out Vim-LaTeX, if you haven't already.  It can be
found at http://vim-latex.sourceforge.net .  The Tutorial
(http://vim-latex.sourceforge.net/index.php?subject=manual&title=Tutorial#tutorial)
 explains how to use it.  I started using it for some Calculus stuff
I have to write and it really saves me  keystrokes and whatnot.  It
has conveniences for viewing and compiling as well.  I highly
recommend it.

-fREW

Re: A nice efm for javac

[Bram Moolenaar]

Michael Lamb wrote:

>  >> I've put some spare time into an errorformat string and a filter
>  >> script which makes plain-old javac compilation nicer than the
>  >> examples from :help errorformat-javac
>  >
>  > Assuming this works well, it's only for Unix.  Thus I would add it
>  > to ":help errorformat-javac" instead of replacing the existing
>  > example.
> 
> I intended neither but I'd be happy for the former. It's not a 
> significant change, so feel free to omit my name for brevity.

I like to keep the name in, so that when later changes are suggested we
know who wrote the original.

> If you're going to add this to the help files where lots of people will 
> read it, let me be a bit more professional. I've made minor language 
> changes to your modification of my text, below.
> 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Here is an alternative for Unix that filters the errors first: >
>:setl errorformat=%Z%f:%l:\ %m,%A%p^,%-G%*[^sl]%.%#
>:setl makeprg=javac\ %\ 2>&1\ \\\|\ vim-javac-filter
> 
> You need to put the following in "vim-javac-filter" somewhere in your
> path (e.g., in ~/bin) and make it executable: >
> #!/bin/sed -f
> /\^$/s/\t/\ /g;/:[0-9]\+:/{h;d};/^[ \t]*\^/G;
> 
> In English, that sed script:
> - Changes single tabs to single spaces and
> - Moves the line with the filename, line number, error message to just
>after the pointer line. That way, the unused error text between
>doesn't break vim's notion of a "multi-line message" and also
>doesn't force us to include it as a "continuation of a multi-line
>message."
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Thanks for the update.  Only the last two items changed, right?

> I was concerned about this not being a cross-platform solution. I'd be 
> delighted if there were a more elegant (pure-vim) method. Is there a way 
> to have some vimscript modify the errorfile before parsing?

Currently not.  Now that Vim script is powerful enough for this it would
be a good idea to add it.  Don't know how it would work exactly.

-- 
BLACK KNIGHT: I'm invincible!
ARTHUR:   You're a looney.
 "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

 /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

Search for complex regex

[Informationen]

Hi,

i have a html-file with footnotes converted to plain text and like
to replace the footnotes in the text with the footnotetext many
pages later, eg. the occurrence of [12] with the later definition
(many pages later) like [12] "bla bla bla." Does anybody has an
idea, how to achieve this?

Thanks in advance

Chris

Re: Annoying insertion.

[Tim Chase]

With that knowledge, I'd go spelunking in the $VIMRUNTIME/
folders for the tex-related plugins/syntax/filetype files to see
if there are "map" commands that should be "nnoremap" commands.
Or perhaps you have some of your own additions under $HOME/.vim/
that might be bunging matters.

-tim

And what is the difference between map and nnoremap?


Well, there's "map", "nmap" and "nnoremap".  I tend to use 
"nnoremap" rotely because it's usually what I mean.


map applies pretty much anywhere

nmap applies only in normal mode

nnoremap also applies only in normal mode, but prevents recursive 
expansion.  Thus, if you did something like


  :nmap  g

you'd likely have problems because the  on the right-hand 
side (RHS) of the mapping again gets expanded to make it "gg" 
which would then be expanded to "ggg", ad infinitum.


  :nnoremap  g

prevents things on the RHS from expanding as additional mappings. 
 The same applies to any of the "*noremap" commands.


When I create a mapping, I generally mean "do this list of things 
as if they are actual Vim commands, even if I accidentally 
overwrite one of its constituent parts with a new mapping".


Each has its uses, but for my general uses, "nnoremap" is almost 
always what I mean, so I just type it and think later...or not at 
all :)


:help recursive-mapping

has more details on the matter.


I inserted several map commands. Here is my list:

:syntax on
imap  :!pdftex book.tex
map  :!pdftex book.tex
imap  :!texexec book.tex >/dev/null
map  :!texexec book.tex >/dev/null
imap  :!acroread book.pdf
map  :!acroread book.pdf
map  1GgqG
imap1GgqGi

Do you see any that could be causing trouble?


I noticed those in your *vimrc files, but didn't see anything 
among them that would have triggered the exact text you had in 
your original example (something about "wqa" or "update" or 
something like that).  However, if some of the above text appears 
in your text at "random", perhaps they are of a problematic ilk. 
 There's no harm in changing them to more precise mappings 
("inoremap" and "nnoremap") to eliminate one possible source of 
problems.


-tim

Re: Annoying insertion.

[John R. Culleton]

On Tuesday 17 April 2007 12:25, Tim Chase wrote:
> >> -does this happen in one particular type of file but not in
> >> others (such as in *.tex or *.xyz but not in others)
> >
> > Most of the files I edit are *.tex files so that is not much of a
> > distinguishing mark.
>
> Ah well...perhaps a tex-filetype mapping?
>
> >> -does it only happen in one mode?  (only in insert-mode?  only
> >> in normal-mode?  only in visual-mode?)
> >
> > It may happen in insert mode when I hit the F4 key. But from the
> > nature of the latest such message it occurs when I hit the "save"
> > entry on a menu. Or perhaps when I exit Gvim by deleting its
> > window.
>
> This is a good lead.  My first suspicion is that there is a
> definition that uses ":map" when it should be using ":nnoremap"
> (or should have both the ":nnoremap" and a ":inoremap" or
> ":imap") such that when you use  in insert-mode, it uses a
> normal-mode mapping.
>
> >> -when it *does* happen, some post-mortem knowledge of the output
> >>
> >> from the following would be helpful:
> >>:scriptnames
> >>:map
> >>:autocmd CursorHold
> >>:autocmd CursorHoldI
> >>:autocmd CursorMoved
> >>:autocmd CursorMovedI
> >>:menu
> >>:ab
> >
> > Unfortunately I don't discover it until I try to compile a *tex
> > file using e.g., texexec or pdftex.
>
> With that knowledge, I'd go spelunking in the $VIMRUNTIME/
> folders for the tex-related plugins/syntax/filetype files to see
> if there are "map" commands that should be "nnoremap" commands.
> Or perhaps you have some of your own additions under $HOME/.vim/
> that might be bunging matters.
>
> -tim
And what is the difference between map and nnoremap? I inserted 
several map commands. Here is my list:

:syntax on
imap  :!pdftex book.tex
map  :!pdftex book.tex
imap  :!texexec book.tex >/dev/null
map  :!texexec book.tex >/dev/null
imap  :!acroread book.pdf
map  :!acroread book.pdf
map  1GgqG
imap1GgqGi

Do you see any that could be causing trouble?

TIA

John Culleton
Able Indexing and Typesetting
Precision typesetting (tm) at reasonable cost.
Satisfaction guaranteed. 
http://wexfordpress.com



_
Need personalized email and website? Look no further. It's easy
with Doteasy $0 Web Hosting! Learn more at www.doteasy.com

Re: search-related question

[Charles E Campbell Jr]

Hale Boyes, Kevin wrote:


How do I search in a document to the next line that doesn't contain a
specific string?  Something along the lines of "grep -v".
 


I suggest trying the LogiPat plugin.  To do what you're asking with it:

  :LP !"string"

It takes Boolean logic (!=not  |=or  &=and ()s ) plus "strings" and 
constructs a regexp

that'll do it.

You can get the latest LogiPat.vim from

   http://mysite.verizon.net/astronaut/vim/index.html#LOGIPAT
  
or a more stable version from:


   http://vim.sourceforge.net/scripts/script.php?script_id=1290

Regards,
Chip Campbell

search-related question

[Hale Boyes, Kevin]

How do I search in a document to the next line that doesn't contain a
specific string?  Something along the lines of "grep -v".

Thanks,
Kevin.

Using Vim/Gvim 7.0

This email communication and any files transmitted with it may contain 
confidential and or proprietary information and is provided for the use of the 
intended recipient only. Any review, retransmission or dissemination of this 
information by anyone other than the intended recipient is prohibited.  If you 
receive this email in error, please contact the sender and delete this 
communication and any copies immediately. Thank you. 
http://www.encana.com

Re: strange commenting behaviour (text gets deleted)

[Andy Wokula]

Daniel Nogradi schrieb:

Hi vimmers,

I have a very strange problem and couldn't figure out what's going on.
I use the following function for commenting out a line or a block of
lines:


function! Komment2(commentLeader, commentTrailer)
   if match( getline("."), "^\ *$" ) < 0
   let save_cpo   = &cpoptions
   let save_paste = &paste
   set cpo&vim
   set paste
   let escCommentLeader = escape(a:commentLeader, '^[.*\~]$')
   let escCommentTrailer = escape(a:commentTrailer, '^[.*\~]$')
   if getline(".") =~ '^\s*' . escCommentLeader . '.*' .
escCommentTrailer . '$'
   execute "normal ^" . strlen(a:commentLeader) . "x$" .
strlen(a:commentTrailer)
. "hl" . strlen(a:commentTrailer) . "x"
   else
   execute "normal I" . a:commentLeader . "\" . "A" .
a:commentTrailer . "\<
ESC>"
   endif
   let &cpo   = save_cpo
   let &paste = save_paste
   endif
   echo
endfunction


This function is a modified version of something I found in one of the
tips or scripts of the vim website. For C I use of course

Komment2('/* ', ' */')

and this works perfectly well, I can select a block of lines, call the
above function and every line will be commented out. It even works in
a toggling way, so commented lines will be uncommented. So far so
good, now comes the strange behaviour.

If there is a line which only contains a { character and that line is
commented out so it looks like /* { */ and then I call the above
function to uncomment it, everything below this line will be deleted.

It's probably unrelated


It is very related ...


but just in case I mention that I have the
following syntax method set:

syn region myFold start='{' end='}' transparent fold
set foldmethod=syntax


I just reproduced what happens:

With the (syntax) fold opened, go to the first / of the
comment
  /* { */
Then press "x" (or "3x" as the function does), this will remove the /
and CLOSE THE FOLD (WHY??)

The next "3x" will then remove the whole fold.

While trying this out, I had ft=vim set.  It obviously happens with
filetype C too.  It doesn't happen with some other filetypes.
Currently, I have no idea what's going on ...

--
Regards,
Andy

EOM

Indenting behavior is different now that I've updated to vim7 from vim6, why?

[Andrew Falanga]

Hi,

I recently upgraded from vim 6 to vim 7 on my Linux system at work.
Because of how they have stuff configured here at the office, I had to
install to my home directory instead of installing to the system.
This, I don't think, has anything to do with the difficulty I'm
having.

int main( ) {
  // important stuff

#ifdef DEBUG
  std::cout << "Something for debugging here" << std::endl;
#endif
  // more important stuff

  return 0;
}

In the above code example, before upgrading, what would happen is, as
I would write the code in main and then begin the preprocessor
directive line with "#ifdef ..." the cursor would automatically jump
to the beginning of the line and then, when I press the enter key for
the next line, the line would jump to the indentation of the preceding
lines of code before the "ifdef ...".  This no longer happens.  The
cursor does jump to the beginning of the line, but on the next return
key, the cursor is repositioned at the beginning of the line again.
However, I've noticed that, once the preprocessor block is completed,
i.e. I enter the "#endif"; the cursor is repositioned at the indent I
was at in the main function (or conditionals, etc.).

Is this supposed to happen?  I realize that there is a logical
separation from the preprocessor code to the body of the function,
conditional, etc., but I like the old way better.  The other change to
indent that is really annoying (more so than the above) is illustrated
below:

int main( ) {
  std::cout << "This line of test"
<< " cascades with this" << std::endl;


  if( true )
 std::cout << "It's true" << std::endl;

  return 0;
}

In both of the above cases, the behavior I'm used to has the cursor
jumping to the first indent for the function *after* I type the
terminating ';' for the C++ statement.  Now, however, what happens
after I type my ';' character is the cursor is returned to the point
of the "<<" on the second line down from the "first" line of the cout
or the indent level of the conditional statement.  Why is this?  The
previous behavior was much more useful.  Are these expected changes to
the indenting behavior of vim7?  If not, can anyone offer me some
explanation as to why they are not working as they should now?

Thanks in advance for any pointers to this.

Andy

Re: Annoying insertion.

[Tim Chase]

-does this happen in one particular type of file but not in
others (such as in *.tex or *.xyz but not in others)


Most of the files I edit are *.tex files so that is not much of a 
distinguishing mark.


Ah well...perhaps a tex-filetype mapping?


-does it only happen in one mode?  (only in insert-mode?  only in
normal-mode?  only in visual-mode?)


It may happen in insert mode when I hit the F4 key. But from the 
nature of the latest such message it occurs when I hit the "save" 
entry on a menu. Or perhaps when I exit Gvim by deleting its window. 


This is a good lead.  My first suspicion is that there is a 
definition that uses ":map" when it should be using ":nnoremap" 
(or should have both the ":nnoremap" and a ":inoremap" or 
":imap") such that when you use  in insert-mode, it uses a 
normal-mode mapping.



-when it *does* happen, some post-mortem knowledge of the output

from the following would be helpful:
:scriptnames
:map
:autocmd CursorHold
:autocmd CursorHoldI
:autocmd CursorMoved
:autocmd CursorMovedI
:menu
:ab

Unfortunately I don't discover it until I try to compile a *tex file 
using e.g., texexec or pdftex.


With that knowledge, I'd go spelunking in the $VIMRUNTIME/ 
folders for the tex-related plugins/syntax/filetype files to see 
if there are "map" commands that should be "nnoremap" commands. 
Or perhaps you have some of your own additions under $HOME/.vim/ 
that might be bunging matters.


-tim

Re: Annoying insertion.

[Tim Chase]

Recently gvim has had the annoying habit of inserting messages in the 
text of the document being edited, such as


:confirm wqa

Sometimes they are longer.  


I don't see anything glaringly obvious in your supplied vimrc 
files that would trigger such behavior.  However, there's a 
possiblity that some plugin/filetype file is causing the problem. 
 The answers to a few questions might help narrow down where the 
problem originates:


-does this happen in one particular type of file but not in 
others (such as in *.tex or *.xyz but not in others)


-does it only happen in one mode?  (only in insert-mode?  only in 
normal-mode?  only in visual-mode?)


-are there any keys you're hitting immediately before this 
happens (perhaps an errant mapping or triggering a menu option?)


-larger sample-sets of the resulting inserted text might help 
narrow it down to a problematic plugin too


-when it *does* happen, some post-mortem knowledge of the output 
from the following would be helpful:


:scriptnames
:map
:autocmd CursorHold
:autocmd CursorHoldI
:autocmd CursorMoved
:autocmd CursorMovedI
:menu
:ab

(there might be other "autocmd" sections of interest, but those 
are the likely culprits)


Hope this helps,

-tim


PS:

let cobol_legacy_code = 1


Sorry 'bout that...I don't put Cobol on my resume, even though I 
did some maint projects a number of years ago...unpleasant 
memories :)

Re: Annoying insertion.

[John R. Culleton]

On Tuesday 17 April 2007 11:45, Tim Chase wrote:
> > Recently gvim has had the annoying habit of inserting messages in
> > the text of the document being edited, such as
> >
> > :confirm wqa
> >
> > Sometimes they are longer.
>
> I don't see anything glaringly obvious in your supplied vimrc
> files that would trigger such behavior.  However, there's a
> possiblity that some plugin/filetype file is causing the problem.
>   The answers to a few questions might help narrow down where the
> problem originates:
>
> -does this happen in one particular type of file but not in
> others (such as in *.tex or *.xyz but not in others)
>
Most of the files I edit are *.tex files so that is not much of a 
distinguishing mark.
> -does it only happen in one mode?  (only in insert-mode?  only in
> normal-mode?  only in visual-mode?)
>
I seldom use visual mode. 

It may happen in insert mode when I hit the F4 key. But from the 
nature of the latest such message it occurs when I hit the "save" 
entry on a menu. Or perhaps when I exit Gvim by deleting its window. 
> -are there any keys you're hitting immediately before this
> happens (perhaps an errant mapping or triggering a menu option?)
>
See above
> -larger sample-sets of the resulting inserted text might help
> narrow it down to a problematic plugin too
>
> -when it *does* happen, some post-mortem knowledge of the output
>
> from the following would be helpful:
>   :scriptnames
>   :map
>   :autocmd CursorHold
>   :autocmd CursorHoldI
>   :autocmd CursorMoved
>   :autocmd CursorMovedI
>   :menu
>   :ab
>
Unfortunately I don't discover it until I try to compile a *tex file 
using e.g., texexec or pdftex.
> (there might be other "autocmd" sections of interest, but those
> are the likely culprits)
>
> Hope this helps,
>
I will try to retreive those autocommands in some future run. 
> -tim
>
> PS:
> > let cobol_legacy_code = 1
>
> Sorry 'bout that...I don't put Cobol on my resume, even though I
> did some maint projects a number of years ago...unpleasant
> memories :)

Like English, it was the first language I learned. So despite the 
imperfections in both cases they are the natural language and 
computer language respectively I am most conversant with. 

Vi/Vim is not the first editor I ever used but it was early in my 
computer wanderings. 

-- 
John Culleton
Able Indexing and Typesetting
Precision typesetting (tm) at reasonable cost.
Satisfaction guaranteed. 
http://wexfordpress.com



_
Need personalized email and website? Look no further. It's easy
with Doteasy $0 Web Hosting! Learn more at www.doteasy.com

Annoying insertion.

[John R. Culleton]

Recently gvim has had the annoying habit of inserting messages in the 
text of the document being edited, such as

:confirm wqa

Sometimes they are longer.  

Here is my user .gvimrc:

version 7.0
if &cp | set nocp | endif
let s:cpo_save=&cpo
let cobol_legacy_code = 1
set cpo&vim
set syntax=auto
imap  }
map!  
imap  1GgqGi
map!  
map!  
map!  
map!  
map!  
map!  
map!  
map!  
map!  
map!  
map Q gq
map  a\nn{
map  
map  1GgqG
map  
map  
map  
map  
map  
map  
map  
map  
map  
map  
let &cpo=s:cpo_save
unlet s:cpo_save
set backspace=indent,eol,start
set backup
set cmdheight=2
set helplang=en
set history=50
set hlsearch
set incsearch
set mouse=a
set printoptions=paper:letter
set ruler
set scrollopt=ver,jump,hor
set showcmd
set termencoding=utf-8
set textwidth=65

:syntax on
imap  :!pdftex book.tex
map  :!pdftex book.tex
imap  :!texexec book.tex >/dev/null
map  :!texexec book.tex >/dev/null
imap  :!acroread book.pdf
map  :!acroread book.pdf
map  1GgqG
imap  1GgqGi
..
my .vimrc is similar.

I use version 7.109
-- 
John Culleton


version 7.0
if &cp | set nocp | endif
let s:cpo_save=&cpo
let cobol_legacy_code = 1
set cpo&vim
set syntax=auto
imap  }
map!  
imap  1GgqGi
map!  
map!  
map!  
map!  
map!  
map!  
map!  
map!  
map!  
map!  
map Q gq
map  a\nn{
map  
map  1GgqG
map  
map  
map  
map  
map  
map  
map  
map  
map  
map  
let &cpo=s:cpo_save
unlet s:cpo_save
set backspace=indent,eol,start
set backup
set cmdheight=2
set helplang=en
set history=50
set hlsearch
set incsearch
set mouse=a
set printoptions=paper:letter
set ruler
set scrollopt=ver,jump,hor
set showcmd
set termencoding=utf-8
set textwidth=65

:syntax on
imap  :!pdftex book.tex
map  :!pdftex book.tex
imap  :!texexec book.tex >/dev/null
map  :!texexec book.tex >/dev/null
imap  :!acroread book.pdf
map  :!acroread book.pdf
map  1GgqG
imap  1GgqGi

Re: gvim: menu disappeared

[A.J.Mechelynck]

Guido Milanese wrote:

I am sorry to ask such a stupid question, but I'm really puzzled.
I have been using vim for ages now, and for some tasks, not always, I prefer a 
GUI. I use a Mandriva Linux distribution and it's all right.
Suddendly the menu bar (not the toolbar with icons, the menu bar with texts: 
File, Edit, and so on) disappeared. I tried several options of the "set 
guioptions" command, but to no success. I also deleted the .vimrc file, but 
again no change. Then, installed vim-X11 again, but nothing happened.


May I ask your kind help?

Thank you!
guido, from Italy
 


Guido Milanese
http://www.arsantiqua.org



Hypothesis 1: You are actually telling Vim not to display a menu.

How to check: In this case, ":verbose set guioptions?" (without the quotes) 
will either not include the m flag, or it will include the M flag. It will 
also tell you where that option whas last changed.


Solution: Make sure (in your vimrc) that 'guioptions' includes m but not M


Hypothesis 2: Your Vim version is unable to display menus.

How to check: ":echo has('menu')" (without the double quotes) answers 0 (zero).

Solution: Avail yourself of a different Vim executable, or compile it yourself.


Hypothesis 2a: You have installed a Vim version which is powerful enough, but 
you are not using it.


How to check: (1) Same as hypothesis 2 above. (2) In the shell (e.g. in bash):

which -a gvim
ls -l `which gvim`

should help you find out what to do: the first "gvim" listed by the first 
command above is the one which is invoked (you _are_ calling it by the name 
"gvim" aren't you?); the second command will give you more info about it, 
especially in the case of a soft link. The solution will depend on what you 
find out.



Best regards,
Tony.
--
Have people realized that the purpose of the fortune cookie program is
to defuse project tensions?  When did you ever see a cheerful cookie, a
non-cynical, or even an informative cookie?

Perhaps inadvertently, we have a channel for our aggressions.  This
still begs the question of whether the cookie releases the pressure or
only serves to blunt the warning signs.

Long live the revolution!
Have a nice day.

Re: CLTR-N and enter

[Jean-Rene David]

* Eric Leenman [2007.04.17 04:15]:
> Is it possible to select the right word with
> another key then the enter-key, and thus staying
> on the same line before CTRL-N was pressed at
> all?

Yes, just continue typing...

See:

:h popupmenu-keys

It defines the only keys which are special in the
popup menu. Any other key will just have its
normal effect.

-- 
JR

Re: Cream User Preferences

[Steve Hall]

[Apologies, I just realized this message was to the Vim list.]

Barnaby, Cream uses a separate lists:

  http://cream.sourceforge.net/about.html

We try to avoid using Vim bandwidth on Cream configuration.

On Tue, 2007-04-17 at 08:15 -0400, Steve Hall wrote:
> On Mon, 2007-04-16 at 19:43 -0700, Barnaby Robson wrote:
> > 
> > Specifically, if anyone would like to help  I want to set "Tab
> > Expansion" to always be on. Currently any time I switch windows, Tab
> > Expansion turns itself off. (It remains checked in the menu,
> > however)
> 
> Turn on AutoWrap, this sets &expandtab in all buffers. (Cream's Tab
> Expansion option is per buffer for temporary on/off.) If you don't
> like the text wrapping at your Wrap Width, just set it to something
> high like .
> 
> I'll make a ToDo for the errant menu indication.

Re: Cream User Preferences

[Steve Hall]

On Mon, 2007-04-16 at 19:43 -0700, Barnaby Robson wrote:
> 
> Specifically, if anyone would like to help  I want to set "Tab
> Expansion" to always be on. Currently any time I switch windows, Tab
> Expansion turns itself off. (It remains checked in the menu,
> however)

Turn on AutoWrap, this sets &expandtab in all buffers. (Cream's Tab
Expansion option is per buffer for temporary on/off.) If you don't
like the text wrapping at your Wrap Width, just set it to something
high like .

I'll make a ToDo for the errant menu indication.



-- 
Steve Hall  [ digitect dancingpaper com ]
:: Cream... usability for Vim
::   http://cream.sourceforge.net

strange commenting behaviour (text gets deleted)

[Daniel Nogradi]

Hi vimmers,

I have a very strange problem and couldn't figure out what's going on.
I use the following function for commenting out a line or a block of
lines:


function! Komment2(commentLeader, commentTrailer)
   if match( getline("."), "^\ *$" ) < 0
   let save_cpo   = &cpoptions
   let save_paste = &paste
   set cpo&vim
   set paste
   let escCommentLeader = escape(a:commentLeader, '^[.*\~]$')
   let escCommentTrailer = escape(a:commentTrailer, '^[.*\~]$')
   if getline(".") =~ '^\s*' . escCommentLeader . '.*' .
escCommentTrailer . '$'
   execute "normal ^" . strlen(a:commentLeader) . "x$" .
strlen(a:commentTrailer)
. "hl" . strlen(a:commentTrailer) . "x"
   else
   execute "normal I" . a:commentLeader . "\" . "A" .
a:commentTrailer . "\<
ESC>"
   endif
   let &cpo   = save_cpo
   let &paste = save_paste
   endif
   echo
endfunction


This function is a modified version of something I found in one of the
tips or scripts of the vim website. For C I use of course

Komment2('/* ', ' */')

and this works perfectly well, I can select a block of lines, call the
above function and every line will be commented out. It even works in
a toggling way, so commented lines will be uncommented. So far so
good, now comes the strange behaviour.

If there is a line which only contains a { character and that line is
commented out so it looks like /* { */ and then I call the above
function to uncomment it, everything below this line will be deleted.

It's probably unrelated but just in case I mention that I have the
following syntax method set:

syn region myFold start='{' end='}' transparent fold
set foldmethod=syntax

Anyone has an idea what's going on?

Re: A nice efm for javac

[Michael F. Lamb]

>> I've put some spare time into an errorformat string and a filter
>> script which makes plain-old javac compilation nicer than the
>> examples from :help errorformat-javac
>
> Assuming this works well, it's only for Unix.  Thus I would add it
> to ":help errorformat-javac" instead of replacing the existing
> example.

I intended neither but I'd be happy for the former. It's not a 
significant change, so feel free to omit my name for brevity.


If you're going to add this to the help files where lots of people will 
read it, let me be a bit more professional. I've made minor language 
changes to your modification of my text, below.


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Here is an alternative for Unix that filters the errors first: >
  :setl errorformat=%Z%f:%l:\ %m,%A%p^,%-G%*[^sl]%.%#
  :setl makeprg=javac\ %\ 2>&1\ \\\|\ vim-javac-filter

You need to put the following in "vim-javac-filter" somewhere in your
path (e.g., in ~/bin) and make it executable: >
   #!/bin/sed -f
   /\^$/s/\t/\ /g;/:[0-9]\+:/{h;d};/^[ \t]*\^/G;

In English, that sed script:
- Changes single tabs to single spaces and
- Moves the line with the filename, line number, error message to just
  after the pointer line. That way, the unused error text between
  doesn't break vim's notion of a "multi-line message" and also
  doesn't force us to include it as a "continuation of a multi-line
  message."
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

I was concerned about this not being a cross-platform solution. I'd be 
delighted if there were a more elegant (pure-vim) method. Is there a way 
to have some vimscript modify the errorfile before parsing?

Re: Fwd: Perl colour coding bug

[Vigil]

On Tue, 10 Apr 2007, Jon Combe wrote:


The following snippet of code, when saved with a ".pl" file extension
breaks the colour coding in Vim

@split = split ( / |-|\/|\"/ , $surname , -1 );


This sometimes annoys me, too. To work around it, use the 'm' operator 
specifically, thus:


@split = split ( m/ |-|\/|\"/ , $surname , -1 );


--

.

Re: CLTR-N and enter

[homemr]

On Tue, Apr 17, 2007 at 08:09:06AM +, Eric Leenman wrote:
>  Hi,
>  
>  I'm using gvim 7.0 the word-completion function activated by CTRL-N.
>  When selecting the right word by pressing CTRL-N to step trough the list I 
>  select the wanted word with pressing enter.
>  This results in the right word, but also an extra carriage return.
>  
>  Is it possible to select the right word with another key then the 
>  enter-key, and thus staying on the same line before CTRL-N was pressed at 
>  all?
>  
>  Rgds,
>  Eric

Hi! You may want to check vim tip 1386 i found it very useful.
>From there you can get the following map

 :inoremap   pumvisible() ? "\" : "\u\"

 which lets you keep using enter to select the word you want staying in the
 same line .

 RuiH

Re: CLTR-N and enter

[Cyril Slobin]

On 4/17/07, Eric Leenman <[EMAIL PROTECTED]> wrote:


Is it possible to select the right word with another key then the enter-key,
and thus staying on the same line before CTRL-N was pressed at all?


Any key expect selection movement keys works. In particular, space key
is my favorite. ;-)

--
Cyril Slobin <[EMAIL PROTECTED]> `When I use a word,' Humpty Dumpty said,
 `it means just what I choose it to mean'

CLTR-N and enter

[Eric Leenman]

Hi,

I'm using gvim 7.0 the word-completion function activated by CTRL-N.
When selecting the right word by pressing CTRL-N to step trough the list I 
select the wanted word with pressing enter.

This results in the right word, but also an extra carriage return.

Is it possible to select the right word with another key then the enter-key, 
and thus staying on the same line before CTRL-N was pressed at all?


Rgds,
Eric

_
Download Messenger. Join the i’m Initiative. Help make a difference today. 
http://im.live.com/messenger/im/home/?source=TAGHM_APR07

Re: how to avoid deleting the auto-indent in a new empty line when i press

[Andy Wokula]

Gary Johnson schrieb:

On 2007-04-16, fREW <[EMAIL PROTECTED]> wrote:

 On 4/16/07, Tom Whittock <[EMAIL PROTECTED]> wrote:

What I need is to always keep the auto-indented spaces.  So next time
I can start to insert from the spaced cursor.

Alternatively use cc to edit the ostensibly blank line. This will open
the line using the correct auto indent. Get into this habit and it
doesn't matter what state the line was in before - you always get the
right indentation.

Cheers.


 I tried cc and S and neither of them correctly reindented the line for
 me.  What gives?


It may depend on the indentation mechanism being used.  That is, on 
whether you're using 'autoindent', 'cindent', 'indentexpr' or 
something else.  For example, it works fine when I edit C code (with 
'cindent' set) but not in this e-mail (with only 'autoindent' set).  
If I indent this paragraph, then try to add a line below the last 
line by typing S or cc on that empty line, the new line starts in 
column 1.  I don't know why that is.


Regards,
Gary


   :h 'ai
| Copy indent from current line when starting a new line (typing  in
| Insert mode or when using the "o" or "O" command).

cc uses the indent of the current line.  Thus if it is empty there is no
indent.  Try using
   :setl inde=indent(v:lnum-1)

--
Regards,
Andy

EOM

Re: how to avoid deleting the auto-indent in a new empty line when i press

[sun]

>> You may even try (untested)
>>
>>:inoremap   .
>>
With the mapping above, you don't have to add a character then delete it: you
hit the Return key, and Vim (with 'nopaste') maps it to "hit Return, hit dot,
hit backspace", i.e., the insertion-deletion game is played automatically
whenever you hit Return in Insert mode. What more do you want?

...or at least that's how I think it works.


o, now I get your point. This mapping indeed inserts the space.
However, I think the disavantage of this way is one has to append all
inserting commands, e.g, o O, with ..


Best regards,
Tony.

Re: how to avoid deleting the auto-indent in a new empty line when i press

[Gary Johnson]

On 2007-04-16, fREW <[EMAIL PROTECTED]> wrote:
>  On 4/16/07, Tom Whittock <[EMAIL PROTECTED]> wrote:
> > > > What I need is to always keep the auto-indented spaces.  So next time
> > > > I can start to insert from the spaced cursor.
> >
> > Alternatively use cc to edit the ostensibly blank line. This will open
> > the line using the correct auto indent. Get into this habit and it
> > doesn't matter what state the line was in before - you always get the
> > right indentation.
> >
> > Cheers.
> >
> 
>  I tried cc and S and neither of them correctly reindented the line for
>  me.  What gives?

It may depend on the indentation mechanism being used.  That is, on 
whether you're using 'autoindent', 'cindent', 'indentexpr' or 
something else.  For example, it works fine when I edit C code (with 
'cindent' set) but not in this e-mail (with only 'autoindent' set).  
If I indent this paragraph, then try to add a line below the last 
line by typing S or cc on that empty line, the new line starts in 
column 1.  I don't know why that is.

Regards,
Gary

-- 
Gary Johnson | Agilent Technologies
[EMAIL PROTECTED] | Mobile Broadband Division
 | Spokane, Washington, USA