> > wprintf( "La\u0301aa"). I noticed this some years back and assumed it was
> > supposed to be that way: the combining character modifies the preceding
> > character. A bit of Web searching suggests that's the way it's supposed to
> > work; to get á, you emit a and then \u0301, not \u0301 and then a.
> >
> > Seen from that angle, Roman's program is working correctly;
> >
> > move(0, 1); add_wch(&ccmod);
> >
> > says "add an accent to the character just to the left of (0, 1)."
> > However, I have to admit that the man page description, I think, supports
> > Roman's expected behavior.
I think we're talking about this paragraph:
• If wch refers to a non-spacing character, all previous characters
at that location are preserved. The non-spacing characters of wch
are added to the spacing complex character, and the rendition spec‐
ified by wch is ignored.
After the first add_wch, the current position is _after_ that character,
but the position for the purpose of combining is _that_ character.
So... a move to the cell after the spacing character can combine with it.
At least, that's how I'm reading it today. An example in the manpage would
probably help a lot :-)
There's discrepancy in the topmost sentence in add_wch(3x) too: "The ... functions put the complex character wch ... at its current position". That's only true when wch is spacing. Then later: "If wch refers to a non-spacing character, all previous characters at that location are preserved. The non-spacing characters of wch are added to the spacing complex character". Here the first part implies that we're working on the complex char at the current position, which is not true.
In the C string "a\u0301" it's impossible to place the accent to the same string item as the 'a', so there needs to be a convention of a shift when outputting the modifier. Ncurses, however, records for each set of coords the base char + all its modifiers. That makes it unnecessary to make exceptions and move() + add() can do just that, no shift. It's even more striking when you put it as mvadd_wch(y, x, &cc). This might and might not operate on (y, x), and that's unorthodox. It stands out when you start doing other char ops than simply writing out a string from beginning to end.
At this point the API's set fairly firmly, I suppose. But notice that as far as ncurses string ops (not char ops) are concerned, add_wch() can work in either way and nothing needs to change on the syntax of the C strings that are passed to those string ops. It's just a matter of their implementaion.
-rz