display has chopped line endings (file sizes) and top file-details line

[cometsong]

FYI, I found out why the text inside the netranger vertical split window was extended beyond the right edge of the window, such as the file sizes being chopped in half.

I then set up a filetype autocmd to keep it from doing that dastardly thing:

autocmd FileType netranger setlocal nonumber norelativenumber listchars=

Thus the line numbers and the extend characters are not present and the ranger has the entire windowwidth to work with.

However, the line at the top of the list which shows the dirname or individual file details gets truncated at the end, showing only up to the -rw-

This could be due to user/group name lengths, or how many levels deep the dir "abbreviation" is, e.g. ~/f/o/o/b. As these details vary depending on individual dirs and files... any tips on how to make these consistent?

[ipod825]

I didn't realize winwidth(0) gives the same values when number is on/off.
Instead of set nonu, I think it's better to subtract the gutter width so that users can still have number in netranger buffer.

I don't quite understand what happens to your first line. Can you show a screenshot?
Ideally, without the number gutter, the width should be calculated correctly.
The only case that it might exceeds the boundary is that even after abbreviation, it still doesn't fit the window width. However, that should be a rare case (probably only when you have vertical split window).

[cometsong]

I do have a vertical split window, which is how the lines reach the right hand edge of the window.
Excellent news on subtracting the gutter, as I do really like my numbers. 👍
The screenshots below were snapped with the filetype-specific settings I mentioned above.

With cursor on dir line:

with cursor on file line:

[ipod825]

I feel this is kind of a design issue.
I have three thoughts on this:

1. Do not show the meta info (user/group name etc.) when in a vertical split window
2. Move the meta info to the second line when in a vertical split window.
3. Move the meta info to the bottom just as ranger did.

1 might be bad as users might want to see the meta info when copying/pasting in parallel window.
2 is ugly
3 should be a good choice but I feel there might be some implementation difficulty.
What's your thought?

[cometsong]

1: is not at all good in my opinion as well, as often that's what I want to see. e.g. the permissions when dealing with a webserver setup.

2: do you mean the line directly below the dir name?

3: The bottom line (or lines if wrapping it based on windowwidth) would be great, but then whenever user scrolls it will need to be simultaneously moved up and down a line, which can potentially make it time/cpu hog. Could you create a separate window directly below the file list, cf. undotree method with "diff" window? (screenshot)

Another thought you could do is make it an option for user to decide what to include:

g:netranger_file_meta_info = ['owner','group','datestamp','permissions','other-magic-fun']

[ipod825]

2: do you mean the line directly below the dir name?

Yes.

3: The bottom line (or lines if wrapping it based on windowwidth) would be great, but then whenever user scrolls it will need to be simultaneously moved up and down a line, which can potentially make it time/cpu hog. Could you create a separate window directly below the file list, cf. undotree method with "diff" window? (screenshot)

running time is actually not a concern here as I already did the same trick on the cwd (first) line. The potential concern might be that I need to figure out the logic to always detect the last line number even there's a horizontal split.
The reason that I chose not to have a separate window is because the status bar will always show up and I felt it's too ugly.

Another thought you could do is make it an option for user to decide what to include:

This can be done by another UI. But I felt it's putting unnecessary burden to the user, so possibly I won't go this way. Possibly I'll try to implement 3.

[cometsong]

The reason that I chose not to have a separate window is because the status bar will always show up and I felt it's too ugly.

The undotree uses their own statuslines for their window titles (e.g. undo). Could you use it for the dirname and/or file info? (Reformatted nicely to "match" of course.)

[ipod825]

I don't think modifying the statusline would be a good idea as even in a netranger buffer, user's statusline might still contains many useful infomation. Even if I can "insert" netranger-related info into the user's original statusline, the info might not fit the statusline when you have a vertical split window.
So I'd prefer put netranger-related info in the buffer.

[cometsong]

Makes sense.

I was just thinking of the buffer-local version as opposed to a global one as undotree does it.

setlocal statusline=%!t:undotree.GetStatusLine()

https://github.com/mbbill/undotree/blob/master/autoload/undotree.vim#L514

Whichever you like is all good here. :)

[ipod825]

It's done in 0a87b4c. Though when the contents do not occupy the whole screen, the footer does not stay at the bottom of the window (kind of ugly, sigh)

[ipod825]

general gutter, listchar are also handled. So you don't need that autocmd line anymore.

[cometsong]

I love this fix! 😃

One issue is that my listchars has extends in it, which apparently is shown even when list is off.
My original setting:

listchars=tab:⊢∽,trail:⎵,extends:⋯,precedes:⋯,eol:$,space:⎵,nbsp:·

So I still removed that.

An option to fix that (also without requiring user-fixes as you said earlier) is to set lastwidth (Vim.py#L58) to one less character. e.g.:

lastWidth = int(vim.eval('virtcol(".")')-1)

This also leaves an extra space between the files sizes and the right window edge, as shown below when I resized window (<c-w>>) and hit j twice for the redraw of each. I think the space makes the window easier to read overall. (IMHO 🙂)

[ipod825]

I don't understand why extends still takes effect even when I set nolist. Do you have any idea?
Your solution solves the problem but I don't quite understand how that work. I'll dig more into that and see if there's a general solution.

[ipod825]

I can't fix your last issue. netranger use some concealed ascii color code to control the displayed color.
However due to this issue, vim's wrap mechanism actually considers the concealed text.

The final mystery is that why your minus 1 trick works. Because even with that minus 1, the whole line including the concealed text should still overpass the screen width and so should still be considered to be wrapped by vim.

I personally don't like how it looks like with the minus 1 trick. That said, listchar is a global setting. Your autocmd will overwrite the global setting without recovering it when you leave a netranger buffer. With some trial, the following vim script snippet works (EDIT: see my below comment for a working version)

augroup NETRANGERLISTCHARS                                                                        
    autocmd BufWinEnter * if &ft == 'netranger' | set listchars-=extends:⋯ | endif
    autocmd BufWinEnter * if &ft != 'netranger' | set listchars+=extends:⋯ | endif
augroup END

The only problem is that when you vim a directory from command line, the BufWinEnter event is not captured and you'll need to leave the buffer and enter it again (e.g. go to the parent directory and go back again) to make the appearance normal.

Anyway, I'll leave this issue open for any further reference and possible (general) solution.

[ipod825]

Ha! I found the following will work in all cases:

augroup NETRANGERLISTCHARS                                                                        
    autocmd FileType netranger set listchars-=extends:⋯                                           
    autocmd BufEnter * if &ft == 'netranger' | set listchars-=extends:⋯ | endif
    autocmd BufLeave * if &ft == 'netranger' | set listchars+=extends:⋯ | endif
augroup END

[ipod825]

@cometsong
Please close the issue if you think the solution works for you.