Systematizifcationizing? about xcompose HOT 3 OPEN

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 pull then runs a modified version of the current install script 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

from xcompose.

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 right. Something else is afoot, though. I'm not sure why 2S works but 2s doesn't. I'm thinking there's a conflict with another key.

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.

from xcompose.

@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"

from xcompose.