justinmk / vim-dirvish Goto Github PK

If you press - in a buffer with unsaved changes, dirvish: E37: No write since last change is shown, just like for :e and vim-vinegar's -. That's great.

There's one difference with dirvish's -, though. If you split a buffer with unsaved changes, such as using <c-w>s, and then press -, the error message is shown too. This is different from how :e and vim-vinegar's - work: They both let you go to the new buffer (since you won't loose your changes anyway because of the other, still open buffer).

I've bumped into this quite a few times when using dirvish, and would really like the :e and vim-vinegar's behavior here.

https://github.com/justinmk/vim-sneak/blob/f00084c6f9e28e8836c3e4b5dc7e255098843a10/doc/sneak.txt#L36

Wouldn't you need to press 'ssi' again?

execute :Dirvish \\lnmp\http\ will output:

    dirvish: fatal: buffer name is not a directory: \lnmp\http\

I tried fixed it:

diff -urN a/bundle/vim-dirvish/autoload/dirvish.vim b/bundle/vim-dirvish/autoload/dirvish.vim
--- a/bundle/vim-dirvish/autoload/dirvish.vim   2016-04-05 17:19:56.000000000 +0800
+++ b/bundle/vim-dirvish/autoload/dirvish.vim   2016-04-06 16:09:25.374273000 +0800
@@ -21,7 +21,10 @@
       return ''
     endif
   endif
