The Compose tables currently allow to put a breve on a letter by using the capital U (for example <Multi_key> <U> <a>). This is fine for putting a breve on an uppercase letter, where one has to press <Shift> anyway, but it is awkward to have to press <Shift> when wanting to add it to a lowercase letter. (Also, to me a breve looks more like a small u than a big U; intuitively I was trying to use <Multi_key> <u> <a>, and had to look in the Compose tables to find that I needed to use Shift+U.) So, the first attached patch adds the "<Multi_key> <u> ..." sequences for the relevant letters. The second patch adds the sequences with the plain <breve> key for <Abreve>, similar to the ones that already exist for <Gbreve>; the latter come from iso8859-3 and iso8859-9, the first from iso8859-2. The third patch fixes a mistaken comment.
Created attachment 72955 [details] [review] allow use of lowercase <u> to compose breve
Created attachment 72956 [details] [review] add sequences with <breve> for Ă and ă
Created attachment 72957 [details] [review] fix comment for quotation mark
Appologies for the delay in getting to this. We already have miniscule <b> for breve in the compose table, so I am reluctant also to add <u>. I will push the other two patches, though.
Created attachment 85108 [details] [review] adds lowercase u sequences for frequent Romanian a with breve I understand your reluctance to add a third way (and for some letters a fourth or fifth way) to put a breve on a letter. But, you see, <Multi_key> <u> <u> already exists, and I have used it to type ŭ (a regular letter in Esperanto). And then one day I needed to type ă (a frequent letter in Romanian) and was surprised and chagrined that <Multi_key> <u> <a> didn't work, nor <Multi_key> <a> <u>. It did not occur to me to try <b> or <U> or <parenleft> -- I had to look in the Compose tables to find that out. Why does the exception <Multi_key> <u> <u> exist? Presumably because it is awkward to type <U> <u>. But it is also (almost as) awkward to type <U> <a>. (Why was <U> chosen instead of <u> to put a breve on a letter, anyhow? I think it was a mistake -- to put a ring above a, A, U or u, <o> is used, not <O>...) So, I request that at least the sequence <Multi_key> <u> <a> be added, to be able to comfortably compose a frequent letter in a much-used European script, a letter which does not occur anywhere on (nor in the hyperlevels of) (almost) any keyboard outside of Romania. I don't care about ĕ and ĭ and ŏ, which mostly only occur in Latin. And ğ... already has too many ways. Attached patch adds the <u> <a> sequence, but also <u> <A> and <u> <U>, which are not strictly necessary but make the thing more consistent.
Created attachment 85144 [details] [review] adds sequences with <parenleft> first for A and G In GTK it is possible to compose ă, Ă, ğ and Ğ with either <parenleft> before or after the letter. But in the current X compose tables only the postfix forms are present. The patch brings Xorg in line with GTK. (I won't propose to add these sequences also for other letters, for now I just wish to see symmetry, adding the more usual forms with diacritic first.)
Created attachment 85145 [details] [review] orders some sequences more rigorously The patch puts sequences with two keys reversed in pairs, just like all other reversed couples are paired. (It is unrelated to breves, but I'm too lazy to open a new bug.) By the way, what to think of this: <Multi_key> <grave> <space> : "`" grave # GRAVE ACCENT <Multi_key> <space> <grave> : "`" grave # GRAVE ACCENT If one has a <grave> key..., why on Earth would one want to compose it? (The same for <Multi_key> <asciitilde> <space> and brother.)
(In reply to comment #5) > Why does the exception <Multi_key> <u> <u> exist? Ehm... I've looked at the history, and... it appears that this sequence was sneaked in seven years ago by... myself. (grin)
What's the status on this, James? Nobody on xorg-devel seems to object to the <Multi_key> <u> ... additions, so what's holding this up?
(In reply to comment #4) > I will push the other two patches, though. Ping?
Looks like I lost track of this report. I remember the early comments, but not the ones after mine. I’ll try to look closer tonight.
The three patches from 09-03 are pushed as: bda0b3b5bd19154206dc40166364e73d4b6b1374 f020235f4bd91fb6eade82f8c9f7b85a57981768 ca435c2f753aa2961fb35ac448cdb2cc77112755
Thanks! There are some other patches I would like to see merged. The one on bug #69103, for example. Is it okay if I put you in the CC field of the ones that I would like you to have a look at?
> Is it okay if I put you in the CC field of the ones that I would like > you to have a look at? Yes!
I had to revert attachment #85144 [details] [review]. <parenleft> <[a-z]> <parenright> sequences exist for circled letters, such as ⓖ and Ⓐ. Gtk+ also has them for letters other than ⓐⒶⓖⒼ; I don’t know why they allowed the clashing sequences for ăĂğĞ. Please run: ./autogen.sh;make;make check to confirm that any proposed Compose sequences are clash-free. Thanks.
(In reply to comment #15) > Please run: > > ./autogen.sh;make;make check > > to confirm that any proposed Compose sequences are clash-free. My system is apparently too old for running ./autogen.sh: configure.ac:25: error: xorg-macros version 1.15 or higher is required but 1.5.0 found But it is compiling now in chroot on a newer distro... It takes ages on my little Atom.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.