Re: filename completion with umlauts (again)

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Jan 8, 11:21pm, Peter Stephenson wrote:
}
} > What is it that I continue to fail to see?
} 
} See any number of while loops over character arrays in compmatch.c; as
} one example, the loop at line 529 in match_str().  The various arrays
} are simply char *'s and they're not even metafied

Ah, so working my way up from the bottom I still haven't climbed far
enough out of the pit.  The stuff that performs comparisons is mostly
MB-ified, but the code that chooses what needs to be compared is not.

} If you *can* prove it's trivial, of course...

Never intended a pretense of *that* claim ... just trying to get on
record what it is that needs looking at.

If we climb even further out of the hole we've dug, then it appears
that for example match_str() is called on [a copy of] the comppprefix
global variable, which, along with the compsuffix et al., is happily
marched around with pointer arithmetic all over the completion code,
not just in compmatch.c.

Furthermore there are a bunch of globals declared in compmatch.c that
keep track of various edits (for lack of a better description) that
need to be applied to the command line to cause it to reflect various
possible outcomes of completion.  This includes stuff like "oh by the
way I changed all your ~ into x to hide them from tilde expansion, you
need to put them back again."

Would it even be sufficient to metafy around the match_str() entry
point, or is the real problem that the *entire* completion system
needs to stop treating the input line as a (char *)?

In which case we almost may as well start over from scratch.