Should we remove the `pacdef group` commands about pacdef HOT 10 CLOSED

I use them often. Yes, they are in principle convenience functions, but they are useful, and essential to me.

from pacdef.

But are they more convenient? Why not just use fundamental file management methods instead?

from pacdef.

The benefit of learning "regular" methods is that they are cross-compatible with all you config files as opposed to the pacdef group commands which can only ever be used for interacting with pacdef files.

from pacdef.

Yes. Instead of nvim ~/.config/pacdef/groups/<TAB><TAB>audio, I do pged <TAB>audio. And pged is alias pged = pacdef group edit which I use because I use it so often.

When I import groups, I go to my dotfiles repo, look for the one I want to use, and go pgi whatever, or pacdef g i whatever.

Yes, they are convenient. We are not getting rid of them.

from pacdef.

The benefit of learning "regular" methods is that they are cross-compatible with all you config files as opposed to the pacdef group commands which can only ever be used for interacting with pacdef files.

That is not an argument why pacdef group is bad or misplaced.

from pacdef.

When I import groups, I go to my dotfiles repo, look for the one I want to use, and go pgi whatever, or pacdef g i whatever.

Those are all things which could be automated using regular dotfiles automation tools though?

Yes. Instead of nvim ~/.config/pacdef/groups/audio, I do pged audio. And pged is alias pged = pacdef group edit which I use because I use it so often.

And for you alias you could use alias pged = nvim ~/.config/pacdef/groups then use a telescope fuzzy finder to select a group file to edit.

That is not an argument why pacdef group is bad or misplaced.

My argument is not that they are harmful directly, but that I don't think they justify their own existence in the codebase when many users such as myself would never use them and so might consider it bloated and so make maintenance more difficult (especially since that code is tightly coupled to the other implementation details in the crate rather than being de-coupled by using fundamental file management commands (cp, ln, mv, etc)

from pacdef.

Perhaps, at least de-coupling the functionality into a different crate would be an improvement without entirely removing them then?

from pacdef.

What concrete improvements would you expect?

from pacdef.

Easier code maintenance due to the de-coupling of functionality.

from pacdef.

I would not call that concrete. Please point to specific code smells that could be removed / improved when we go forward with your approach.

EDIT: I'm offline for today, will take another look tomorrow or Friday.

from pacdef.