Monday, February 27, 2012

Re: netrw in try clause


Several users including myself have run into this issue with the Vimwiki plugin.  We have a try-catch stmt wrapped around a command that opens an existing directory, and we are receiving the "Illegal file name" error and a blank page.  I am using Vim 7.3, like others above.  I believe I am using Netrw v143 ... at least, when I type ":help netrw-history", it starts with:

v143: Jun 01, 2011 * |g:netrw_winsize| will accept a negative
    number; the absolute value of it will then
    be used to specify lines/columns instead of
    a percentage.

If I source motz's script (above) *without* the try-stmt, it works, and *with* the try-stmt, nothing happens.

Are we doing something wrong?  
Any help would be appreciated.  

Thank you,
- Stu

p.s. Here's my Vim version info:

VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Jul 31 2011 19:27:29)
Compiled by XXXXXXXXX
Normal version without 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 +diff +digraphs 
-dnd -ebcdic -emacs_tags +eval +ex_extra +extra_search -farsi +file_in_path 
+find_in_path +float +folding -footer +fork() -gettext -hangul_input +iconv 
+insert_expand +jumplist -keymap -langmap +libcall +linebreak +lispindent 
+listcmds +localmap -lua +menu +mksession +modify_fname +mouse -mouseshape 
-mouse_dec -mouse_gpm -mouse_jsbterm -mouse_netterm -mouse_sysmouse 
+mouse_xterm +multi_byte +multi_lang -mzscheme +netbeans_intg -osfiletype 
+path_extra -perl +persistent_undo +postscript +printer -profile -python 
-python3 +quickfix +reltime -rightleft -ruby +scrollbind +signs +smartindent 
-sniff +startuptime +statusline -sun_workshop +syntax +tag_binary 
+tag_old_static -tag_any_white -tcl +terminfo +termresponse +textobjects +title
 -toolbar +user_commands +vertsplit +virtualedit +visual +visualextra +viminfo 
+vreplace +wildignore +wildmenu +windows +writebackup -X11 -xfontset -xim -xsmp
 -xterm_clipboard -xterm_save 
   system vimrc file: "$VIM/vimrc"
     user vimrc file: "$HOME/.vimrc"
      user exrc file: "$HOME/.exrc"
  fall-back for $VIM: "/usr/share/vim"
Compilation: gcc -c -I. -D_FORTIFY_SOURCE=0 -Iproto -DHAVE_CONFIG_H -arch i386 -arch x86_64 -g -Os -pipe
Linking: gcc -arch i386 -arch x86_64 -o vim -lncurses



On Thursday, February 10, 2011 4:41:29 PM UTC-5, Charles Campbell wrote:
Bram Moolenaar wrote:
> Charles Campbell wrote:
>
>    
>> Bram Moolenaar wrote:
>>      
>>> Possibly netrw could add a BufReadCmd that leaves the buffer empty.
>>> That avoids the "illegal file name" error. Just be very careful to only
>>> trigger the auto command for directories, otherwise you disable editing
>>> some type of file.
>>>
>>>
>>>        
>> v141j of netrw now uses a BufReadCmd on files matching, via an autocmd,
>> *[/\\] .  This method does avoid the "... is a directory" message as
>> Bram said it would, and works inside a try-endtry clause, so long as the
>> directory path ends with a "/" or "\".  However, paths to directories
>> that don't end in a "/" or "\" will continue to exhibit the former behavior.
>>
>> v141j of netrw is available at my website as:
>> http://mysite.verizon.net/astronaut/vim/index.html#NETRW .
>>      
> I suppose to fix this properly would require adding some magic to the
> autocmd pattern, e.g.:
>
>         :autocmd BufReadCmd<type==dir>  DoNothing
>
> We already have the<buffer>  item in the pattern, thus we would follow
> that.
>
> Could also do something like this:
>
>         :autocmd BufWritePost<type!=dir>/tmp/* chmod 600
>         :autocmd BufWritePost<type==dir>/tmp/* chmod 700
>
> Perhaps this is too complicated?
>
>    
How about <isdir> and <notisdir> ... otherwise, you're bound to have
someone ask for full-fledged expressions in those <...>s.  But that
would work nicely.  I've been trying  the  *[/\\] along with BufReadCmd
and have been ending up with readonly files.  I haven't really looked
into it in detail yet to see what's doing the readonly bit (I tried  
:set verbose ro?  and didn't get anything).

Regards,
Chip Campbell


On Thursday, February 10, 2011 4:41:29 PM UTC-5, Charles Campbell wrote:
Bram Moolenaar wrote:
> Charles Campbell wrote:
>
>    
>> Bram Moolenaar wrote:
>>      
>>> Possibly netrw could add a BufReadCmd that leaves the buffer empty.
>>> That avoids the "illegal file name" error. Just be very careful to only
>>> trigger the auto command for directories, otherwise you disable editing
>>> some type of file.
>>>
>>>
>>>        
>> v141j of netrw now uses a BufReadCmd on files matching, via an autocmd,
>> *[/\\] .  This method does avoid the "... is a directory" message as
>> Bram said it would, and works inside a try-endtry clause, so long as the
>> directory path ends with a "/" or "\".  However, paths to directories
>> that don't end in a "/" or "\" will continue to exhibit the former behavior.
>>
>> v141j of netrw is available at my website as:
>> http://mysite.verizon.net/astronaut/vim/index.html#NETRW .
>>      
> I suppose to fix this properly would require adding some magic to the
> autocmd pattern, e.g.:
>
>         :autocmd BufReadCmd<type==dir>  DoNothing
>
> We already have the<buffer>  item in the pattern, thus we would follow
> that.
>
> Could also do something like this:
>
>         :autocmd BufWritePost<type!=dir>/tmp/* chmod 600
>         :autocmd BufWritePost<type==dir>/tmp/* chmod 700
>
> Perhaps this is too complicated?
>
>    
How about <isdir> and <notisdir> ... otherwise, you're bound to have
someone ask for full-fledged expressions in those <...>s.  But that
would work nicely.  I've been trying  the  *[/\\] along with BufReadCmd
and have been ending up with readonly files.  I haven't really looked
into it in detail yet to see what's doing the readonly bit (I tried  
:set verbose ro?  and didn't get anything).

Regards,
Chip 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

No comments: