Re: Can 'set ' be elided? When?

On 31/03/13 17:24, Dotan Cohen wrote:
> On Sat, Mar 23, 2013 at 12:58 AM, Paul Isambert <zappathustra@free.fr> wrote:
>>> I notice that some settings use the format ':set name=value' and other
>>> use ':name value'. For instance:
>>> :set syntax=php
>>> :syntax off
>>
>> Note that ":syntax php" doesn't work.
>>
>>> Can the string 'set ' always be safely elided?
>>
>> No.
>>
>>> If not, then what are the guidelines?
>>
>> As far as I can tell, there aren't any. Some commands have the same name as
>> options (e.g. :filetype and 'filetype', :confirm and 'confirm'), but they don't
>> do the same things.
>>
>> Best,
>> Paul
>>
>
> I notice that the following doesn't work:
> :syntax php
>
> However the following does work:
> :colorscheme desert
>
> Why is "syntax" an option yet "colorscheme" a command?
>
>
>
> --
> Dotan Cohen
>
> http://gibberish.co.il
> http://what-is-what.com
>

There is both a :syntax command and a 'syntax' option, and they are not
interchangeable: The command can be:

:syntax on
:syntax off
:syntax enable
:syntax list " with optional arguments
:syntax sync fromstart
:syntax sync clear
:syntax sync ccomment
" also other variants
:syntax sync " with no arguments: "tell me"

etc. Most of the variants of this command are for use in syntax scripts,
to define how the particular syntax of a certain filetype must be
highlighted. ":syntax on" can be used in your vimrc to enable syntax
highlighting. ":syntax sync" with no arguments and ":syntax list" are
used from the keyboard, to request information.



The 'syntax' option is something else: it defines which named syntax
applies to a given file. It can be set, usually by ":setlocal"; normally
this is done automatically as part of the FileType event handling. You
can also do it manually, for instance

:setlocal syntax=

to remove all syntax highlighting for one editfile only, until it is
reloaded.



As for the :colorscheme command, ":colorscheme foobar" is approximately
equivalent with (IIUC) ":doautocmd ColorScheme foobar | runtime
colors/foobar.vim" which is also a command. If you want to determine
which colorscheme is in use, you should check the global variable
colors_name which every properly constructed colorscheme will set to its
own filename (without the path and the .vim extension). You can do that
with ":colorscheme" with no argument, which (in a Vim with +eval
compiled-in) does something similar to ":if exists('g:colors_name') |
echo g:colors_name | else | echo 'default' | endif", another command.


Best regards,
Tony.
--
LETTERS TO THE EDITOR (The Times of London)

Dear Sir,

I am firmly opposed to the spread of microchips either to the home or
to the office. We have more than enough of them foisted upon us in
public places. They are a disgusting Americanism, and can only result
in the farmers being forced to grow smaller potatoes, which in turn
will cause massive unemployment in the already severely depressed
agricultural industry.

Yours faithfully,
Capt. Quinton D'Arcy, J. P.
Sevenoaks

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Get netrw to ignore executability of file

On Mar 31, 6:46 am, Christian Brabandt wrote:
> On windows, there is no executable bit and is actually not needed,
> because only certain file types are executable. So in principle is
> should be possible to simply highlight .exe .bat .cmd .com files as
> executable on Windows.

Hi, Christian,

I would say that you're right in principle. However, cygwin seems to
use a different scheme to determine whether the executable bit is
set. I haven't yet figured out exactly what the scheme is.

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Vim freezes with 100% cpu usage on exit

Hi

I'm experiencing a bug with vim inside virtualbox running ubuntu 12.04 LTS(which automatically installs guest additions). I noticed the bug happens with the following actions:

1 - I open vim inside a tmux session and start working on some project. I always have two files open in vertically split window(not sure if this is relevant)

2 - I detach the tmux session, save virtualbox state then shutdown my computer.

3 - Some time later(like 30 minutes) I turn my computer on, resume virtualbox and reattach to the tmux/vim session.

When I reattach, everything is working normally, except when I try to quit vim with :qa . When I do that, vim freezes and starts to consume 100% cpu until I send a SIGKILL.

This always happens with me. The vim version I'm using is the one that comes with ubuntu 12.04 LTS(7.3.429), but I also have tested with the latest build(875) and the problem persists. The ubuntu guest only contains the minimal install (console-only)

To whoever is interested in investigating this bug and fails to reproduce it: just ask and I will try to collect more info about my working environment.

Thanks in advance.

--
--
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
 
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Re: "hi netrwCopyTgt" doesn't bold netrw's target directory for copy

On Mar 31, 3:32 am, Tony Mechelynck wrote:
>On 31/03/13 09:16, AndyHancock wrote:
>>On Mar 30, 7:20 pm, Charles E Campbell wrote:
>>>AndyHancock wrote:
>>>> I am trying to get my netrw marked files to show up as yellow,
>>>> and the target directory for copying marked files to show up as
>>>> bolded
>>>> <...snip...>
>>> The netrwCopyTgt syntax is transparent. You need to get rid of
>>> that modifier. So, put in your .vim/after/syntax/netrw.vim file:
>>>
>>> syn clear netrwCopyTgt
>>> syn match netrwCopyTgt "Copy/Move Tgt:" contained skipwhite
>>> nextgroup=netrwList
>>> hi link netrwCopyTgt Unique
>>>
>>> where Unique is whatever color you want (or, instead of hi link
>>> ..., use hi and fg= bg= etc specifications).
>>
>> I put the lines into cygwin's /usr/share/vim/vimfiles/after/syntax/
>> netrw.vim. In place of "hi link netrwCopyTgt Unique", I put
>>
>> hi netrwCopyTgt term=bold cterm=11 gui=bold guifg=yellow
>>
>> When I editted a directory path and netrw is invoked, I pressed "a"
>> to cycle through the hiding list modes until nothing was hidden. I
>> got the error:
>>
>> Error detected while processing
>> /usr/share/vim/vimfiles/after/syntax/netrw.vim:
>> line 5:
>> E492: Not an editor command: nextgroup=netrwList
>>
>> I then commented that line out. The effect of netrw's "mt" was to
>> highlight the words "Copy/Move Tgt:" in the header. The target
>> file itself was not highlighted. Is that what the commented line
>> should have done?
>
> There was a spurious linebreak in the email. "nextgroup=netrwList"
> should either have been at the end of the previous :syn match line,
> or else have a backslash at the start to mark it as a continuation
> line.

Thanks Tony. Appending

nextgroup=netrwList

to the end of

syn match netrwCopyTgt "Copy/Move Tgt:" contained skipwhite

eliminates the error message, but the text that is highlighted by

hi netrwCopyTgt term=bold cterm=11 gui=bold guifg=yellow

is still only the text "Copy/Move Tgt:" in the header region of the
netrw window. The occurance of the directory name itself in the file
listing part of the netrw window is not highlighted.

This is better than it was before, though. Thanks again, Tony,
Charles.

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: gVim Hanging/Freezing When Closing

