xcompose
xcompose copied to clipboard
kragen
Systematizifcationizing?
The Fever
So, I only discovered XCompose recently, and I found it exciting. Then, stumbling upon kragen/xcompose was double-exciting, but almost instantly I want to find myself triple-excited. This is a very rapid onset of addiction. I'm basically the guy described here: http://youtu.be/8r1CZTLk-Gk
Proposed Solution
I think the project needs some overlays. We already have /usr/share/X11/locale/en_US.UTF-8/Compose as a base layer, with ~/.XCompose stacking on top of it. But, in my opinion, there should be more user preferences that go on top of that.
Implementation?
I modified my kragen/xcompose output to have this:
include "/home/rking/.XCompose-local"
...and it seems to work cleanly for the case where it's absent (e.g., I couldn't find any error messages) and it does use those mappings when it is present.
The downside is that I couldn't figure out a way to get rid of the hard-coded username. I tried:
include ".XCompose-local" # only works for programs started in ~ include "~/.XCompose-local" # Nope. include "$HOME/.XCompose-local" # Nope. include "/home/$USER/.XCompose-local" # Nnnope. ...I think that's all I had before I punted and used the full path.
So basically my thinking is that there would be a Makefile whose default task did a git pull then runs a modified version of the current install script which fills in that blank using $HOME.
vim digraphs
Last week I goofed around munging the output of vim's :digraph and came up with this: http://panoptic.com/rking/doc/vim-digraphs-full-oneline.txt
It would take about 3 minutes to convert that to XCompose lines. If you're up for it, I'd love to figure out a way to include it into this repo with some kind of opt-in/opt-out.
Design Philosophy?
I can see from the comments that you put a good bit of thought into what bindings get what codepoints. There is definitely some tension between providing guessable shortcuts vs. locking yourself into supporting a binding that you wish you used a different way.
That's why the overlays helps. You can make the stock .XCompose have the one's you're most sure about. For example,
include "/home/rking/.XCompose-even_more"
...then you could throw in such synonym mappings, with the caveat that they are less guaranteed in the future than the ones in the main .XCompose.
...what do you think? -☈
On 05/06/2012 01:44 AM, rking wrote:
The Fever
So, I only discovered XCompose recently, and I found it exciting. Then, stumbling upon kragen/xcompose was double-exciting, but almost instantly I want to find myself triple-excited. This is a very rapid onset of addiction. I'm basically the guy described here: http://youtu.be/8r1CZTLk-Gk
Thanks; I'd seen part of that clip before (about "you had to sit on the runway for 40 minutes... and what happened next, didn't you FLY!?") but didn't have a link to it. (see also http://whitewhine.com/ ; they're starting to call these "first-world problems." Oh, man, the local Starbucks was closed and I had to walk four blocks out of my way to get to another one...)
Believe me, I understand addictions of this sort really intimately. I get obsessed with things from time to time, obsessions lasting anywhere from half an hour to half a year. By the time they subside I've learned a hell of a lot about whatever it was. By now I've been obsessed with a whole lot of things.
Proposed Solution
You can't talk about a solution until you've mentioned a problem...
Basically, I think the project needs some overlays. We already have /usr/share/X11/locale/en_US.UTF-8/Compose as a base layer, with ~/.XCompose stacking on top of it. But, in my opinion, there should be more user preferences that go on top of that.
What do you mean by overlays? You mean, split the thing up into smaller parts so you can decide just which to include? Might be good just for organization's sake; everything's all mixed together in the file; you can't find where things are and where new things should go.
(I'm also pondering if I shouldn't revamp a lot of the sequences. Maybe instead of worrying about a special prefix (double-multi-key) I should have an ending character, so I wouldn't have to fret about sequences being prefixes of each other. Also look more at some of TeX/LaTeX keywords)
Anyway. That's what you mean, then, breaking the file up more?
Implementation?
I modified my kragen/xcompose output to have this:
include "/home/rking/.XCompose-local"
...and it seems to work cleanly for the case where it's absent (e.g., I couldn't find any error messages) and it does use those mappings when it is present.
The downside is that I couldn't figure out a way to get rid of the hard-coded username. I tried:
include ".XCompose-local" # only works for programs started in ~ include "~/.XCompose-local" # Nope. include "$HOME/.XCompose-local" # Nope. include "/home/$USER/.XCompose-local" # Nnnope. ...I think that's all I had before I punted and used the full path.
So basically my thinking is that there would be a Makefile whose default task did a
git pullthen runs a modified version of the currentinstallscript which fills in that blank using $HOME.
You don't need that. Look at man XCompose. On my machine, it describes how you can use %H for the home directory, %S and %L to access the various system locale XComposes.
vim digraphs
Last week I goofed around munging the output of vim's :digraph and came up with this: http://panoptic.com/rking/doc/vim-digraphs-full-oneline.txt
It would take about 3 minutes to convert that to XCompose lines. If you're up for it, I'd love to figure out a way to include it into this repo with some kind of opt-in/opt-out. I could probably write a script to convert that, yeah. There already is the opt-out of just not putting it in your file. You can use the various includes that you talk about above to decide whether or not to include this one. I sort of already have that with the frakturcompose file.
Design Philosophy?
I can see from the comments that you put a good bit of thought into what bindings get what codepoints. There is definitely some tension between providing guessable shortcuts vs. locking yourself into supporting a binding that you wish you used a different way.
That's why the overlays helps. You can make the stock .XCompose have the one's you're most sure about. For example,
should indubitably be →. But what about ←? Currently it is , which makes some sense, but I imagine I'm not the only one who looked for instead. If you had another line that did: include "/home/rking/.XCompose-even_more"
...then you could throw in such synonym mappings, with the caveat that they are less guaranteed in the future than the ones in the main .XCompose. Mm. So basically reorganize into smaller pieces, with potentially alternate mappings?
The idea is okay as an idea, but it needs to be seen as an example I think. What actually we would do. Right now it's too nebulous.
~mark
I reorganized everything a bit (see Pull Request).
Not sure what you'll think of it, actually.
But I ♥ it.
The next steps are the details. I'd like to shatter the default/kragen file into chunks, some going in default/ and others going in maybe/.
I need to give some serious TLC to the vim file — some things are working and others are not. Part of it is because I didn't do much substitution to make the
Which brings me to another thing - I plan on adding make targets for your excellent python utils. My thinking is that ./configure would emit a second file that has a simple list of the XCompose files selected, then you could run "make scan4dups" to use that list as the input to utils/scan4dups.py.
Anyhow, nothing is set in stone, no feelings would be hurt if you wanted to revamp in some ways.
@ryanjosephking http://manpages.ubuntu.com/manpages/trusty/man5/XCompose.5.html that link explains that the common usage to included other files would be:
include "%H/.XCompose-local"
