Insert in dictionary lower-cased?

[rrthomas]

(I've now been using jinx rather than ispell for some months, and am very happy with it; many thanks!)

I'm trying to find a jinx equivalent for ispell's feature that allows a word to be inserted in the dictionary, but lower-cased. If it doesn't exist, then this is a feature request! If it does exist, this is an apology; I looked at the source code and wiki before opening this issue.

If it does not yet exist, then I have a design suggestion: it should be a modifier rather than a separate action as in ispell, where it's only possible to insert a word lower-cased in the user's dictionary, but not in the session or per-file wordlists.

So, I would imagine adding a modifier to the jinx-correct-nearest "dialog", perhaps l, which toggles whether the word will be downcased before being entered in the relevant dictionary. Typing the modifier could show the word downcased in the dialog, so it would be obvious at any stage what pressing @, *, / or + would enter.

If something like this seems acceptable (I did not find any trace of a discussion in closed items either) then I would be happy to have a go at implementing it.

[minad]

So, I would imagine adding a modifier to the jinx-correct-nearest "dialog", perhaps l, which toggles whether the word will be downcased before being entered in the relevant dictionary. Typing the modifier could show the word downcased in the dialog, so it would be obvious at any stage what pressing @, *, / or + would enter.

What about actions with a < prefix key, e.g., <@, <* and so on with lower-case candidate strings? So it is like a modifier, but also like a separate action.

[rrthomas]

It had always been like that. Since the Jinx correct UI is based on completing-read, we have to work with various completion UIs and various completion styles which we do not control. On the upside, the result is quite convenient and requires little code, but depends on the specifics of the completion UI. On the downside, we are more restricted in our choices, keybindings etc. I still think that it is better to go this way than implementing a completely custom UI as is done in Ispell for instance.

Fair enough! But still, choosing non-alphanumeric keys for jinx is quite a restriction. It would not have been a problem with letters, for example..

It is also the most natural choice given that Jinx allows you to edit the word after the @, +, *. One can save @arbitrary word this way.

Yes! I like it.

[rrthomas]

Please try out 65c92fe. Does this work well for you?

Yes, this is great! Many thanks for the rapid implementation.

[minad]

Fair enough! But still, choosing non-alphanumeric keys for jinx is quite a restriction. It would not have been a problem with letters, for example..

Well, letters have bigger problems. They match the actual words if you use the builtin substring completion style for example. The design is severely restricted due to the completion styles which can do whatever they want. This has caused me headaches before, but overall I still like the result.

Yes, this is great! Many thanks for the rapid implementation.

Okay, thanks for checking.

[rrthomas]

I don't think I've gotten my head around the fact that you're using whatever general completion system is in use, not a custom prompt like ispell.

[minad]

For me the main advantage of using the general completion system is that the Emacs UI overall becomes a little more coherent - Helm, Ivy or Vertico everywhere. I prefer this over every package inventing its own UI. But of course, we can only push completion so much and there are certainly use cases where a custom UI works better. Jinx is an edge case I think.