On Friday, March 29, 2013 11:45:32 AM UTC-6, Charles Campbell wrote:
> Christian Brabandt wrote:
>
> > Hi Kenny!
>
> >
>
> > On Do, 28 M�r 2013, Kenny Ballou wrote:
>
> >
>
> >> Hey all.
>
> >>
>
> >> I haven't found anything on this, and it might be relatively new (i.e., new
>
> >> kernel/ new vim release); but I am having an issue with gvim hanging when I try
>
> >> to close. That is, the gvim window is clearly _trying_ to close (doesn't
>
> >> redraw, no longer responds to commands, etc.) but can't, stuck waiting for ...
>
> >> something.
>
> >>
>
> >> Behavior or characteristics I have discovered so far.
>
> >>
>
> >> * Happens with a file in buffer or without
>
> >>
>
> >> * Only happens when launched from system launcher (e.g., Alt-F2) or from a
>
> >> shell
>
> >>
>
> >> * Does *not* happen when launched by double-clicking a file in a file manager
>
> >>
>
> >> - Tested with Dolphin and Krusader
>
> >>
>
> >> * Frozen gvim windows have wait channel of `futex_`
>
> >>
>
> >> * Is local to gvim; vim is unaffected
>
> >>
>
> >> I'm not sure what needs to be done to further debug this and/or fix. This
>
> >> happens on both of my main working machines and only started recently (in which
>
> >> time I have had a vim update and a kernel update).
>
> >>
>
> >> Other relevant information (both machines):
>
> >>
>
> >> * KDE 4.10.1 with Openbox (3.5.0-7) window manager
>
> >>
>
> >> * See bugreport.txt
>
> >>
>
> >> Thanks in advance for any help and/or insight anyone can provide.
>
> > You might want to strace it or build gvim with debugging symbols and
>
> > attach gdb to it and print a backtrace.
>
> >
>
> Just in case its a plugin or otherwise doing something when an autocmd
>
> is firing, try
>
> :set verbose=20
>
>
>
> just before closing. You should see what commands are being executed
>
> and where gvim is hanging.
>
>
>
> Regards,
>
> C Campbell

C Campbell,