-  let dir = substitute(dir, '/\+', '/', 'g') "replace consecutive slashes
+  if dir[0:1] !=# '//'
+    "replace consecutive slashes
+    let dir = substitute(dir, '/\+', '/', 'g')
+  endif
   " Always end with separator.
   return (dir[-1:] ==# '/') ? dir : dir.'/'
 endfunction
@@ -31,6 +34,9 @@
     echoerr 'not a directory:' a:dir
     return
   endif
+  if a:dir =~# '^//\([^/]\+\)/\([^/]\+\)/$'
+    return a:dir
+  endif
   return s:normalize_dir(fnamemodify(a:dir, ":p:h:h"))
 endfunction

I'm not sure what to title this error, also not sure about how to debug it.

I'm getting the message:

Error detected while processing function dirvish#open..5:
line      62:
expected buffer name: "C:\home\username\vimfiles\" (actual: "")

when loading dirvish from my vimrc file. I notice that line 160 in autoload/dirvish.vim is where this error is thrown from, where your comment suggests that this is a bug.

Some things that might be contributing:

• This is under Windows (dirvish works absolutely fine in the vast majority of use cases)
• This occurs reliably when pressing - to load dirvish from within my vimrc
• My vimrc is in a folder called vimfiles, which itself is a symlink (I think this might be the root cause) to my .vim/ folder (so I can use the same folder for Windows/Cygwin/Linux.

Anything else I can provide to debug, just let me know. Thanks for this very helpful and much used plugin.

For that matter, I guess :Dirvish should take a range...

here are steps for reproducing

1. start vim with no arguments
2. press -
3. press q

I've written some code to make Dirvish behave a bit like a project drawer - essentially just opening itself in a 35-column split and closing itself when opening a file. (I personally never want to use an entire full-width buffer for a Dirvish listing.) This is the entirety of the code:

nmap <C-o> <Plug>(dirvish-toggle)
nnoremap <silent> <Plug>(dirvish-toggle) :<C-u>call <SID>dirvish_toggle()<CR>

function! s:dirvish_toggle() abort
  let l:last_buffer = bufnr('$')
  let l:i = 1
  let l:dirvish_already_open = 0

  while l:i <= l:last_buffer
    if bufexists(l:i) && bufloaded(l:i) && getbufvar(l:i, '&filetype') ==? 'dirvish'
      let l:dirvish_already_open = 1
      execute ':'.l:i.'bd!'
    endif
    let l:i += 1
  endwhile

  if !l:dirvish_already_open
    35vsp +Dirvish
  endif
endfunction

function! s:dirvish_open() abort
  let l:line = getline('.')
  if l:line =~? '/$'
    call dirvish#open('edit', 0)
  else
    call <SID>dirvish_toggle()
    execute 'e '.l:line
  endif
endfunction

augroup dirvish_commands
  autocmd!
  autocmd FileType dirvish call fugitive#detect(@%)
  autocmd FileType dirvish nnoremap <silent> <buffer> <C-r> :<C-u>Dirvish %<CR>
  autocmd FileType dirvish unmap <silent> <buffer> <CR>
  autocmd FileType dirvish nnoremap <silent> <buffer> <CR> :<C-u> call <SID>dirvish_open()<CR>
  autocmd FileType dirvish setlocal nonumber norelativenumber statusline=%F
  autocmd FileType dirvish silent! keeppatterns g@\v/\.[^\/]+/?$@d
  autocmd FileType dirvish execute ':sort r /[^\/]$/'
augroup END

I'd be glad to clean this up (remove unrelated sorting etc) and do a PR if this is something you'd be interested in merging as a let g:dirvish_project_drawer_view = 1-style option. But I also completely understand if you don't want this kind of thing in Dirvish proper.

1. Open a random file
2. killall -KILL nvim
3. Try to open the file with dirvish
4. Freeze

Now you have to press escape to continue normally or if you press <C-c> then the buffer isn't read properly.

Hey, vim-dirvish team!

I've been looking for a no-frills directory viewer like this. It is quite awesome.

I would like to set up my own custom mappings inside of dirvish. For this I needed to free up/move the keybindings for '/', '?' and '' etc..

Would it be possible to add an option such that user easily can change the various keybinding? Perhaps hard-bind them to <plug>(dirvish-...) and optionally map default keys to those?

Maybe I'm just stupid (I'm pretty new to vim in general) but when running dirvish with a file open via scp, it doesn't work. Support for this would be nice

(in case you want the error):
dirvish: invalid directory: 'scp://[email protected]/current/path'

It's great that we can change the sorting, but it's tiresome to do it every time as we go from directory to directory. Based on reading the docs, it would seem that an autocommand could solve this, e.g.,

augroup dirvish_customization
  autocmd!
  " Sort folders at the top.
  autocmd FileType dirvish setlocal modifiable | sort r /[^\/]$/ | setlocal nomodifiable
augroup END

This, however, doesn't work: we still get the default sort.

Almost any other autocommand will work, e.g.,

augroup dirvish_customization
  autocmd!
  " Sort folders at the top.
  autocmd FileType dirvish echo 'shoot me'
augroup END

Shot in the dark: I think this is because we set the filetype before we add the contents to the buffer. If we switch the order, the plugin would be a lot more customizable (unless there's some reason the filetype needs to be set before you populate the buffer).

Here I found a weird slash https://github.com/justinmk/vim-dirvish/blob/master/autoload/dirvish.vim#L411

I know the dirvish help doc states how to accomplish this but I'm wondering why it's not available by default. Seems like this is basic functionality, would you accept a PR to add this mapping by default?

$ vim / /etc

This works, I can use :n to go to the next buffer. However, this gives an error:

$ vim -p / /etc
Error detected while processing function dirvish#open..<SNR>55_do_open..<SNR>55_buf_render
..<SNR>55_win_do..<SNR>55_tab_win_do:
line    5:
E121: Undefined variable: w:dirvish

After continuing I get an empty buffer. Using gt to go to the second tab shows the / directory (and not /etc, like I would expect).

Using vim -o / /etc or vim -O / /etc also doesn't work, albeit with slightly different errors and none of the buffers get populated. Switching windows with <C-w>w gives me a Undefined variable: w:dirvish every time.

How to reproduce:

• Set g:dirvish_hijack_netrw = 0
• Open dirvish buffer
• Switch to alternate file via :b# or CTRL-^, and then switch back to dirvish.

The dirvish buffer has now become a become a netrw buffer, but it retains the dirvish mappings and leads to a lot of erroneous behavior.

I use vim installed from Ubuntu 16.04’s repositories and dirvish commit f3280a1.

$ vim --version
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Apr 08 2016 11:38:28)
Included patches: 1-1689
Modified by [email protected]
Compiled by [email protected]
Huge version with GTK2 GUI.

I’ve tested with this .vimrc (using vim-plug):

set nocompatible
call plug#begin('~/.vim/bundles')
Plug 'justinmk/vim-dirvish'
call plug#end()

I go upwards the file tree by pressing -, and downwards the file tree with <cr>.

After having pressed <cr>, I expect the cursor to be at the top of the buffer.
After having pressed -, I expect the cursor to be on the file or directory I came from.

Even if that’s not how Dirvish is supposed to work, I don’t understand how the cursor is placed. To me, it seems almost random.

Sometimes, the cursor is placed at the top – even when going upwards!
Sometimes, it is placed on some directory – but not necessarily the one I came from!

Anyone else experiencing this?

I'm contributing to this cool new repo, and I'm unable to open the challenge directories for some reason, I suspect because of weird Windows escaping and the # symbol.

I've tested this on Linux with vim and gvim and they open just fine, but on Windows this error occurs:

dirvish: invalid directory: 'C:\Git\DailyProgrammerChallenges\Intermediate Challenges\Challenge \#0012 [Intermediate]\'

I'm not sure if this is intended (i.e., you want users to use u or -), but here's the issue:

• Open directory: nvim ~/.nvim
• Enter subdirectory by pressing Enter over it
• Press <C-o>, get an error E19: Mark has invalid line number
• Press <C-o> again , back inside ~/.nvim

Edit: I should probably mention the expected behavior as you can't read my mind, which is that goes back to the directory in 1 step, without error.

Error detected while processing VimEnter Auto commands for "*":
E216: No such group or event: FileExplorer *

If I disable this line Vim starts without any error message.
Plug 'justinmk/vim-dirvish'

My current working directory is /home/martin/test/for/dirvish, I type:

vim a

where a is an existing file.

My statusline shows a, echo expand('%') outputs a, and :pwd outputs /home/martin/test/for/dirvish.

Now I exit Vim and type:

vim .

and select the a file from the directory listing.

Now the statusline shows ~/test/for/dirvish/a, echo expand('%') outputs /home/martin/test/for/dirvish/a, and :pwd still outputs /home/martin/test/for/dirvish.

I currently fix this manually with:

:cd .

Perhaps dirvish should do this automatically? I'm not sure what other side-effects this might cause though. Another alternative might be stripping the cwd from the pathname before opening the file.

Starting vim on a directory produces the following error:

% vim ~/tmp
Error detected while processing function dirvish#open[36]..35_do_open[58]..35_set_altbuf:
line 2:
E94: No matching buffer for -1

Presumably, this is related to the fact that there is no previous buffer when we open Dirvish.

Would it be possible to save &autochdir, unset it while Dirvish does its thing and restore it afterwards, with the rest of the "state" ?

Anyway to make these open dirvish instead of netrw?

1. Open a file
2. :Dirvish
3. Dirvish opens up
4. :set ft? prints dirvish
5. ...and yet, pressing <CR>, i etc. works as if it was a plain buffer.

I tried removing all the plugins and bindings. The issue persists in Neovim and Vim alike.
Using vim-plug.

Manually setting setf dirvish on unrelated buffers does conceal absolute paths into relative ones so it works to certain extent, but the bindings are missing there too.

Tested with:

rr-@tornado$ cat .testrc
call plug#begin()
Plug 'justinmk/vim-dirvish'
call plug#end()
rr-@tornado$ nvim -u .testrc

:PlugStatus shows only vim-dirvish.

When invoking ctrlp from a dirvish buffer, it opens the selected file in a split rather than replacing the dirvish buffer. This is with default ctrlp settings.

I am trying to customise the directory listing like this:

• Directories are listed before files.
• Directories and files are each sorted alphabetically.
• Dotfiles are hidden by default.

This is what I've got:

augroup my_dirvish_events
  autocmd!

  " Sort: folders at top, alphabetical, case-insensitive.
  autocmd FileType dirvish sort ir /^.*[^\/]$/

  " Hide dotfiles by default.
  " To unhide, type u to undo.  To hide again, reload with R.
  autocmd FileType dirvish silent keeppatterns g|\v/\.[^\/]+/?$|d
augroup END

It works until I try to show the dotfiles with u: instead of only unhiding them, it also un-does the sort. I'm not sure if/why vim is treating the sort and global commands as a single undo-able item.

I'm sure there's a simple solution but I can't seem to find it...

Thanks!

I use FileBeagle's + often to add a new file or directory. Do you have any plans to build that capability into vim-dirvish?

As the title say. This is the kind of error I get:

Error detected while processing function 21:
line   21:
E172: Only one file name allowed: Dirvish /Users/vheon/path/with spaces/project name/aaa/bbbb/ccc/

I have the following in my vimrc:

highlight! ColorColumn ctermbg=darkblue guibg=#E1340F guifg=#111111
call matchadd('ColorColumn', '\%81v', 100)

For some directories the above snippet causes dirvish to draw directories as follows:

If I move the cursor to errorwidget.h, this happens.

This is what I see, if I set conceallevel to 0.

Is there anything I can do to solve this? I already have a hacky solution. However, I was wondering If it was something easy to fix ( Like invoking a user autocommand on dirvish_quit ).

Is there any way to color files/dirs like git-nerdtree?

I'm using the latest version, when I browse a folder and then open a file (from dirvish itself or via ctrlp) the filetype detection doesn't kick in.
It didn't happen with ae206266555ff3e81db9f45fa54dbcb3a1a07a49 nor it happens with netrw.

is that setting made on purpose with this plugin? I see new temp files for every new dervish buffer

I don't know if this is the expected behaviour but if I do:

• vim ., the darvish buffer opens
• press Enter on a file, the file is open.
• press <C-6> I get back to the darvish buffer

I was expecting nothing to change.

dirvish's philosophy for customizing sorting is "do it yourself with an autocmd". Unfortunately, sort leaves the cursor at the top of the file, which breaks the feature that "pressing - leaves you on the name of the current file".
#45 provides a nice fix. After I implemented it, pressing - correctly placed me on the current filename.

While this fixes the behaviour when going up, it breaks the behaviour going down. Namely, I expect the cursor to be at the first line of the buffer when I hit <Enter> on a directory. Instead, the cursor ends up on the line that was at the top of the file, before sorting. This is really jarring, and almost as bad as - not working right.

I am not sure how to fix this robustly, except by introducing custom sorting (or even a custom autocmd, to be run between buffer content generation and cursor placement) as a first-class dirvish feature. I get the feeling there's a lot of demand for custom sorting, but I suspect that making it first-class runs counter to your philosophy for the plugin. Do you have any advice?

Consider the following scenario (my comments are in double parentheses):

% vim foo.txt
:Dirvish . ((opens Dirvish))
:set buflisted? ((prints "nobuflisted"))
i ((goes back to foo.txt))
:e . ((reopens Dirvish))
:set buflisted? ((prints "buflisted"))

This only happens if I :edit an existing Dirvish buffer (a freshly :edit'ed directory is nobuflisted). Also, this does not happen if an existing Dirvish buffer is reopened with :Dirvish and not with :edit.

A similar scenario, probably related to the first one:

% vim foo.txt
:Dirvish . ((open Dirvish))
:set buflisted? ((prints "nobuflisted"))
i ((goes back to foo.txt))
<Ctrl-^> ((goes back to the Dirvish buffer))
:set buflisted? ((prints "buflisted"))
``

To reproduce:

• Open a file: nvim file (:e file from nvim causes the issue too)
• Make a split based on the same buffer: :vs or :sp (both seem to cause the issue)
• Open a folder: :e ~/.nvim
• There should now be only one window (dirvish), as opposed to two (one for file, one for dirvish)

the bufread event occurs when you use the Dirvish command, surprisingly with the file already opened. This can be slow because of user autocmds and also the time needed to reread the file

When I do: vim . the BufCreate autocommand isn't executed, but if I do vim -c ':e .' it is.

I see a lot of noau in the script; I'm not sure why you would ever need that? If I understand the intention of this plugin correct, it's designed to be "just a buffer", so stuff like running autocommands seems to be a part of that to me?

At any rate, both methods (vim . and :e .) should probably do the same.

vim-sneak is indispensable for long directory listings. Type two characters, and I'm right at the directory I'm trying to get to, so just hit <Enter> and go!

Unfortunately, the sneak highlighting carries over to this new buffer. Moving around doesn't kill it, either; I have to hit <Esc>.

This seems very reproducible:

1. Make a directory where two entries have a common substring, and the first entry is a directory which contains a file with that same substring. e.g.,

   testdir/dir_xx/file_xx
   testdir/file_xx
   

   (The second entry testdir/file_xx is needed to trigger sneak highlighting, which won't happen if there's just one entry.)

2. Open testdir in dirvish.

3. Sneak to xx (make sure that dir_xx is the first entry sneak finds).

4. Hit <Enter> to go into dir_xx

5. Observe that the xx in file_xx is still sneak-highlighted, when it shouldn't be.

I am not sure if this is a bug for dirvish or sneak. Maybe you can get together with the author of sneak and figure out where the problem lies.

Since installing dirvish, I noticed that sometimes (but not always) vim would spit out an angry red storm of messages when I exit. I managed to get lucky by running gvim -V9vimlog and getting the errors to come. Among other issues, I found this:

E121: Undefined variable: w:dirvish
E116: Invalid arguments for function has_key(w:dirvish, '_w_cocu')
E15: Invalid expression: has('conceal') && has_key(w:dirvish, '_w_cocu')

My best guess for how to reproduce this uses tpope/vim-fugitive.

1. Change a file in a git repo, and save it.
2. Run :Gstatus, select that file, and hit D to diff it.
3. Make sure you're in the fugitive:///window (i.e., the left one).
4. :qa

I think you can fix this by replacing this line:

  if has('conceal') && has_key(w:dirvish, '_w_cocu')

with this one:

  if has('conceal') && has_key(w:, 'dirvish') && has_key(w:dirvish, '_w_cocu')

I am not sure whether this indicates any deeper issues (fundamental assumptions being violated, etc.) since I don't have any understanding of the codebase. But this makes the angry redness go away as far as I can tell.

Would Ctrl-L not fit better than R as a mapping to reload the directory? Of course, conserving :redraw.

Very simple to reproduce. I'll just illustrate the idea below.

Start in your home directory.

1. nvim ~/scratch
2. select a random file, any file
3. :lcd ~/scratch
4. :Dirvish
5. Now if you try to select any file, it'll give you an error because it still thinks you are in your home directory for some reason.

I've read the description for this plugin and it seems like VimFiler already does everything that this plugin does. Did I miss something?

vim 8.0 0049, run in a terminal with "set title", shows the empty string as the file name when the Dirvish buffer is entered. For example, this is the terminal title when I do :Dirvish /tmp
= (/)
I would expect the name of the current directory to appear to the left of the "=" status flag.

It looks that the fix for #47 (#53) does not work with nvim.

I use the current master (6bc12c7) and the behavior is exactly the same as described in the original issue. It works fine when I use vim with the same settings, though.

EDIT: by the way, here is my neovim version NVIM v0.1.6-36-g0ade1bb. I guess that it's probably because win_findbuf was not ported yet to neovim but I did not check this.

In Dirvish buffers, EasyMotion symbols don't show up:

It should look something like this:

Hi, and thank you for this plugin!

I would like to suggest the following change to :Shdo's behaviour: make {} optional. If not supplied, :Shdo should behave as if {} was supplied at the end.

For example, these would be identical:

• :Shdo rm {}
• :Shdo rm

This behaviour would be similar to xargs.

In case you don't think this change is appropriate, I think :Shdo should show an error if {} is not supplied.

Thanks!

When I open dirvish just after starting vim pressing q to close it again has no effect.

Is this by design? Because netrw seems to focus the opened split.