Feature Request: Option to use `conceal` to hide hashes
jeetsukumaran opened this issue · 9 comments
Would you be interested in allowing for the hashes to be hidden using the conceal syntax? Maybe hidden entirely or substituted by a character of the user's choice? I can work on a PR if so.
I've thought about this before and I personally don't think it's a good idea to have hashes being concealed, since without them it's impossible to tell by eye if a file is being deleted and a new file is being created or if a file is just being renamed. In this example image I went to dirbuf's repo, renamed README.md to new_README.md, and deleted lua/ and replaced it with new_lua/
As such, I'm not comfortable with enshrining this as a config option in Dirbuf since I fear people, especially those new to Dirbuf, will enable the option because they think it looks nicer, only to then run into issues where they accidentally delete files with Dirbuf or find it's hard to determine what Dirbuf will do just by looking at the buffer.
That being said, you're not the first person to ask about conceal, so I think I'm comfortable adding an "officially sanctioned hack" to the documentation with a disclaimer. This after/syntax/dirbuf.vim file would be the "hack"
syntax clear DirbufHash
syntax match DirbufHash /^#\x\{8}\t/ms=s-1 conceal
" or for `hash_first = false`
" syntax match DirbufHash /\t#\x\{8}\s*$/ms=s+1 conceal
setlocal conceallevel=3Thanks for the quick response.
That "hack" works really well (and, FWIW, I see it more as a "customization" than a "hack" ;).
FWIW, I've "hacked the hack" to:
syntax clear DirbufHash
syntax match DirbufHash /^#\x\{8}\t/ms=s-1 conceal cchar=#
syntax match DirbufNewFile /^[^#].*/
highlight default link DirbufNewFile SpecialKey
" or for `hash_first = false`
" syntax match DirbufHash /\t#\x\{8}\s*$/ms=s+1 conceal
setlocal conceallevel=2
setlocal concealcursor=n
The first replaces the concealed text with a placeholder token, so we "know" something is there.
The second highlights new/uncreated files in a different color.
The first replaces the concealed text with a placeholder token, so we "know" something is there.
Oh this is really smart! That fixes the issue where new files are ambiguous. I don't know why I didn't think of that 🤦. I think I'll use your customization (😉) sans the DirbufNewFile syntax group as the example in the docs if you don't mind.
The reason I want to exclude the DirbufNewFile syntax group is because sadly it overrides the normal DirbufFile, DirbufDirectory, ..., and DirbufMalformedLine highlighting, which I think is valuable.
If this customization proves to be popular, I'd actually be okay with potentially enshrining it as a configuration option.
I added your example sans DirbufNewFile to the in 8c7c1f7 like I mentioned earlier, along with a link to this issue where others can voice their opinions if they want built-in conceal support as well
Is it possible to display hashes via virtual text?
I talked about this in #6 but the gist is no, even tho it feels like it should. The reason is virtual text is attached to an extended mark, and extended marks don't get copied or deleted by editing text. I experimented with this in super early versions of dirbuf.nvim but it ended up not working
I talked about this in #6 but the gist is no, even tho it feels like it should. The reason is virtual text is attached to an extended mark, and extended marks don't get copied or deleted by editing text. I experimented with this in super early versions of dirbuf.nvim but it ended up not working
Well, if convenient ,can you state how you sync dirbuf to filesystem?🤣
Well, if convenient ,can you state how you sync dirbuf to filesystem? 🤣
Sure thing! I plan to write up something about how Dirbuf works and link to it in the README but haven't finished it yet. But a quick overview without getting too off-topic is that when you open a directory buffer, Dirbuf keeps a record of all the filesystem entries in the directory buffer tracked by a hash (which has recently been changed to an index) which is displayed next to the file/directory in the buffer. Then when you sync the directory buffer, it reads the buffer and associates every filename in the buffer with the recorded filesystem entries based off of its hash in the buffer. This results in a data-structure kinda like this
Then Dirbuf runs an algorithm on this to resolve inter-dependencies, resolve cycles, and remove unnecessary actions (e.g. copying a file to itself, converting copies to moves if possible). After this we get a list of actions which can be displayed to the user and/or executed.
I'm closing this since there is a 'conceal' recipe in dirbuf.txt