I finally got a chance to try your suggestion and have found that poweline (the new python version) is at fault and the problem is an already open issue for the project (https://github.com/Lokaltog/powerline/issues/371).

I will have to either downgrade powerline or disable it entirely, for now.

Thanks,
--Kenny

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Can 'set ' be elided? When?

Hi Dotan!

On So, 31 Mär 2013, Dotan Cohen wrote:

> On Sun, Mar 31, 2013 at 7:34 PM, Christian Brabandt <cblists@256bit.org> wrote:
> >> Why is "syntax" an option yet "colorscheme" a command?
> >
> > Probably because colorschemes do not change the behaviour of Vim but
> > rather change its appearance.
> >
> > But who really knows the reasoning why some commands are not options?
> >
>
> Thank you. I did not realize that syntax actually changes the
> behaviour of VIM. I suppose that it could change things like
> indentation.

Yes, loading syntax files could e.g. change the 'isk' setting so syntax
highlighting works better, but this might have other side effects. So in
fact setting syntax (and therefore loading a special syntax file) might
in fact change the behaviour of Vim.

Actually I think the syntax option is a bad example here, since
:set syntax?
might not always give the exact syntax setting that is used.

regards,
Christian
--

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Can 'set ' be elided? When?

On Sun, Mar 31, 2013 at 7:34 PM, Christian Brabandt <cblists@256bit.org> wrote:
>> Why is "syntax" an option yet "colorscheme" a command?
>
> Probably because colorschemes do not change the behaviour of Vim but
> rather change its appearance.
>
> But who really knows the reasoning why some commands are not options?
>

Thank you. I did not realize that syntax actually changes the
behaviour of VIM. I suppose that it could change things like
indentation.


--
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Can 'set ' be elided? When?

Hi Dotan!

On So, 31 Mär 2013, Dotan Cohen wrote:

> I notice that the following doesn't work:
> :syntax php
>
> However the following does work:
> :colorscheme desert
>
> Why is "syntax" an option yet "colorscheme" a command?

Probably because colorschemes do not change the behaviour of Vim but
rather change its appearance.

But who really knows the reasoning why some commands are not options?

regards,
Christian

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Can 'set ' be elided? When?

On Sat, Mar 23, 2013 at 12:58 AM, Paul Isambert <zappathustra@free.fr> wrote:
>> I notice that some settings use the format ':set name=value' and other
>> use ':name value'. For instance:
>> :set syntax=php
>> :syntax off
>
> Note that ":syntax php" doesn't work.
>
>> Can the string 'set ' always be safely elided?
>
> No.
>
>> If not, then what are the guidelines?
>
> As far as I can tell, there aren't any. Some commands have the same name as
> options (e.g. :filetype and 'filetype', :confirm and 'confirm'), but they don't
> do the same things.
>
> Best,
> Paul
>

I notice that the following doesn't work:
:syntax php

However the following does work:
:colorscheme desert

Why is "syntax" an option yet "colorscheme" a command?



--
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Get netrw to ignore executability of file

Hi Tony!

On Sa, 30 Mär 2013, Tony Mechelynck wrote:

> On 30/03/13 20:46, AndyHancock wrote:
> >For netrw 140, one of the differences between the Windows gvim and
> >Cygwin/X11 gvim is that the Cygwin/X11 version will show the
> >executable files with "highlight netrwExe" which is linked to
> >"highlight Preproc". This does not happen with the Windows version,
> >even netrwExe is also linked to PreProc. I assume that it is because
> >the executability of each file is not conveyed to gvim and/or netrw,
> >or because it is not *properly* conveyed.
> >
> >I actually prefer the behaviour without special highlighting of
> >executable files because in Windows, files seem to be marked
> >executable in a random manner (at least as viewed using "ls -l" in
> >Cygwin's bash). So the highlighting is random and is the source of
> >cognitive noise. Furthermore, even if that was not the case, I rarely
> >make use of the information about a file's executability. True binary
> >executables are always collected away in their own directories and are
> >rarely mixed with other file types, so there is no need to highlight
> >them and distinguigh them from brethren files. As well, for my
> >purposes, the notion of executables have blurred e.g. vim files,
> >matlab files, bash files, perl file, etc.. Particularly in Windows,
> >it doesn't matter much whether one launches an app by double-clicking
> >on the binary executable or by double-clicking a file with an
> >extension that invokes a particular app.
> >
> >I tried to get rid of netrwExe highlighting by linking it to Normal.
> >This was OK, but the asterisk that immediately follows the filename to
> >indicate executability still there, and is definitely not Normal. It
> >is still loudly pronouncing itself in netrwExe highlighting. Is there
> >a way to get rid of the distinction of executability all together?
> >
>
> FAT filesystems have no built-in executable bit. I'm less sure about
> NTFS filesystems. OTOH POSIX-compatible filesystems typically have

On windows, there is no executable bit and is actually not needed,
because only certain file types are executable.
So in principle is should be possible to simply highlight .exe .bat .cmd
.com files as executable on Windows.

regards,
Christian
--
Frage an Radio Eriwan: "Stimmt es, daß in den USA jeder ein Auto hat?"
Antwort: "Im Prinzip ja, aber bei uns hat dafür jeder einen Parkplatz."

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: "hi netrwCopyTgt" doesn't bold netrw's target directory for copy

On 31/03/13 09:16, AndyHancock wrote:
> On Mar 30, 7:20 pm, Charles E Campbell wrote:
>> AndyHancock wrote:
>>> I am trying to get my netrw marked files to show up as yellow, and
>>> the target directory for copying marked files to show up as bolded
>>> cyan. In my vimrc, I have:
>>>
>>> syntax on
>>> color mine
>>>
>>> I deliberately stuck "syntax on" as a precaution because the
>>> highlight groups netrwMarkFile and netrwCopyTgt don't exist without
>>> "syntax on". Without it, the "color mine" seems to have no effect
>>> in netrw.
>>> [snip]
>>> The Cyan for Directory works. The yellow for netrwMarkFile works.
>>> But the netrwCopyTgt doesn't work (neither bold nor yellow)
>>
>> The netrwCopyTgt syntax is transparent. You need to get rid of that
>> modifier. So, put in your .vim/after/syntax/netrw.vim file:
>>
>> syn clear netrwCopyTgt
>> syn match netrwCopyTgt "Copy/Move Tgt:" contained skipwhite
>> nextgroup=netrwList
>> hi link netrwCopyTgt Unique
>>
>> where Unique is whatever color you want (or, instead of hi link ...,
>> use hi and fg= bg= etc specifications).
>
> Hi Charles,
>
> I put the lines into cygwin's /usr/share/vim/vimfiles/after/syntax/
> netrw.vim. In place of "hi link netrwCopyTgt Unique", I put
>
> hi netrwCopyTgt term=bold cterm=11 gui=bold guifg=yellow
>
> When I editted a directory path and netrw is invoked, I pressed "a" to
> cycle through the hiding list modes until nothing was hidden. I got
> the error:
>
> Error detected while processing
> /usr/share/vim/vimfiles/after/syntax/netrw.vim:
> line 5:
> E492: Not an editor command: nextgroup=netrwList
>
> I then commented that line out. The effect of netrw's "mt" was to
> highlight the words "Copy/Move Tgt:" in the header. The target file
> itself was not highlighted. Is that what the commented line should
> have done?
>

There was a spurious linebreak in the email. "nextgroup=netrwList"
should either have been at the end of the previous :syn match line, or
else have a backslash at the start to mark it as a continuation line.

Best regards,
Tony.
--
... the privileged being which we call human is distinguished from
other animals only by certain double-edged manifestations which in
charity we can only call "inhuman."
-- R. A. Lafferty

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: "hi netrwCopyTgt" doesn't bold netrw's target directory for copy

On Mar 30, 7:20 pm, Charles E Campbell wrote:
>AndyHancock wrote:
>> I am trying to get my netrw marked files to show up as yellow, and
>> the target directory for copying marked files to show up as bolded
>> cyan. In my vimrc, I have:
>>
>> syntax on
>> color mine
>>
>> I deliberately stuck "syntax on" as a precaution because the
>> highlight groups netrwMarkFile and netrwCopyTgt don't exist without
>> "syntax on". Without it, the "color mine" seems to have no effect
>> in netrw.
>> [snip]
>> The Cyan for Directory works. The yellow for netrwMarkFile works.
>> But the netrwCopyTgt doesn't work (neither bold nor yellow)
>
> The netrwCopyTgt syntax is transparent. You need to get rid of that
> modifier. So, put in your .vim/after/syntax/netrw.vim file:
>
> syn clear netrwCopyTgt
> syn match netrwCopyTgt "Copy/Move Tgt:" contained skipwhite
> nextgroup=netrwList
> hi link netrwCopyTgt Unique
>
> where Unique is whatever color you want (or, instead of hi link ...,
> use hi and fg= bg= etc specifications).

Hi Charles,

I put the lines into cygwin's /usr/share/vim/vimfiles/after/syntax/
netrw.vim. In place of "hi link netrwCopyTgt Unique", I put

hi netrwCopyTgt term=bold cterm=11 gui=bold guifg=yellow

When I editted a directory path and netrw is invoked, I pressed "a" to
cycle through the hiding list modes until nothing was hidden. I got
the error:

Error detected while processing
/usr/share/vim/vimfiles/after/syntax/netrw.vim:
line 5:
E492: Not an editor command: nextgroup=netrwList

I then commented that line out. The effect of netrw's "mt" was to
highlight the words "Copy/Move Tgt:" in the header. The target file
itself was not highlighted. Is that what the commented line should
have done?

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Get netrw to ignore executability of file

On Mar 30, 7:06 pm, Charles E Campbell <drc...@campbellfamily.biz>
wrote:
> AndyHancock wrote:
>
> > I tried to get rid of netrwExe highlighting by linking it to Normal.
> > This was OK, but the asterisk that immediately follows the filename to
> > indicate executability still there, and is definitely not Normal.  It
> > is still loudly pronouncing itself in netrwExe highlighting.  Is there
> > a way to get rid of the distinction of executability all together?
>
> syn clear netrwExe
> syn clear netrwClassify
>
> Place in your (home)/.vim/after/syntax/netrw.vim file  (or use vimfiles
> instead of .vim, whatever).

Thanks Charles. It works like charm.

I realize that shenanigans happen to convey the executability of files
to netrw. I just didn't want to wrestle with how cygwin does the
translation.

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Get netrw to ignore executability of file

On Mar 30, 5:56 pm, Tony Mechelynck wrote:
> On 30/03/13 20:46, AndyHancock wrote: FAT filesystems have no
> built-in executable bit. I'm less sure about NTFS filesystems. OTOH
> POSIX-compatible filesystems typically have "rwxrwxrwx" permissions,
> and IIRC Cygwin tries to simulate that for your Windows files. When
> I was on Windows (with Cygwin installed), ISTR that everything had
> the executable bits set from the Cygwin POV. Windows executables are
> of course distinguished by their extension (.EXE etc. for binaries,
> .BAT etc. for shell scripts) but you may also have bash scripts with
> either .sh or no extension at all, for use with Cygwin bash.
>
> You may try running chmod a+x * to mark everything as "executable",
> which will make the *distinction* disappear (everything will be the
> same again). GNU chmod has a -R (recursive) option but I'm not sure
> how to avoid looping forever on Cygwin's representation of your
> Windows filesystem. Maybe reading "man chmod" in a Cygwin bash shell
> may help you.

Thanks, Tony. I'm on Windows 7, so it's NTFS.

I just double checked, and whether a file is marked executable
according to "ls -l" in cygwin's bash seems to vary, though I'm not
sure how cygwin decides. "chmod -R" will fix it for the moment, but
the directory subtree that I intend to use netrw on typically varies
alot, so it's be great if I there is a way for netrw to ignore
executability.

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: execute command with "

On 15:27 Sat 30 Mar , Canis Major wrote:
> Hello,
>
> I have problem to execute the following command
> execute ":s/foo/\<C-r>\"/g\<Left>\<Left>"
> The result is not the value of unnamed register. How to perform the <C-
> r>" key sequence by execute command?
>
> --
> --
> 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
>
> ---
> You received this message because you are subscribed to the Google Groups "vim_use" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

Hi,

You can use CTRL-r" in the command line in the same way as in the insert mode. Otherwise, you can:

:s/foo/\=@"/g

See ':help sub-replace-\='.

Best,
Marcin

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Setting the TEXINPUTS and BIBINPUTS varibles for latex inside vim/gVim

Christoph Wiesmeyr wrote:
> Thanks for the answer, but unfortunately this does not solve the problem for me. After adding these environment variables to my vimrc they are accessible within gvim but when I start compiling they don't seem to be in the scope anymore. In fact more than that, when the variables are set on vim startup compilation does not even work in the console based vim, which used to work.
>
Setting environment variables from within an app affects that app and
its child apps. So, are you compiling from within vim? ie. do you
leave vim and then try latex, bibtex, etc?

Another way to say this: changing an environment variable from within
vim will not affect vim's parent environment. That's not a vim thing,
that's a generic feature.

Regards,
C Campbell

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: "hi netrwCopyTgt" doesn't bold netrw's target directory for copy

AndyHancock wrote:
> I am trying to get my netrw marked files to show up as yellow, and the
> target directory for copying marked files to show up as bolded cyan.
> In my vimrc, I have:
>
> syntax on
> color mine
>
> I deliberately stuck "syntax on" as a precaution because the highlight
> groups netrwMarkFile and netrwCopyTgt don't exist without "syntax
> on". Without it, the "color mine" seems to have no effect in netrw.
> [snip]
> The Cyan for Directory works. The yellow for netrwMarkFile works.
> But the netrwCopyTgt doesn't work (neither bold nor yellow)
>
[snip]

The netrwCopyTgt syntax is transparent. You need to get rid of that
modifier. So, put in your .vim/after/syntax/netrw.vim file:

syn clear netrwCopyTgt
syn match netrwCopyTgt "Copy/Move Tgt:" contained skipwhite
nextgroup=netrwList
hi link netrwCopyTgt Unique

where Unique is whatever color you want (or, instead of hi link ..., use
hi and fg= bg= etc specifications).

C Campbell


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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Setting the TEXINPUTS and BIBINPUTS varibles for latex inside vim/gVim

[This may appear twice. I sent the original almost 6 hours ago and
it still hasn't appeared on the list while messages from other
posters have, so I'm assuming it got lost somewhere.]

On 2013-03-22, Christoph Wiesmeyr wrote:
> Dear all,
>
> I have been trying to set the TEXINPUTS variable for my latex to
> have it search for packages in paths, where I have some custom
> built macros and styles. I have therefore added this line in my
> vimrc:
>
> let g:Tex_TEXINPUTS = '/home/christoph/Dokumente/Dropbox/NuHAG/latex/**,./**'
>
> According to what I found in http://tinyurl.com/d66jz45 , this
> should do the job.
>
> It works in console based vim, as it seems to inherit the
> environment varibles from the bash, where I have them set in
> bashrc. However, when I use gVim this is not the case. Therefore I
> have two questions:
>
> - is there anything wrong with how I set the environment variable
> above?
> - can I somehow also set environment variables in the internal
> gVim shell, that is invoked on compilation?

The setting of the $TEXINPUTS variable and the g:Tex_TEXINPUTS
variable is covered in

:help custom-packages
:help Tex_TEXINPUTS

Something that doesn't seem to be covered very well by the LaTeX
Suite documentation is where to set the g:Tex_TEXINPUTS variable.
It is set by the package in the ftplugin/latex-suite/texrc file.
The top of that file says:

NOTE: Do NOT be edit this file directly:
this file will be over-written each time you install a new
copy of latex-suite.

You can do one of the following:
1. Copy this file into $VIMFILES/ftplugin/tex/texrc
and edit the values in that file.
$VIMFILES is ~/.vim for UNIX systems and ~/vimfiles for
WINDOWS systems.

2. Just set values of each setting individually in your
$VIMFILES/ftplugin/tex.vim file. (See above for what
$VIMFILES is). You will need to use :let instead of
:TexLet in this case.

So, the proper place to set g:Tex_TEXINPUTS is _not_ in your
~/.vimrc file but in either of the two files mentioned above.

Regards,
Gary

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Get netrw to ignore executability of file

AndyHancock wrote:
>
> I tried to get rid of netrwExe highlighting by linking it to Normal.
> This was OK, but the asterisk that immediately follows the filename to
> indicate executability still there, and is definitely not Normal. It
> is still loudly pronouncing itself in netrwExe highlighting. Is there
> a way to get rid of the distinction of executability all together?
>
syn clear netrwExe
syn clear netrwClassify

Place in your (home)/.vim/after/syntax/netrw.vim file (or use vimfiles
instead of .vim, whatever).

C Campbell

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Get netrw to ignore executability of file

AndyHancock wrote:
> For netrw 140, one of the differences between the Windows gvim and
> Cygwin/X11 gvim is that the Cygwin/X11 version will show the
> executable files with "highlight netrwExe" which is linked to
> "highlight Preproc". This does not happen with the Windows version,
> even netrwExe is also linked to PreProc. I assume that it is because
> the executability of each file is not conveyed to gvim and/or netrw,
> or because it is not *properly* conveyed.
>
May I suggest that you look into

man getfacl
man setfacl

The executability of the files is controlled by the executable bits AND
by ACLs.

Try ls -lsa (using cygwin)

and I suspect that you'll find a lot of permission strings with a
trailing "+". That means that an acl is in control and apparently
flagging the file as an executable.

Regards,
C Campbell

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

execute command with "

Hello,

I have problem to execute the following command
execute ":s/foo/\<C-r>\"/g\<Left>\<Left>"
The result is not the value of unnamed register. How to perform the <C-
r>" key sequence by execute command?

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Get netrw to ignore executability of file

On 30/03/13 20:46, AndyHancock wrote:
> For netrw 140, one of the differences between the Windows gvim and
> Cygwin/X11 gvim is that the Cygwin/X11 version will show the
> executable files with "highlight netrwExe" which is linked to
> "highlight Preproc". This does not happen with the Windows version,
> even netrwExe is also linked to PreProc. I assume that it is because
> the executability of each file is not conveyed to gvim and/or netrw,
> or because it is not *properly* conveyed.
>
> I actually prefer the behaviour without special highlighting of
> executable files because in Windows, files seem to be marked
> executable in a random manner (at least as viewed using "ls -l" in
> Cygwin's bash). So the highlighting is random and is the source of
> cognitive noise. Furthermore, even if that was not the case, I rarely
> make use of the information about a file's executability. True binary
> executables are always collected away in their own directories and are
> rarely mixed with other file types, so there is no need to highlight
> them and distinguigh them from brethren files. As well, for my
> purposes, the notion of executables have blurred e.g. vim files,
> matlab files, bash files, perl file, etc.. Particularly in Windows,
> it doesn't matter much whether one launches an app by double-clicking
> on the binary executable or by double-clicking a file with an
> extension that invokes a particular app.
>
> I tried to get rid of netrwExe highlighting by linking it to Normal.
> This was OK, but the asterisk that immediately follows the filename to
> indicate executability still there, and is definitely not Normal. It
> is still loudly pronouncing itself in netrwExe highlighting. Is there
> a way to get rid of the distinction of executability all together?
>

FAT filesystems have no built-in executable bit. I'm less sure about
NTFS filesystems. OTOH POSIX-compatible filesystems typically have
"rwxrwxrwx" permissions, and IIRC Cygwin tries to simulate that for your
Windows files. When I was on Windows (with Cygwin installed), ISTR that
everything had the executable bits set from the Cygwin POV. Windows
executables are of course distinguished by their extension (.EXE etc.
for binaries, .BAT etc. for shell scripts) but you may also have bash
scripts with either .sh or no extension at all, for use with Cygwin bash.

You may try running chmod a+x * to mark everything as "executable",
which will make the *distinction* disappear (everything will be the same
again). GNU chmod has a -R (recursive) option but I'm not sure how to
avoid looping forever on Cygwin's representation of your Windows
filesystem. Maybe reading "man chmod" in a Cygwin bash shell may help you.


Best regards,
Tony.
--
Do not read this fortune under penalty of law.
Violators will be prosecuted.
(Penal Code sec. 2.3.2 (II.a.))

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Get netrw to ignore executability of file

For netrw 140, one of the differences between the Windows gvim and
Cygwin/X11 gvim is that the Cygwin/X11 version will show the
executable files with "highlight netrwExe" which is linked to
"highlight Preproc". This does not happen with the Windows version,
even netrwExe is also linked to PreProc. I assume that it is because
the executability of each file is not conveyed to gvim and/or netrw,
or because it is not *properly* conveyed.

I actually prefer the behaviour without special highlighting of
executable files because in Windows, files seem to be marked
executable in a random manner (at least as viewed using "ls -l" in
Cygwin's bash). So the highlighting is random and is the source of
cognitive noise. Furthermore, even if that was not the case, I rarely
make use of the information about a file's executability. True binary
executables are always collected away in their own directories and are
rarely mixed with other file types, so there is no need to highlight
them and distinguigh them from brethren files. As well, for my
purposes, the notion of executables have blurred e.g. vim files,
matlab files, bash files, perl file, etc.. Particularly in Windows,
it doesn't matter much whether one launches an app by double-clicking
on the binary executable or by double-clicking a file with an
extension that invokes a particular app.

I tried to get rid of netrwExe highlighting by linking it to Normal.
This was OK, but the asterisk that immediately follows the filename to
indicate executability still there, and is definitely not Normal. It
is still loudly pronouncing itself in netrwExe highlighting. Is there
a way to get rid of the distinction of executability all together?

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: "hi netrwCopyTgt" doesn't bold netrw's target directory for copy

In case it wasn't obvious (and it might not be), the following post
was with regards gvim, not vim. The same behaviour is observed on the
Windows binary as well as the cygwin/X-windows version. The netrw
version is 140. I add gvim :ver information at the bottom.

---------- Original message ----------
Date: Mar 30, 4:33 am

I am trying to get my netrw marked files to show up as yellow, and the
target directory for copying marked files to show up as bolded cyan.
In my vimrc, I have:

syntax on
color mine

I deliberately stuck "syntax on" as a precaution because the highlight
groups netrwMarkFile and netrwCopyTgt don't exist without "syntax
on". Without it, the "color mine" seems to have no effect in netrw.

I issued :highlight and extracted the following relevant lines. I
also indicate the lines that result from my color scheme.

" Default:
"----------
Directory term=bold ctermfg=11 guifg=Cyan

netrwDir links to Directory

" My color scheme:
" The #80FFFF is very similar to Cyan if not the same
"-----------------------------------------------------
Identifier term=underline cterm=bold ctermfg=7 guifg=#80FFFF

netrwCopyTgt term=bold ctermfg=11 gui=bold guifg=yellow
" This is "cleared" by default.
" Use yellow as a test.
" Will change to Cyan once I get bold working.

netrwMarkFile term=underline cterm=bold ctermfg=7 guifg=yellow

I included Identifier because the default is for netrwMarkFile to link
to Identifier.

I do not have a gvimrc.

The Cyan for Directory works. The yellow for netrwMarkFile works.
But the netrwCopyTgt doesn't work (neither bold nor yellow)

The scheme doesn't *appear* to be all that complicated, but I'm not
all that familiar with the inner workings of syntax and color
schemes. Can anyone suggest a way to make it work, or identify what
is preventing it from working?

---------- End original message ----------

The :ver info is:

VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Oct 27 2010 17:59:02)
MS-Windows 32-bit GUI version with OLE support
Included patches: 1-46
Compiled by Bram@KIBAALE
Big version with GUI. Features included (+) or not (-):
+arabic +autocmd +balloon_eval +browse ++builtin_terms +byte_offset
+cindent
+clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info
+comments
+conceal +cryptv +cscope +cursorbind +cursorshape +dialog_con_gui
+diff
+digraphs -dnd -ebcdic +emacs_tags +eval +ex_extra +extra_search
+farsi
+file_in_path +find_in_path +float +folding -footer +gettext/dyn -
hangul_input
+iconv/dyn +insert_expand +jumplist +keymap +langmap +libcall
+linebreak
+lispindent +listcmds +localmap -lua +menu +mksession +modify_fname
+mouse
+mouseshape +multi_byte_ime/dyn +multi_lang -mzscheme +netbeans_intg
+ole
-osfiletype +path_extra +perl/dyn +persistent_undo -postscript
+printer
-profile +python/dyn +python3/dyn +quickfix +reltime +rightleft +ruby/
dyn
+scrollbind +signs +smartindent -sniff +startuptime +statusline -
sun_workshop
+syntax +tag_binary +tag_old_static -tag_any_white +tcl/dyn -tgetent
-termresponse +textobjects +title +toolbar +user_commands +vertsplit
+virtualedit +visual +visualextra +viminfo +vreplace +wildignore
+wildmenu
+windows +writebackup -xfontset -xim -xterm_save +xpm_w32
system vimrc file: "$VIM\vimrc"
user vimrc file: "$HOME\_vimrc"
2nd user vimrc file: "$VIM\_vimrc"
user exrc file: "$HOME\_exrc"
2nd user exrc file: "$VIM\_exrc"
system gvimrc file: "$VIM\gvimrc"
user gvimrc file: "$HOME\_gvimrc"
2nd user gvimrc file: "$VIM\_gvimrc"
system menu file: "$VIMRUNTIME\menu.vim"
Compilation: cl -c /W3 /nologo -I. -Iproto -DHAVE_PATHDEF -DWIN32 -
DFEAT_CSCOPE -DFEAT_NETBEANS_INTG -DFEAT_XPM_W32 -DWINVER=0x0400 -
D_WIN32_WINNT=0x0400 /Fo.\ObjGOLYHTR/ /Ox /GL -DNDEBUG /Zl /MT -
DFEAT_OLE -DFEAT_MBYTE_IME -DDYNAMIC_IME -DFEAT_GUI_W32 -
DDYNAMIC_ICONV -DDYNAMIC_GETTEXT -DFEAT_TCL -DDYNAMIC_TCL -
DDYNAMIC_TCL_DLL=\"tcl83.dll\" -DDYNAMIC_TCL_VER=\"8.3\" -DFEAT_PYTHON
-DDYNAMIC_PYTHON -DDYNAMIC_PYTHON_DLL=\"python27.dll\" -DFEAT_PYTHON3 -
DDYNAMIC_PYTHON3 -DDYNAMIC_PYTHON3_DLL=\"python31.dll\" -DFEAT_PERL -
DDYNAMIC_PERL -DDYNAMIC_PERL_DLL=\"perl512.dll\" -DFEAT_RUBY -
DDYNAMIC_RUBY -DDYNAMIC_RUBY_VER=191 -DDYNAMIC_RUBY_DLL=\"msvcrt-
ruby191.dll\" -DFEAT_BIG /Fd.\ObjGOLYHTR/ /Zi
Linking: link /RELEASE /nologo /subsystem:windows /LTCG:STATUS
oldnames.lib kernel32.lib advapi32.lib shell32.lib gdi32.lib
comdlg32.lib ole32.lib uuid.lib /machine:i386 /nodefaultlib gdi32.lib
version.lib winspool.lib comctl32.lib advapi32.lib shell32.lib /
machine:i386 /nodefaultlib libcmt.lib oleaut32.lib user32.lib /
nodefaultlib:python27.lib /nodefaultlib:python31.lib e:\tcl\lib
\tclstub83.lib WSock32.lib e:\xpm\lib\libXpm.lib /PDB:gvim.pdb -debug

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Setting the TEXINPUTS and BIBINPUTS varibles for latex inside vim/gVim

On 2013-03-22, Christoph Wiesmeyr wrote:
> Dear all,
>
> I have been trying to set the TEXINPUTS variable for my latex to
> have it search for packages in paths, where I have some custom
> built macros and styles. I have therefore added this line in my
> vimrc:
>
> let g:Tex_TEXINPUTS = '/home/christoph/Dokumente/Dropbox/NuHAG/latex/**,./**'
>
> According to what I found in http://tinyurl.com/d66jz45 , this
> should do the job.
>
> It works in console based vim, as it seems to inherit the
> environment varibles from the bash, where I have them set in
> bashrc. However, when I use gVim this is not the case. Therefore I
> have two questions:
>
> - is there anything wrong with how I set the environment variable
> above?
> - can I somehow also set environment variables in the internal
> gVim shell, that is invoked on compilation?

The setting of the $TEXINPUTS variable and the g:Tex_TEXINPUTS
variable is covered in

:help custom-packages
:help Tex_TEXINPUTS

Something that doesn't seem to be covered very well by the LaTeX
Suite documentation is where to set the g:Tex_TEXINPUTS variable.
It is set by the package in the ftplugin/latex-suite/texrc file.
The top of that file says:

NOTE: Do NOT be edit this file directly:
this file will be over-written each time you install a new
copy of latex-suite.

You can do one of the following:
1. Copy this file into $VIMFILES/ftplugin/tex/texrc
and edit the values in that file.
$VIMFILES is ~/.vim for UNIX systems and ~/vimfiles for
WINDOWS systems.

2. Just set values of each setting individually in your
$VIMFILES/ftplugin/tex.vim file. (See above for what
$VIMFILES is). You will need to use :let instead of
:TexLet in this case.

So, the proper place to set g:Tex_TEXINPUTS is _not_ in your
~/.vimrc file but in either of the two files mentioned above.

Regards,
Gary

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: expand('%:p') doesn't work properly when opening a new file in a non-existing directory?

On 30/03/13 07:35, Hong Xu wrote:
[...]
> Hi Tony,
>
> Thanks for your reply.
>
> I have noticed that I can not write to disk if I create a new file in a
> non-existing directory; what I am concerning is the unexpected behavior
> of `expand('%:p')`. I am currently encountering an issue in my plugin: I
> call `expand('%:p')` to obtain the full path, but in the given case
> above, I would get a truncated path. So I think this behavior should not
> be expected. Do you think so?
>
> Thanks,
> Hong
>

I think that you cannot get the full path if there is no disk path.
Maybe you ought to get '' rather than 'a/a.b'. Or maybe it is intended
(perhaps vi-compatible) behaviour, and you can test the value (on Unix:
either empty, or doesn't start with a slash; on Windows: either empty,
or the second character is not a colon) to determine that you didn't get
a real path. (Empty is for a [No Name] buffer.)

" untested
let filepath = expand('%:p')
if ((has('unix') && (filepath =~ '/.*')) || (!has('unix') && (filepath
=~ '.:.*'))
" we have a real path
else
" we don't
endif

Now that I think of it, a better test might be filereadable() or
filewritable(). Or :w in a try-catch block.

See
:help filereadable()
:help filewritable()
:help :try

Best regards,
Tony.
--
INSPECTOR END OF FILM: Move along. There's nothing to see! Keep moving!
[Suddenly he notices the cameras.]
INSPECTOR END OF FILM: (to Camera) All right, put that away sonny.
[He walks over to it and puts his hand over the lens.]
"Monty Python and the Holy Grail" PYTHON (MONTY)
PICTURES LTD

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: optimal vimrc and plugins for fortran, latex, c and html

Hi,

You can checkout my latex plugin, which is a very good vim-latex
alternative:
http://atp-vim.sf.net

It works on Linux, Mac and it is about to start working on Windows as
well (if you are on Windows use the git version)

Best,
Marcin

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

optimal vimrc and plugins for fortran, latex, c and html

Dear Friends,
I work on (g)vim mainly for writing codes in fortran, C and Latex (and my webpage in html).
I am using fortran code complete (http://www.vim.org/scripts/script.php?script_id=2487) and vim-latex(http://vim-latex.sourceforge.net/).
I know about omni but not yet managed to use it for autocomplete my codes.
I am looking for some suggestions on plugins and an optimal vimrc for better productivity.
My present vimrc is:

set autoindent
set smartindent
set incsearch
set ignorecase
set smartcase
set novisualbell
set paste
set ruler
"set expandtab
"set smarttab
"set shiftwidth=3
"set softtabstop=3

syntax on
colorscheme MySlate
"set mouse=a "enable mouse
set nu "show line number
"set cul "highlight current line

if version >= 700
set spell spl=en_us
set spell
nmap <F12> :set nospell!
endif

" Fortran stuff
:let fortran_do_enddo=1
:let fortran_more_precise=1
:let fortran_free_source=1
:let fortran_have_tabs=1
autocmd BufNewFile *.f90 call New_Fortran_File()
fun! New_Fortran_File()
:0put='!This is file : ' . expand('%')
:put='Implicit None'
exe ":3"
endf
filetype on
filetype plugin on
filetype indent on

set sw=2
set iskeyword+=:
"latex only
let g:tex_flavor='latex'
" Always jump to last edited line
if has("autocmd")
au BufReadPost * if line("'\"") > 0 && line("'\"") <= line("$")
\| exe "normal! g'\"" | endif
endif

:nnoremap <Leader>lw :up!<cr>:call Tex_RunLaTeX()<cr>
":echo 'Current time is ' . strftime('%c')<CR>
autocmd FileType html set omnifunc=htmlcomplete#CompleteTags

I am using vim 7.3.712 in fedora18

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Setting the TEXINPUTS and BIBINPUTS varibles for latex inside vim/gVim

Thanks for the answer, but unfortunately this does not solve the problem for me. After adding these environment variables to my vimrc they are accessible within gvim but when I start compiling they don't seem to be in the scope anymore. In fact more than that, when the variables are set on vim startup compilation does not even work in the console based vim, which used to work.



Best,
Christoph

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

"hi netrwCopyTgt" doesn't bold netrw's target directory for copy

I am trying to get my netrw marked files to show up as yellow, and the
target directory for copying marked files to show up as bolded cyan.
In my vimrc, I have:

syntax on
color mine

I deliberately stuck "syntax on" as a precaution because the highlight
groups netrwMarkFile and netrwCopyTgt don't exist without "syntax
on". Without it, the "color mine" seems to have no effect in netrw.

I issued :highlight and extracted the following relevant lines. I
also indicate the lines that result from my color scheme.

" Default:
"----------
Directory term=bold ctermfg=11 guifg=Cyan

netrwDir links to Directory


" My color scheme:
" The #80FFFF is very similar to Cyan if not the same
"-----------------------------------------------------
Identifier term=underline cterm=bold ctermfg=7 guifg=#80FFFF

netrwCopyTgt term=bold ctermfg=11 gui=bold guifg=yellow
" This is "cleared" by default.
" Use yellow as a test.
" Will change to Cyan once I get bold working.

netrwMarkFile term=underline cterm=bold ctermfg=7 guifg=yellow

I included Identifier because the default is for netrwMarkFile to link
to Identifier.

I do not have a gvimrc.

The Cyan for Directory works. The yellow for netrwMarkFile works.
But the netrwCopyTgt doesn't work (neither bold nor yellow)

The scheme doesn't *appear* to be all that complicated, but I'm not
all that familiar with the inner workings of syntax and color
schemes. Can anyone suggest a way to make it work, or identify what
is preventing it from working?

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: expand('%:p') doesn't work properly when opening a new file in a non-existing directory?

On Friday, March 29, 2013 9:14:17 PM UTC-7, Tony Mechelynck wrote:

>> On 30/03/13 03:50, hong@topbug.net wrote:
>>
>>> Hi All,
>>
>>>
>>
>>> According to the document of expand, "expand('%:p')" should be able to give full path of current buffer. This works properly when use vim to open an existing file or create a new file in an existing directory. But If I execute this command:
>>
>>>
>>
>>> gvim a/a.c
>>
>>>
>>
>>> where a is a non-existing directory. Then I run ":echo expand('%:p')", it gives 'a/a.c', which is not what I expected. Other modifiers just work as expected except '%:r'.
>>
>>>
>>
>>> Anyone have any ideas?
>>
>>>
>>
>>> Thanks!
>>
>>> Hong
>>
>>>
>>
>>
>>
>> In this case, trying to write the file will answer "a/a.c: E212 Cannot
>>
>> open file for writing", showing that there is *no* path to the file. But
>>
>> after creating a subdirectory ./a in the current directory,
>>
>> expand('%:p') gets a sensible value, and the write (if attempted) succeeds.
>>
>>
>>
>> On Unix you might try
>>
>> :exe '!mkdir -pv' expand('%:h')
>>
>> :w
>>
>> if you really want to save the file under that name. (Of course it will
>>
>> fail if you don't have the necessary directory-creation permissions.)
>>
>>

Hi Tony,

Thanks for your reply.

I have noticed that I can not write to disk if I create a new file in a
non-existing directory; what I am concerning is the unexpected behavior
of `expand('%:p')`. I am currently encountering an issue in my plugin: I
call `expand('%:p')` to obtain the full path, but in the given case
above, I would get a truncated path. So I think this behavior should not
be expected. Do you think so?

Thanks,
Hong

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: expand('%:p') doesn't work properly when opening a new file in a non-existing directory?

On 30/03/13 03:50, hong@topbug.net wrote:
> Hi All,
>
> According to the document of expand, "expand('%:p')" should be able to give full path of current buffer. This works properly when use vim to open an existing file or create a new file in an existing directory. But If I execute this command:
>
> gvim a/a.c
>
> where a is a non-existing directory. Then I run ":echo expand('%:p')", it gives 'a/a.c', which is not what I expected. Other modifiers just work as expected except '%:r'.
>
> Anyone have any ideas?
>
> Thanks!
> Hong
>

In this case, trying to write the file will answer "a/a.c: E212 Cannot
open file for writing", showing that there is *no* path to the file. But
after creating a subdirectory ./a in the current directory,
expand('%:p') gets a sensible value, and the write (if attempted) succeeds.

On Unix you might try
:exe '!mkdir -pv' expand('%:h')
:w
if you really want to save the file under that name. (Of course it will
fail if you don't have the necessary directory-creation permissions.)


Best regards,
Tony.
--
Machine-Independent, adj.:
Does not run on any existing machine.

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Register overwritten only when clipboard=unnamed

On Saturday, March 30, 2013 3:03:45 AM UTC+9, Bee wrote:
> On Mar 29, 8:26 am, <kyu...@gmail.com> wrote:
>
> > I am trying to copy & paste a word under the cursor.
>
>
>
> Are you trying to 'exchange' the word under the cursor with the one on
>
> the clipboard?
>
>
>
> What version of vim?
>
> What platform: Windows, Linux, Mac ?
>
>
>
> Bill

I am using gVim 7.3 on Windows x64 platform.

Yes, I want to replace a word at the cursor position by
another word yanked from a different position.

I thought viwp followed by yiw and cursor movement is
a well-known sequence of key strokes for this purpose.
Sorry for my previous imprecise description.

With clipboard=unnamed and guioptions=a set,
I found out there happens a hidden yank between
viw( visually selecting a word ) and
p( overwriting the selected visual block with previously yanked word )
both to the unnamed register and the os clipboard register.

So it looks like my previously yanked word
just disappears from the register.
But I don't think it's a bug or something
because it operates as specified in
guioption=autoselect section of vim documentation.

With guioptions=a unset, this problem has gone.

Thanks
Kyung-Kook



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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

expand('%:p') doesn't work properly when opening a new file in a non-existing directory?

Hi All,

According to the document of expand, "expand('%:p')" should be able to give full path of current buffer. This works properly when use vim to open an existing file or create a new file in an existing directory. But If I execute this command:

gvim a/a.c

where a is a non-existing directory. Then I run ":echo expand('%:p')", it gives 'a/a.c', which is not what I expected. Other modifiers just work as expected except '%:r'.

Anyone have any ideas?

Thanks!
Hong

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: how to undo a register insertion using i_CTRL-R?

On Friday, March 29, 2013 2:15:19 PM UTC-5, Christian Brabandt wrote:
> Hi Ben!
>
>
>
> On Fr, 29 M�r 2013, Ben Fritz wrote:
> > >
>
> > > inoremap <C-R> <C-G>u<C-R>
>
> >
>
> > The problem with this solution, and the reason I don't use it, is because this will make it so you can no longer repeat the change with '.' in normal mode.
>
>
>
> Can you give an example? I just tried repeating using '.' and it seemed
>
> to work ok.
>

I just tested and you're right, it does work OK. But according to :help ins-special-special, it shouldn't work. The help says, "Only the last change can be redone and always behaves like an "i" command."

Consider text "somevar" in register 'a'.

The following keysequence will insert a line with text, "printf(somevar);":
oprintf(<C-R>a);

In this case, I expect the following two mappings to be equivalent:
inoremap <C-R> <Left><Right><C-R>
inoremap <C-R> <C-G>u<C-R>

Without any mapping, pressing 'u' after the insertion will undo the entire insertion. With either mapping, pressing 'u' will only undo inserting "somevar);".

Without any mapping, pressing '.' will repeat the entire insertion. I expect that with either mapping, pressing '.' will only repeat inserting "somevar);" which is not very helpful.

But experimentation shows that the first mapping behaves in the expected unhelpful manner, but the second mapping behaves helpfully, with both "undo" and "repeat" working as intended.

I'm not sure why this works, but I'm glad for it. I'll put that second mapping in my .vimrc now. Can we update the docs?

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Register overwritten only when clipboard=unnamed

Hi kyungk!

Please don't top poste.

On Fr, 29 Mär 2013, kyungk@gmail.com wrote:

> I meant yiw not yip. Sorry for the confusion.

Please, if you want us to help: clearly state, what you did, what you
expected and what did you observe and at last also include the vim
version.

regards,
Christian
--
Verpiß dich kleiner oder deine Zahnbürste greift morgen ins Leere.

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: how to undo a register insertion using i_CTRL-R?

Hi Ben!

On Fr, 29 Mär 2013, Ben Fritz wrote:

> On Friday, March 29, 2013 1:07:56 PM UTC-5, Ben Fritz wrote:
> > On Friday, March 29, 2013 10:55:09 AM UTC-5, Maciej Kalisiak wrote:
> > > I love the ability of inserting a register content, directly in insert mode, using i_CTRL-R. However, this gets me into trouble from time to time.
> > >
> > > For example, I might be on a roll, and without leaving insert mode, I enter a whole paragraph or three, which I want to finish with a contents of a register, which I insert using i_CRTL-R. Except, it turns out I did not get the right register (e.g., there was an intervening cut, so it's no longer "1 but rather "2 or "3). Instead of the expected word or phrase, I accidentally pasted a register which contained massive amount of text. Great, I'll just hit undo key in normal mode to undo it. But hold on! This also undoes the whole paragraph or three I typed in before the mistake.
> > >
> > > Gah, how do I undo just the register insertion?! Or do I have to train myself to leave insert mode before register pastes?
> >
> > This problem, and it's prevention, is closely related to:
> >
> > http://vim.wikia.com/wiki/Recover_from_accidental_Ctrl-U
> >
> > To sum up, you should set up a mapping to break the current undo sequence before triggering the CTRL-R, like:
> >
> > inoremap <C-R> <C-G>u<C-R>
>
> The problem with this solution, and the reason I don't use it, is because this will make it so you can no longer repeat the change with '.' in normal mode.

Can you give an example? I just tried repeating using '.' and it seemed
to work ok.

Mit freundlichen Grüßen
Christian
--
Es ist viel leichter, einen ersten Wunsch zu unterdrücken, als sich
die Wünsche zu erfüllen, die der erste nach sich zieht.
-- François de La Rochefoucauld

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: how to undo a register insertion using i_CTRL-R?

On Friday, March 29, 2013 1:07:56 PM UTC-5, Ben Fritz wrote:
> On Friday, March 29, 2013 10:55:09 AM UTC-5, Maciej Kalisiak wrote:
> > I love the ability of inserting a register content, directly in insert mode, using i_CTRL-R. However, this gets me into trouble from time to time.
> >
> > For example, I might be on a roll, and without leaving insert mode, I enter a whole paragraph or three, which I want to finish with a contents of a register, which I insert using i_CRTL-R. Except, it turns out I did not get the right register (e.g., there was an intervening cut, so it's no longer "1 but rather "2 or "3). Instead of the expected word or phrase, I accidentally pasted a register which contained massive amount of text. Great, I'll just hit undo key in normal mode to undo it. But hold on! This also undoes the whole paragraph or three I typed in before the mistake.
> >
> > Gah, how do I undo just the register insertion?! Or do I have to train myself to leave insert mode before register pastes?
>
> This problem, and it's prevention, is closely related to:
>
> http://vim.wikia.com/wiki/Recover_from_accidental_Ctrl-U
>
> To sum up, you should set up a mapping to break the current undo sequence before triggering the CTRL-R, like:
>
> inoremap <C-R> <C-G>u<C-R>

The problem with this solution, and the reason I don't use it, is because this will make it so you can no longer repeat the change with '.' in normal mode.

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: how to undo a register insertion using i_CTRL-R?

On Friday, March 29, 2013 10:55:09 AM UTC-5, Maciej Kalisiak wrote:
> I love the ability of inserting a register content, directly in insert mode, using i_CTRL-R. However, this gets me into trouble from time to time.
>
> For example, I might be on a roll, and without leaving insert mode, I enter a whole paragraph or three, which I want to finish with a contents of a register, which I insert using i_CRTL-R. Except, it turns out I did not get the right register (e.g., there was an intervening cut, so it's no longer "1 but rather "2 or "3). Instead of the expected word or phrase, I accidentally pasted a register which contained massive amount of text. Great, I'll just hit undo key in normal mode to undo it. But hold on! This also undoes the whole paragraph or three I typed in before the mistake.
>
> Gah, how do I undo just the register insertion?! Or do I have to train myself to leave insert mode before register pastes?

This problem, and it's prevention, is closely related to:

http://vim.wikia.com/wiki/Recover_from_accidental_Ctrl-U

To sum up, you should set up a mapping to break the current undo sequence before triggering the CTRL-R, like:

inoremap <C-R> <C-G>u<C-R>

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Register overwritten only when clipboard=unnamed

On Mar 29, 8:26 am, <kyu...@gmail.com> wrote:
> I am trying to copy & paste a word under the cursor.

Are you trying to 'exchange' the word under the cursor with the one on
the clipboard?

What version of vim?
What platform: Windows, Linux, Mac ?

Bill

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: gVim Hanging/Freezing When Closing

Christian Brabandt wrote:
> Hi Kenny!
>
> On Do, 28 Mär 2013, Kenny Ballou wrote:
>
>> Hey all.
>>
>> I haven't found anything on this, and it might be relatively new (i.e., new
>> kernel/ new vim release); but I am having an issue with gvim hanging when I try
>> to close. That is, the gvim window is clearly _trying_ to close (doesn't
>> redraw, no longer responds to commands, etc.) but can't, stuck waiting for ...
>> something.
>>
>> Behavior or characteristics I have discovered so far.
>>
>> * Happens with a file in buffer or without
>>
>> * Only happens when launched from system launcher (e.g., Alt-F2) or from a
>> shell
>>
>> * Does *not* happen when launched by double-clicking a file in a file manager
>>
>> - Tested with Dolphin and Krusader
>>
>> * Frozen gvim windows have wait channel of `futex_`
>>
>> * Is local to gvim; vim is unaffected
>>
>> I'm not sure what needs to be done to further debug this and/or fix. This
>> happens on both of my main working machines and only started recently (in which
>> time I have had a vim update and a kernel update).
>>
>> Other relevant information (both machines):
>>
>> * KDE 4.10.1 with Openbox (3.5.0-7) window manager
>>
>> * See bugreport.txt
>>
>> Thanks in advance for any help and/or insight anyone can provide.
> You might want to strace it or build gvim with debugging symbols and
> attach gdb to it and print a backtrace.
>
Just in case its a plugin or otherwise doing something when an autocmd
is firing, try
:set verbose=20

just before closing. You should see what commands are being executed
and where gvim is hanging.

Regards,
C Campbell

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Register overwritten only when clipboard=unnamed

I meant yiw not yip. Sorry for the confusion.

 

 

보낸 사람: Bee
보낸 날짜: 2013년 3월 30일 토요일 오전 1:20
받는 사람: vim_use

 

On Mar 29, 8:26 am, <kyu...@gmail.com> wrote:
> I am trying to copy & paste a word under the cursor.
>
> Typing yip in normal mode will yank a word at the current cursor position.

:help ip

       *v_ip* *ip*
ip   "inner paragraph", select [count] paragraphs (see
   |paragraph|).
   Exception: a blank line (only containing white space)
   is also a paragraph boundary.
   When used in Visual mode it is made linewise.

Bill

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.