How about a dirvish-filter extension?

[alexluigit]

Related to the performance of dired, do you have any ideas that can make dired-filter-groups faster? I like them a lot and would like to have them enabled if I accidentally open a directory with large number of files but the performance is slow. My knowledge of dired internals is non-existent so I don't know if that aspect can be made faster, but if you have any ideas I will like to try in (not so) near future.

Ref: wyuenho/all-the-icons-dired#16

Not that I know of. The reason for that is dired-filter.el heavily relies on dired-revert, which, unfortunately, is very slow especially on large/remote directories. This also puts the filter stack mechanism in a very awkward situation: it's not useful for small directories, yet it's slow on big directories. Besides, this package provides a lot of features that overlaps with dired's inbuilt marking system, of which I'm not a big fan. For the reasons above I've stopped using this package. I'm planning to implement a stripped-down version of this package in the form of a dirvish extension (like dirvish-subtree as to dired-subtree), maybe in the near future.

[aikrahguzar]

Not that I know of. The reason for that is dired-filter.el heavily relies on dired-revert, which, unfortunately, is very slow especially on large/remote directories.

Why is that? I got lost when I was reading (a while ago) the code in it but the very high level idea seemed to go through the buffer line by line and keep the lines that should be kept which seems like the obvious thing to do. I doesn't seem like that should need dired-revert.

This also puts the filter stack mechanism in a very awkward situation: it's not useful for small directories, yet it's slow on big directories. Besides, this package provides a lot of features that overlaps with dired's inbuilt marking system, of which I'm not a big fan. For the reasons above I've stopped using this package. I'm planning to implement a stripped-down version of this package in the form of a dirvish extension (like dirvish-subtree as to dired-subtree), maybe in the near future.

This is indeed awkward, but filter stack has been useful to me even in small directories in that I can keep important files at the top. For example I used it to keep tex files at the top and then pdf files and then style files etc in a dired buffer which is difficult to achieve with a sort based on extension.

I think an extension is a good idea and I can try writing it myself in a few weeks but I do need an overview of what is involved.

P.S. dirvish-subtree and the drop like indicators for it are very nice.

[aikrahguzar]

Is it what you are looking for?

(group-name (file-attribute-group-id attrs))

This gives us the group the files belongs too. If the file doesn't have the other executable bit set, we need to know if the groups the current user belongs too to know if they can execute the file. This is probably going a bit too much into academic territory though. I haven't seen an executable without that bit set and chmod +x which is the most common way of making a file executable, sets all three bits. So what you suggested along with the check that the file is not a directory should be enough i.e

(dirvish-emerge-define-predicate executables "Matches executables."
    (and  (eq 'file (car type)) (eq ?x (aref (file-attribute-modes attrs) 3))))

The situation with dired-omit is actually more complicated than I initially realized ...

Personally I don't use this feature very often, does the following setup achieves the same results as dired-omit-mode does for you?

(setq dirvish-emerge-groups `(("Omit" (regex . ,dired-omit-files) t)))

If this works fine, maybe we can write a helper command to toggle the visibility of this "Omit" group. Basically the same thing as dired-omit-mode, but faster.

I actually wanted to suggest that. I think toggle the visibility depending on the value of dired-omit-mode should work better than directly using dired-omit-expunge. But dired-omit-files is not the complete story, the correct way to get the omit regexp is (dired-omit-regexp). This is because in addition to dired-omit-files there is also dired-omit-extensions. The regexp (dired-omit-regexp) produces seemed to perform poorly compared to the one by dirvish-emerge for extensions so I checked the difference and it seems like the difference is dirvish checks for dot only once while the elements in dired-omit-extensions aren't really extensions and they are basically matched at the end of filename. I have only extensions in that variable (quite a lot of them) and my entry for an "Omitted" group is,

("Omitted" (regex
            . ,(rx-to-string
                `(or (regexp ,dired-omit-files)
                     (and "."
                          (or . ,(mapcar (lambda (str) (substring str 1)) dired-omit-extensions))
                          eos)))))

The regexp above performs better but will fail for any entry in dired-omit-extensions that doesn't start with a dot.

For now this option still only impacts full-screen sessions, so there might be some unexpected behaviors, I'll make it take effect in both scenarios.
Thanks for this.

[alexluigit]

the elements in dired-omit-extensions aren't really extensions and they are basically matched at the end of filename

IMO that's not a good practice. Filenames like "foo~" should not be seen as file "foo" with "~" as its extension. So the "Omitted" group you provided is totally fine I guess. Maybe we can add a user option like dirvish-emerge-omitted-files and set its default value as you provided above.

[alexluigit]

I'm not sure if it's a bug of Dired, but after open a dired buffer in emacs -q, (buffer-modified-p) gives t instead of nil.

I think normally dired buffers appear modified only if files have been marked/copied/moved etc.

This only happens after dired-omit-mode being applied to the buffer.

I hope ac08fc3 handled the modification state correctly. Apart from using with-silent-modifications, I also gave every dirvish buffer an initial unmodified state.

[aikrahguzar]

This only happens after dired-omit-mode being applied to the buffer.

That might be, I have had dired-omit-mode in my dired-mode-hook for a long time.

I hope ac08fc3 handled the modification state correctly. Apart from using with-silent-modifications, I also gave every dirvish buffer an initial unmodified state.

Yes, it works perfectly now. Thanks!

[aikrahguzar]

IMO that's not a good practice. Filenames like "foo~" should not be seen as file "foo" with "~" as its extension. So the "Omitted" group you provided is totally fine I guess. Maybe we can add a user option like dirvish-emerge-omitted-files and set its default value as you provided above.

I agree with it not being a good practice but it seems to be common, e.g. doom uses that misfeature. That predicate is pretty problematic to provide by default, since it needs to be defined after dired-omit-mode is loaded and even then it won't change it the variables from dired-omit-mode are changed. I think it is better to put it in the documentation about how dired-omit-mode can be used with dirvish-emerge.

About avoiding dired-omit-exounge, I think the best way is to allow users to set the third entry of the members of dired-emerge-groups. This is already possible I think and just needs to be documented. We can allow three values for it, nil means the group is shown, t means that group is hidden but we show its header indicating that is it hidden, and if it is omitted then nothing is shown.

I can implement this in the pr I opened.