search

protesilaos / mct

Enhancements for the default minibuffer completion UI of Emacs.
https://protesilaos.com/emacs/mct
GNU General Public License v3.0
33 stars 3 forks source link

request to make mct-backward-updir optional #3

Closed cburroughs closed 2 years ago

cburroughs commented 2 years ago

I understand why someone would find the mct-backward-updir behavior useful for filename-completion-map. However, I personally don't prefer it and would rather backspace behaved normally. I'd like to suggest a defcustom way to disable it (as opposed to hacking at the internals).

protesilaos commented 2 years ago

Hello @cburroughs and thanks for taking the time to report this!

My plan was to remove it altogether during the current release cycle and provide it as (i) either a separate file or (ii) document it in the manual for those who want to define it themselves, similar to how I did with the sorting functions for Emacs 29.

What do you think about this?

[ There is also a plan to rewrite or otherwise change the functionality related to line numbers---it is not good enough right now. ]

cburroughs commented 2 years ago

I think either of those options is good from my point of view. I'm not sure if providing it as a separate file makes it less likely to "bit rot", but would defer to whichever you think has the smallest maintenance burden.

protesilaos commented 2 years ago

I am leaning towards keeping it in the manual, especially as it is a single command. Let me think about it a bit more and make the changes tomorrow morning (it is almost 22h here).

In the meantime, you can get the standard behaviour with something like this:

(define-key mct-minibuffer-local-filename-completion-map (kbd "DEL") #'backward-delete-char)

Or:

(setq mct-minibuffer-local-filename-completion-map nil)
protesilaos commented 2 years ago

Just removed the command. Please let me know if everything works as intended.

minad commented 2 years ago

It is a good development direction to reduce Mct to its core features! In fact, this was one small criticism I had regarding Mct, that it bundled too many unrelated tweaks.

As you already mentioned, you could still collect the addons in a separate mct-extra.el file, which is also distributed as part of the package and loaded optionally. The tweaks from the extra package would have to be activated one by one by the user according to preference. This is the approach I've also chosen with the Vertico extensions in order to keep the core package small and maintainable. So far I've made good experiences with that. The whole set of extensions makes the package somehow a completion UI builder toolkit.

I've only read once that somebody considered Vertico "complex", due to the unfortunate misconception that the extensions are required, while for a beginner it is entirely sufficient to only install the single vertico.el file. I've expected this risk when I introduced the extensions. So one should make it very clear that it is sufficient to install only mct.el to get the core features only and I should probably emphasize this once more in my README.

protesilaos commented 2 years ago

Hello @minad!

It is a good development direction to reduce Mct to its core features! In fact, this was one small criticism I had regarding Mct, that it bundled too many unrelated tweaks.

Indeed! My original plan was to implement those changes as part of version 0.5.0 but realised they would result in a massive change log entry. So I decided to be more conservative with that release (which was published yesterday) and leave the code-cleanup for version 0.6.0.

These "extras" are the legacy of the code I had before producing the package, where I would just incorporate my tweaks directly in the file. That approach is fine for a private setup, though it is inappropriate for a package.

As you already mentioned, you could still collect the addons in a separate mct-extra.el file, which is also distributed as part of the package and loaded optionally. The tweaks from the extra package would have to be activated one by one by the user according to preference. This is the approach I've also chosen with the Vertico extensions in order to keep the core package small and maintainable. So far I've made good experiences with that. The whole set of extensions makes the package somehow a completion UI builder toolkit.

Your method with Vertico---and all the modular packages in general---is correct.

Right now I am simply documenting the extras in the manual for users who want to add the code to their own init files. I already did so with mct+avy, the CRM indicator, the ido-style directory navigation, and the sorting of candidates for Emacs 29. Furthermore, I am working on a branch to delete or otherwise refactor everything that relates to line numbers: https://github.com/protesilaos/mct/tree/refactor-completion-numbers.

I've only read once that somebody considered Vertico "complex", due to the unfortunate misconception that the extensions are required, while for a beginner it is entirely sufficient to only install the single vertico.el file. I've expected this risk when I introduced the extensions. So one should make it very clear that it is sufficient to install only mct.el to get the core features only and I should probably emphasize this once more in my README.

Ah yes, that would need to be clarified.

-- Protesilaos Stavrou https://protesilaos.com

protesilaos commented 2 years ago

I forgot to close this issue at the time I made the change. Sorry about that! In short: I removed the Ido-like behaviour and simply kept it in the manual.