greghendershott / racket-mode

Emacs major and minor modes for Racket: edit, REPL, check-syntax, debug, profile, packages, and more.
https://www.racket-mode.com/
GNU General Public License v3.0
682 stars 93 forks source link

Remove "oint" keybinding in racket-unicode input method #717

Closed bkc39 closed 2 months ago

bkc39 commented 2 months ago

The oint quail prefix activates when writing common identifiers such as point and pointer. This removes the binding from the input method out of convenience.

greghendershott commented 2 months ago

Thanks for the PR!

This is one feature I don't "dog food" myself. So I don't have any useful opinion. I'm happy to defer to you, and merge this.

Comment: I didn't realize these trigger in the middle of words. That seems... tricky.

Question: Just out of curiosity, are these case sensitive? If so, would it make any sense maybe to change it from "oint" to "Oint"?

(Not seeking a long discussion. Just wanted to ask before merging.)

capfredf commented 2 months ago

I feel like we should use a leader/prefix key to turn on the unicode input method

bkc39 commented 2 months ago

This is one feature I don't "dog food" myself. So I don't have any useful opinion. I'm happy to defer to you, and merge this.

Yea, this came up on the Racket Discord channel and some others seem to have experienced the same issue.

Comment: I didn't realize these trigger in the middle of words. That seems... tricky.

Yea what i generally do is C-g right before the last character to exit the quail completion.

Question: Just out of curiosity, are these case sensitive? If so, would it make any sense maybe to change it from "oint" to "Oint"?

The bindings are case sensitive. I would personally be fine with "Oint" as the mapping and agree that is better than removing the binding completely

bkc39 commented 2 months ago

I feel like we should use a leader/prefix key to turn on the unicode input method

C-\ toggles the input method on and off. The issue with oint is that because oint is a common substring of Racket identifiers you end up having to toggle a lot.

capfredf commented 2 months ago

I was not clear. In the agda2 mode, the Agda unicode input method is turned on by default, but one needs to press \ to input the unicode symbols.

bkc39 commented 2 months ago

I would be fine with something similar to Agda mode. I also use the TeX input method which has the same convention as Agda, but I think that would be different enough behavior that we may want to consider making a different quail package altogether. If we decide on a name for the input method I would be fine adding something that has the same keybindings as racket-unicode but uses a prefix \ instead of a suffix space .

greghendershott commented 2 months ago

It looks like agda2-mode does this, not in the translation map itself, but via a user customization agda-input-tweak-all to tweak that map in various ways.

The customization is extremely generalized; including predefined functions. (First glance, I wonder is that excessive? But subsequent glances, maybe I'd say sure why not.)

greghendershott commented 2 months ago

In any case, some customizable prefix (and/or suffix?) seems the way to go.

For example, if I were using this mode, a \ prefix would drive me nuts given how often I need that for escapes in Racket strings and regexps. In fact that's bound to paredit-backslash for me. Also, I had to type \\ twice to escape itself here in this markdown comment. :)

greghendershott commented 2 months ago

It looks like agda2-mode does this, not in the translation map itself, but via a user customization agda-input-tweak-all to tweak that map in various ways.

The customization is extremely generalized; including predefined functions. (First glance, I wonder is that excessive? But subsequent glances, maybe I'd say sure why not.)

This seems like the right direction to proceed.

I'd be fine cargo-cult-ing all of the agda-mode code (because, hell, originally this was mostly cargo-cult-ed from haskell-mode). Of course, just using the rackety translations, instead.

I'd also be fine limiting the predefined utility functions, for users when customizing, to just the stuff pertaining to changing the prefix. No strong opinion here either way.

@bkc39 I don't know if this is something you would still like to do as a PR? If that feels like too much: I could take a crack at this, probably within a week after getting a finish on another issue I'm currently working on.

bkc39 commented 2 months ago

@greghendershott I could probably take a swing at this this weekend. Do you think this should be included in this PR or submitted separately? Do you think we should update racket-unicode input method or make another that "inherits" from racket-unicode like they "inherit" from TeX in agda2-mode?

I actually have the beginnings of this in my personal config but I am not sure the best way to port it into the racket-mode package.

greghendershott commented 2 months ago

It seems that the existing translation table could be fine, provided there's a way users can customize a prefix or suffix?

If you do agree, then I'd say the PR could morph into or be replaced by the new "cargo cult agda2-input" plan.

But maybe you disagree, because you'd rather not type any prefix at all; you just want to change "oint" to "Oint" and you'd be happy? So for you the esting PR would suffice?

If so, that's OK, too. Just let me know. I could merge your simpler change, and then you or I could tackle the bigger change, later.

Or,

bkc39 commented 2 months ago

It seems that the existing translation table could be fine, provided there's a way users can customize a prefix or suffix?

I agree.

But maybe you disagree, because you'd rather not type any prefix at all; you just want to change "oint" to "Oint" and you'd be happy? So for you the esting PR would suffice?

I think that in the immediate term the "oint" binding specifically is what I and others would like change and in that sense the existing PR would suffice to remove the pain point.

If so, that's OK, too. Just let me know. I could merge your simpler change, and then you or I could tackle the bigger change, later.

My preference would be to merge this change and then have a separate PR for the bigger change as that is likely to warrant more scrutiny.

greghendershott commented 2 months ago

Merged; thanks!

greghendershott commented 1 month ago

@bkc39 I wanted to give you a heads up about commit 36c7062, which I just merged.

Among other things, it:

If you try this, you might like it. But if you don't, you could restore things exactly to the previous status quo:

In other words the default should reduce conflicts. And for people who don't like a prefix, they can remove that, and racket-input-translations can now be customized without needing to make a PR.

I hope I explained this well; if you have any questions please let me know.

And thanks again contributing the original PR, it was helpful in the meantime!