samhocevar / wincompose

🔣 Compose Key for Windows
http://wincompose.info/
Other
2.63k stars 83 forks source link

Unable to override built-in sequences with longer sequences? #479

Open DoktorJ opened 2 years ago

DoktorJ commented 2 years ago

I am trying to define custom sequences for vulgar fractions:

<Multi_key> <1> </> <4> : "¼" # Vulgar fraction 1/4
<Multi_key> <1> </> <3> : "⅓" # Vulgar fraction 1/3
<Multi_key> <1> </> <2> : "½" # Vulgar fraction 1/2
<Multi_key> <2> </> <3> : "⅔" # Vulgar fraction 2/3
<Multi_key> <3> </> <4> : "¾" # Vulgar fraction 3/4

The ⅔ and ¾ fractions work fine, but the first three don't, because there's a built-in:

Fraction Numerator One U+215F ⅟

It's not in any of the res files, and even disabling the other sequence options doesn't get rid of it, making it entirely impossible for me to define these sequences. I can't see myself ever using the fraction numerator character. To get 1/4,1/3,1/2 I'd have to use that and then the sequence for the relevant subscript denominator e.g.

⅟₂ = <MK><1></><MK><_><2> ⅟₄ = <MK><1></><MK><_><4>

Which just really seems unnecessary to me. It consumes an extra character space on limited-length platforms, and is more prone to editorial munging (like if I'm typing ⅟₂tsp in a recipe but decide I want a space, accidentally hit backspace 4 times instead of 3 and now I'm left with ⅟ tsp which is a lot less visually distinguishable as an error than tsp). Also, typographically, ⅟₂ and ½ may look different in different fonts (here, the subscript 2 is set below the baseline as a subscript should be, but the vulgar fraction sits on the baseline), and if a font has the specific vulgar fraction defined I'd much rather stick with that.

I'm sure there are other folks who want to define sequences that are "blocked" by built-ins. What would be really lovely is to have a priority list that a user can drag around to specify which set of sequences should be processed first – notably, this needs to include partial sequences, so that my .XCompose definition of <Multi_key> <1> </> <4> can override the default Fraction Numerator One sequence. I've seen other bugs submitted where users have problems with a partial sequence (#464 , #323 , etc), and think that being able to prioritize which list takes precedence as well as whether partials should be "held" to check for longer sequences would be nice.

Yes I know there are sequences for the vulgar fractions, but my OCD brain always tries to put the slash and I have to go back and correct myself. I'd much rather be able to define it the way I want to use it, and I'm sure others have run into similar conflicts, possibly with other sequences, hence this bug.

dkeenan7 commented 2 years ago

You can override built in sequences just fine. e.g. You could define

<1> : "foo" if you wanted to. A better description of this bug would be "**Unable to override built-in sequence with longer sequence**". No additional user interface is required to fix this bug. There's no need to be able to arrange priorities. The only priority system we need is that the last sequence to be defined wins. This is currently what happens with identical sequences. All we need is that a new sequence should not only override old sequences that are the same, it should also override old sequences that are _prefixes_ of it. So when you define <1> <2> : "½" this should deactivate any of these that might be active: <1> <2> <1> <1> Only one of these can be active. If the old sequence was _shorter_ than the new sequence, WinCompose could be _really_ friendly by automatically adding another new sequence that is the old sequence with a \ appended, with the old replacement, since \ is a standard "early exit" character. This would be an "automatic upgrade" of the old sequence. e.g. <1> : "⅟" would automatically be replaced with <1> \ : "⅟" before <1> <2> : "½" is added. Of course it should not do the automatic upgrade if the automatic new sequence happens to be the same as the user's new sequence. i.e. if the user was defining <1> \.
johnallsup commented 2 years ago

I'm curious where and how the stock sequences are defined -- if I git clone the repo, where do I find the stock definitions in the source?

DoktorJ commented 2 years ago

What @dkeenan7 offered would be a perfect solution – longer sequences when defined later should override shorter sequences, and the early-exit path to access the default (or earlier-defined user) sequences would be ideal. Just like I use <-> <-> \ for an en-dash versus <-> <-> <-> for an em-dash

(also, I'm just noticing in the editor here that an em-dash is 38% longer than it should be, at least in this particular font, but that's not a Wincompose issue 🤣)

dkeenan7 commented 2 years ago

I'm glad you like it @DoktorJ. I just hope it is easy for our hard-working Sam to implement.

I assume you wrote above: "Just like I use <-> <-> \ for an en-dash". But I note that "\" is not showing. You just need to put a backslash before it, i.e. "\\".

Also, I think you can change the title of this issue, e.g. to "Unable to override built-in sequence with longer sequence", if you want to, by editing your original post.

DoktorJ commented 1 year ago

Thanks for catching that @dkeenan7 , I didn't realize git had eaten the \! Updating the title too, I think that makes it clearer.