Skip to content
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

Open
DoktorJ opened this issue Sep 15, 2022 · 5 comments
Open

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

DoktorJ opened this issue Sep 15, 2022 · 5 comments

Comments

@DoktorJ
Copy link

DoktorJ commented Sep 15, 2022

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
Copy link

dkeenan7 commented Oct 25, 2022

You can override built in sequences just fine. e.g. You could define
<Multi_key> <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
<Multi_key> <1> </> <2> : "½"
this should deactivate any of these that might be active:
<Multi_key> <1> </> <2>
<Multi_key> <1> </>
<Multi_key> <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 <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.
<Multi_key> <1> </> : "⅟"
would automatically be replaced with
<Multi_key> <1> </> <space> : "⅟"
before
<Multi_key> <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 <Multi_key> <1> </> <space>.

@johnallsup
Copy link

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
Copy link
Author

DoktorJ commented Nov 1, 2022

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 versus <Multi_key> <-> <-> <-> 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
Copy link

dkeenan7 commented Nov 1, 2022

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.

@DoktorJ
Copy link
Author

DoktorJ commented Feb 1, 2023

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

@DoktorJ DoktorJ changed the title Unable to override built-in sequences? Unable to override built-in sequences with longer sequences? Feb 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants