Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using - in modified buffer produces error when nohidden #77

Closed
fweep opened this issue Oct 30, 2016 · 3 comments
Closed

Using - in modified buffer produces error when nohidden #77

fweep opened this issue Oct 30, 2016 · 3 comments

Comments

@fweep
Copy link

fweep commented Oct 30, 2016

If the current file is modified and unsaved, and nohidden is set, and I hit -, I get this error:

Error detected while processing function <SNR>38_opendir:
line   12:
E37: No write since last change (add ! to override)

I would never normally use vim with nohidden, and I have no idea how it even got set that way, so this isn't really a big deal. I set hidden and it worked fine. I restarted vim just to check and see if for some reason vinegar had changed the flag, and of course had hidden set, so everything's fine...but you might want to check for this and handle the scenario more cleanly.

@kiryph
Copy link
Contributor

kiryph commented Nov 2, 2016

This does make sense: without set hidden, any modified and unsaved buffer cannot be put into background. Or did I get you wrong?

Note, :h abandon and :h E37 might be more insightful than :h 'hidden'.

@fweep
Copy link
Author

fweep commented Nov 8, 2016

It makes sense, it's just an ugly multi-line error and it's not entirely clear what the reason is. I'm going to close this because I don't think it necessarily needs any attention.

@fweep fweep closed this as completed Nov 8, 2016
@kiryph
Copy link
Contributor

kiryph commented Nov 8, 2016

I see your point. Following patch would remove the multi-line error:

diff --git a/plugin/vinegar.vim b/plugin/vinegar.vim
index 85ed2a4..a50b4ba 100644
--- a/plugin/vinegar.vim
+++ b/plugin/vinegar.vim
@@ -43,16 +43,20 @@ function! s:opendir(cmd) abort
   if expand('%:t')[0] ==# '.' && g:netrw_list_hide[-strlen(df):-1] ==# df
     let g:netrw_list_hide = g:netrw_list_hide[0 : -strlen(df)-1]
   endif
-  if &filetype ==# 'netrw'
-    let currdir = fnamemodify(b:netrw_curdir, ':t')
-    execute s:netrw_up
-    call s:seek(currdir)
-  elseif expand('%') =~# '^$\|^term:[\/][\/]'
-    execute a:cmd '.'
-  else
-    execute a:cmd '%:h/'
-    call s:seek(expand('#:t'))
-  endif
+  try
+    if &filetype ==# 'netrw'
+      let currdir = fnamemodify(b:netrw_curdir, ':t')
+      execute s:netrw_up
+      call s:seek(currdir)
+    elseif expand('%') =~# '^$\|^term:[\/][\/]'
+      execute a:cmd '.'
+    else
+      execute a:cmd '%:h/'
+      call s:seek(expand('#:t'))
+    endif
+  catch /.*/
+    echo v:exception
+  endtry
 endfunction

 function! s:seek(file) abort

This returns a one-liner:

Vim(edit):E37: No write since last change (add ! to override)

Another option is following diff which avoids orphan/stray netrw buffers which occur when set hidden is active. See discussion in #74.

❯ git diff
diff --git a/plugin/vinegar.vim b/plugin/vinegar.vim
index 28adce4..a59e279 100644
--- a/plugin/vinegar.vim
+++ b/plugin/vinegar.vim
@@ -29,7 +29,7 @@ if !exists("g:netrw_special_syntax")
 endif
 let s:netrw_up = ''

-nnoremap <silent> <Plug>VinegarUp :call <SID>opendir('edit')<CR>
+nnoremap <silent> <Plug>VinegarUp :call <SID>opendir('Explore')<CR>
 if empty(maparg('-', 'n'))
   nmap - <Plug>VinegarUp
 endif

In this case no error is raised the netrw buffer is forced to be open in a split window without explicitly using :Sex or :Vex

netrw-:Explore
:Explore will open the local-directory browser on the current file's
directory (or on directory [dir] if specified). The window will be
split only if the file has been modified and |'hidden'| is not set
,
otherwise the browsing window will take over that window. Normally
the splitting is taken horizontally.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants