-
Notifications
You must be signed in to change notification settings - Fork 84
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to override built-in sequences with longer sequences? #479
Comments
You can override built in sequences just fine. e.g. You could define 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 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 <space> appended, with the old replacement, since <space> is a standard "early exit" character. This would be an "automatic upgrade" of the old sequence. e.g. 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 <Multi_key> <1> </> <space>. |
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? |
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 <Multi_key> <-> <-> <space> for an en-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 🤣) |
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 <Multi_key> <-> <-> <space> for an en-dash". But I note that "<space>" is not showing. You just need to put a backslash before it, i.e. "\<space>". 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. |
Thanks for catching that @dkeenan7 , I didn't realize git had eaten the <space>! Updating the title too, I think that makes it clearer. |
I am trying to define custom sequences for vulgar fractions:
The ⅔ and ¾ fractions work fine, but the first three don't, because there's a built-in:
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 thantsp
). 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.
The text was updated successfully, but these errors were encountered: