Published 2024-10-18
tag(s): #programming #emacs
A while ago I mentioned I stopped using fido-mode. The idea being that not relying on a completion framework would be slightly painful at first, but yield some benefits later. An update post confirmed this to be mostly true.
In that last post, I said:
Today I wanted to share a great example of this. Funnily enough, on my way to fix that case, I found a different one.I am now more aware not only of the naming conventions of things at work, but even for my own packages and custom code, I am revisiting the naming of some commands to make them more consistent.
I became aware that my proto-package to wrap some GitHub CLI operations had inconsistencies in command names. I navigated to the repo and right when opening the file I noticed this:
.git
README.md
azcli.el
ghcli-tools.el
jira-tools.el
pyvenv.el
That's the dired listing. jira-tools.el was probably the first file, then
came ghcli-tools.el , but when I added azcli.el, I didn't add the
suffix "-tools" to it. Which now, looking back, is a pretty dumb naming convention: everything
in that repo could (should?) have the suffix, then what's the point.
But that's not important now. What matters is consistency. I am leaning on
renaming ghcli-tools.el to ghcli.el because the command prefix for
the module is "ghcli-".
Which leads back to the original issue I was meaning to fix. I noticed something in the "pr"
(pull request) commands: ghcli-create-pr has the action first, then the subject.
But ghcli-pr-view has the subject first, then the action. I listed all the
"public" functions using occur to see if there were similar cases:
11 matches for "(defun ghcli-[^-]" in buffer: ghcli-tools.el
214:(defun ghcli-list-org-repos (&optional query)
255:(defun ghcli-pr-view (pr-number)
319:(defun ghcli-code-search (search-term &optional arg)
396:(defun ghcli-create-pr ()
422:(defun ghcli-list-my-prs (&optional arg)
493:(defun ghcli-workflow-run (workflow-id branch &optional params)
509:(defun ghcli-workflow-list (workflow-id branch)
I can see that the workflow commands are consistent. And then list-my-prs
and list-org-repos are consistent between them too. They just use the opposite
convention! 🤣
So I have to decide if I want to change all of them to have the action first, or the target. I am leaning on having the target first, the end result would be:
ghcli-repos-org-list
ghcli-pr-view
ghcli-code-search
ghcli-pr-create
ghcli-pr-list-mine
ghcli-workflow-run
ghcli-workflow-list
The biggest change is ghcli-list-my-prs to ghcli-pr-list-mine, I
think the name is still descriptive enough.
I think that if was going to make this into a proper, self-contained package, I most likely
would have checked the naming of the commands to make sure they followed the same convention.
But it is interesting that not having completion popping the list right away made these
problems obvious, I had been using these commands for quite some time now without
noticing.
And the filename inconsistency I found on the way to correct the commands is the cherry on
top.
There are cases when not having the completion pop up right away is an annoyance, though. For
example I have a command to insert the tags for a page[1] and in many
cases (not all, but most?) I want to peruse the list to find the right one, then I need to
press C-i (or TAB) to get the *Completions* buffer to
pop up.
Overall, I am still happy with my current setup, no regrets! I might come back to fido (or icomplete-vertical. or even try Vertico) if I feel I need to. But I think this post proves I am getting value from this "minimal" experience.