Re: [COMMIT] Rename the ascii-character property, support more keysyms

 Ar an ceathr=C3=BA l=C3=A1 de m=C3=AD I=C3=BAil, scr=C3=ADobh Stephen J.=
 Turnbull:=20

 > [...] All the query functions, on the other hand, give coordinates
 > relative to an Emacs window.

Hmm, ugly design, as far as I can see. Could probably be worked around wi=
th
loads of judicious hiding of toolbars and menubars--but what was the
rationale for it?

 > [...]
 >     Aidan> The revisions of x-compose.el were a consequence of the
 >     Aidan> removal of x-iso8859-1.el; the removal of x-iso8859-1.el
 >     Aidan> was a consequence of ####=E2=80=99s that said =E2=80=9Cwe s=
hould remove
 >     Aidan> x-iso8859-1.el when we can,=E2=80=9D which is, to me, an
 >     Aidan> indication that such a change should not be controversial.
 >=20
 > It's exactly the opposite.  It's an indication that the prerequisites =
to
 > the recommended change are probably controversial.  This is especially
 > true with Ben and Jamie comments, as neither of them was shy about
 > ripping out code they didn't like if they thought that they had the
 > relevant use cases covered in other ways.

Well, in this case, those comments were written long before XEmacs had
support for non-Latin-1, so I=E2=80=99m pretty sure those use cases are c=
overed by
these changes.=20

 >     Aidan> The problems being unrelated doesn=E2=80=99t make the patch
 >     Aidan> incoherent.
 >=20
 > Of course it does.=20

I still disagree. Trivially, you could criticise my documentation and my
function names in a ten line patch, and there we would have unrelated
problems in a presumably coherent patch.=20

 > It means that the reviewer either has to split the patch to review par=
t
 > of it, or make sufficient time to review the whole thing.  Go review t=
he
 > Wing vs. the World threads in the xemacs-review archives.

I=E2=80=99ve read plenty of Wing vs. world threads, and patches, and this=
 patch was,
in my judgement, an order of magnitude less scattered.=20

 > You are free to commit whatever you like to a branch, and request
 > testing of that branch, etc.=20

And people are free not to test the branch, just as they are free not to
test patches when I explicitly request that before committing.

 > If you want stuff in the mainline, though, it needs to pass review.  I=
f
 > you want it in quickly, it needs to pass review quickly.  To get that,
 > you need to get people to review, which means making it convenient for
 > them to review.  The combination of the jit binding patch, the
 > ascii-character patch, and the x-compose patch probably cost you a
 > month's delay from me for the ascii-character patch and a couple of we=
eks
 > on the jit binding patch, and I still haven't gotten to actually
 > _testing_ them.

And who says that if I had split it it would have been any faster?=20

 >     Aidan> W.r.t. Adrian=E2=80=99s breakage, I asked, twice, for testi=
ng of
 >     Aidan> that change from Windows users before it was committed,
 >     Aidan> with no response. I don=E2=80=99t see how I could have done=
 that
 >     Aidan> differently without installing VMWare and paying our
 >     Aidan> friends in Redmond whatever it is that Visual C++ costs
 >     Aidan> these days.
 >=20
 > My recommendation is trivial: don't commit patches you can't test on
 > some common platforms and don't have excellent understanding of how
 > the mechanism works on some of the affected platforms.  That requires
 > less effort on your part than any other way.  :-)  Choose stuff that
 > all the active reviewers can review.  There's plenty of work to be
 > done on Lisp code, which is platform-independent or buggy by
 > definition.  "Unicode Inside" should be mostly platform-independent.
 >=20
 > If keyboard work is really that important to you, there are a number
 > of possibilities.  I'm sure the SourceForge compile farm has Windows
 > boxes to at least ensure it builds. =20

Nope.=20

 > You must have friends with Windows boxes you could borrow for testing.

Most of my friends in this part of the world are humanities folk, and I
don=E2=80=99t know anyone with Visual C++. On the plus side, I haven=E2=80=
=99t had to argue
with wide-eyed unconditional opponents of software patents in months, tha=
nks
be to Sweevo, the God of Cut Timber.=20

 > I have boxes out the wazoo (due to insane budget policies in my
 > institution), I could sacrifice one to Windows testing, the constraint
 > being my time, which will start to be available in reasonable chunks i=
n
 > about 10 days.  You could write directly to Adrian for testing,
 > explaining that this is a pet project but you feel unable to commit
 > without a test report.  You could write Ben Wing and Andy Piper
 > personally for coding advice.  Ben is very likely to give a useful
 > response even if he seems to be ignoring the lists entirely.  Andy is
 > less so due to work pressure, but he's not been entirely absent so I'm
 > sure he'd take one inquiry in good spirit, and let you know on what te=
rms
 > he's (un)available if it's inconvenient for him now.

So, if the mailing lists are doing their job, all these are equivalent to=
 a
an open-ended request on them, no?

 >     >> Uh, what's the hurry?
 >=20
 >     Aidan> The faster the process for one change is, the more time
 >     Aidan> there is for other changes. I don=E2=80=99t see anything
 >     Aidan> controversial about that--XEmacs is unfortunately not at
 >     Aidan> the point of asymptotically approaching perfection, such
 >     Aidan> that there is a small number of things left to do :-( .
 >=20
 > Exactly.  With so many things to do, why did you choose to do this?

I was doing lots of things; I implemented this in a break from swearing a=
t
my unicode-internally code for getting alignment wrong when inserting int=
o a
buffer.

 > With the need for speed, why did you combine three things that you
 > should have known in advance I was going to resist individually into a
 > single patch, pretty much ensuring that the whole thing would get
 > vetoed?

Why should I have known that in advance? I mean, I understand and accept
your objections to renaming ascii-character in the way I did now, but I a=
m
still, several mails later, having trouble appreciating your trepidation =
at
the other changes. I don=E2=80=99t read minds any more than anyone else.=20

 >     >> It's a reference to Meta-handling, and there's no question that
 >     >> it can screw up ASCII users to the extent that they do use
 >     >> 8-bit-is-meta.
 >=20
 >     Aidan> I didn=E2=80=99t change any meta handling--I only removed t=
he
 >     Aidan> MAP-DEVICE-KEY-NAMES argument, which has a tenuous
 >     Aidan> relationship to meta handling.
 >=20
 > According to the documentation of `set-input-mode', high-bit handling
 > is a three-state switch: ignore the high bit, interpret the high bit
 > as meta, interpret the high bit as C1/GR.  The underlying function
 > used to have two booleans (for this purpose) with the "both-set" state
 > disallowed, it now has one, and therefore something has changed.  Is
 > that not true?

It=E2=80=99s not true; the behaviour of set-input-mode is exactly as it w=
as before.

 > Now, now.  :-)  They're not glaciated; there's plenty of work being
 > done on the emacs-unicode2 branch it would seem, not to mention
 > various people's private branches.  I'll grant that I did it very
 > differently (rather than freeze for a year, I released as "gamma", a
 > formalization of "point zero releases always suck"), but the practical
 > result isn't all that different---except that as usual the released
 > GNU Emacs will be better documented and more robust than any XEmacs
 > since before it was called XEmacs, and there may be a few *nix distros
 > left that distribute 21.4a rather than 22.0-pre.

Labels matter, and stability is easy to do when you have their lack of
energy with regard to incorporating new features. Their multi-tty support
has been stable for months, for example, and there=E2=80=99s not a whispe=
r of it
being integrated.=20

 > As for the comment-face silliness, he's waiting for the documentation
 > kind of stuff to get done, and like everybody in this business, he
 > can't resist jumping into a flamewar over trivialities.  BFD.

I don=E2=80=99t think that it=E2=80=99s a big deal, just an indication of=
 bad
judgement. Ditto with his reaction to Stefan Monnier=E2=80=99s fatherhood=
,
cf. http://edward.oconnor.cx/2005/04.shtml for details.=20

 > I think that current policy at GNU Emacs is a recipe for permanently
 > making GNU Emacs as irrelevant as XEmacs has become to the vast
 > majority of developers, but "That's Just My Opinion---I Could Be
 > Wrong."[1]  Even if that's your opinion, too.  :-)  30-some active GNU
 > Emacs developers support RMS in doing this, even if they disagree on a
 > specific here or there; that's about as big a vote of confidence as
 > any Emacs maintainer can get, no?

Hey, the Catholic Church counts a billion believers--that doesn=E2=80=99t=
 make its
stance on contraception right. Or even arguable.=20

 >     >> What XEmacs has over GNU Emacs is a modern design (so to
 >     >> speak), but except for purely technical improvements (the
 >     >> dumper, the MINIMAL_TAGBITS stuff, etc), the important ones go
 >     >> back to Jamie's.  Some of Ben's stuff is really interesting
 >     >> (specifiers, lstreams, etc), but for whatever reason Ben's APIs
 >     >> seem to be an impediment to new developers, unlike the Lucid
 >     >> event loop, extents, creation of various abstract data types,
 >     >> etc.
 >=20
 >     Aidan> Did Jamie=E2=80=99s changes ship with nice sample uses of t=
he APIs?
 >=20
 > Yes, one.  It was called "Lucid Emacs".  This isn't entirely
 > facetious; the Lucid folks (not just Jamie) generally didn't design
 > huge APIs without having applications for them, whereas that's an MO
 > that immediately fingers Ben as the culprit.

Ah, okay, that does make sense.=20

 >     Aidan> Because, for example, I ended up reading code to work out
 >=20
 > You could have asked me; I use that feature all the time.  :-)

If I asked questions about every tiny detail I was having trouble
understanding, the traffic in comp.emacs.xemacs would be 90% my unanswere=
d
questions, I suspect. :-) .

 >     Aidan> that you could pass an actual buffer object as the LOCALE
 >     Aidan> argument to set-specifier
 >=20
 > Did you submit a document patch?  :-)  Note that this is one of Ben's
 > APIs, which are notorious for their unreadability and unreadable
 > documentation (and not just according to David Kastrup; David's
 > reports have provoked hundreds of lines of doc patches from developers
 > who at least sympathize with him even while they say they understood
 > it the first time ;-).

I need to look into where to put it; in some sort of general introduction=
 to
Ben=E2=80=99s APIs, if such a thing exists.=20

 > [...] BTW, it's actually a sarcastic reference to the historical pract=
ice in
 > Mule of favoring Japanese.  The irony of finding myself doing it, too,
 > because I was chasing other bugs at the time, well....  That comment
 > embarrasses me every time I see it, and one of these days I'll lose
 > patience with it and fix the underlying problem.

So you put off integrating the Xft patch for however many months because =
of
its crappy internationalisation support, and then went and integrated it
yourself, with crappy internationalisation support?

 > In general, the big problem with Mule is that most of the app and UI
 > coders have ignored it entirely, and the Mule coders (mostly Japanese
 > or ISO 8859-1 users) have set up the defaults so that Japanese support
 > is excellent out of the box.  Thus a lot of UIs and high level APIs
 > that should be there (eg for non-Latin fonts) just aren't.
 >
 >     >> Not even close.  If you know that your environment will have
 >     >> only one unibyte encoding in it that you care about ever,
 >     >> no-Mule XEmacs plus setting the font resource is all you need.
 >=20
 >     Aidan> Who knows that? Even Jamie Zawinski, bless his resolutely
 >     Aidan> ASCII-centric heart, has had our broken support for decent
 >     Aidan> typography bite him in the arse.
 >=20
 > We have no support for typography at all, what _are_ you talking
 > about?  Please don't confuse support for your favorite glyphs with
 > support for typography.

http://list-archive.xemacs.org/xemacs-beta/200408/msg00151.html=20

Sorry, =E2=80=9Ctypographical glyphs.=E2=80=9D

 > Anyway, people who only use XEmacs for program development can be
 > pretty sure they'll only see their favorite 8-bit codes.

No they can=E2=80=99t. They will eventually copy and paste something from=
 a mail of
mine, or someone=E2=80=99s blog, and end up with crap in the buffer.=20

 >     Aidan> Europeans tend to have much more interaction with other
 >     Aidan> European countries and their languages than do the Japanese
 >     Aidan> with other East Asian countries and their languages; I
 >     Aidan> think if we prevented people in German language
 >     Aidan> environments from typing =C3=B1, the result would complaint=
s
 >     Aidan> from people who use that functionality--from Uwe Brauer,
 >     Aidan> anyway, and from me, though I have been putting off signing
 >     Aidan> up for Spanish class--and oblivousness from everyone else.
 >=20
 > C'mon, stop trying to score easy debating points and start thinking
 > about the issues.  If there are only 96 GR characters available, we
 > can't support (eg) both Russian and German with the same unibyte coded
 > character set, at least not if we stick to the usual standards.

The editor (I=E2=80=99m not saying =E2=80=9Cwe=E2=80=9D because I=E2=80=99=
ll be shouting =E2=80=9Cuse Mule!=E2=80=9D
whenever anyone suggests such a thing) can support them with different fo=
nts
in different buffers, if they want to go in that direction.=20

 > Clearly we want to help users to avoid inadvertantly entering a bunch
 > of Cyrillic characters which will be mixed with Latin-1, ensuring that
 > one or the other is unreadable in plain text.

Well, they will get immediate feedback when what they=E2=80=99ve typed do=
esn=E2=80=99t
appear as such in the buffer, and if they are serious about trying to han=
dle
Mule in non-Mule, they can separate out the characters into distinct
buffers, changing the fonts in those buffers to have the appropriate char=
set
registry.=20

 > Similarly, some users might wish to be warned (or even prevented) from
 > entering Latin-1 characters not used by their current language, althou=
gh
 > I grant that's probably a stretch.

To me, it=E2=80=99s almost inconceivable.=20

 > How that UI gets set up (which is what would generate complaints) is a
 > completely different issue.  My point is that the existing API
 > provides a single set of objects (the pseudo-keysyms) that can be
 > tested for such a situation, while the approach you implemented does
 > not, since by the time the keystroke has been converted to something
 > that Lisp can handle it's already a character.
 >
 > Of course, based on my limited current knowledge, it's possible that
 > the pseudo-keysyms are never actually exposed to Lisp, and it's
 > possible, even likely, that the whole issue is moot in practice, as
 > most such users will convert to Mule.  If so, again, what's the hurry?

There=E2=80=99s also the option of doing this by wrapping self-insert-com=
mand; the
keysym will be available to Lisp from there.=20

 >     >> I think it's worth thinking about whether it's true and whether
 >     >> it matters before doing it, rather than trying it, having you
 >     >> go on permanent sabbatical, and then having the bugs show up.
 >     >> That happened altogether too often in the run-up to releasing
 >     >> 21.4.
 >=20
 >     Aidan> I think your general point is right there, but in this
 >     Aidan> specific case it=E2=80=99s not that warrented.
 >=20
 > Yeah, and all of everybody's commits are specific cases where it's not
 > warranted.  Otherwise they wouldn't have committed.  Ie, this kind of
 > principle has to applied as the general case, then you get this kind
 > of discussion in specific cases.

I meant this specific use case doesn=E2=80=99t warrant that thinking.=20

 > [...]
 >
 >     >> Don't know how many of the [ASCII-only bit-8-is-meta users]
 >     >> there are, but shouldn't the [number of Europeans et al who
 >     >> want GR entry] be "zero" because they'd have "bit-8-is-meta"
 >     >> off in the first place?
 >=20
 >     Aidan> You mean in the TTY?
 >=20
 > No, in XEmacs.  If they're stuck with a TTY that doesn't support GR
 > entry as such but does display GR glyphs, they've probably learned to
 > use the Meta map as a way to enter GR glyphs in 8-bit clean apps, I
 > would think.

M-x for oslash is the least intuitive thing in the world. Back when I was
using non-Mule, I bound a key to iso-accents-mode and accepted that I
wouldn=E2=80=99t be able to paste. Or is that even what you=E2=80=99re ta=
lking about?

 >     >> It's a symbol, for heaven's sake; that string could be used
 >     >> anywhere, and if it's used in a context where the contents are
 >     >> expected to be HPC because it's known to be a keysym name, it's
 >     >> unsafe.  What makes you think there are no such places?
 >=20
 >     Aidan> For example, because we munge the keysym names in the
 >     Aidan> platform specific code, mapping dead_diaeresis to
 >     Aidan> dead-diaeresis,
 >=20
 > That is bizarre.  From your previous comments I gather you didn't find
 > any rationale for it?  Just because hyphens look more Lisp-y?

Exactly.=20

 > However, it should be invertible, since hyphens are interpreted as
 > subtraction in C, and can't be part of identifiers.  No?=20

We munge some hyphens, we don=E2=80=99t munge others. But yeah, it is pro=
bably
invertible. Probably.=20

 > Do we munge any other characters?  (BTW, X11 is so weird; elsewhere in
 > that file, "diaeresis" is spelled "dieresis", and there's even a #defi=
ne
 > XK_Greek_IOTAdiaeresis XK_Greek_IOTAdieresis allegedly
 > backward-compatible with an old typo....)

English could really do with a standard orthography ...

 >     Aidan> so any future lookup in the X11 code is
 >     Aidan> guaranteed to give something nonsensical for some fraction
 >     Aidan> of its input. x-valid-keysym-name-p is already open to
 >     Aidan> being buggy in this direction, and I=E2=80=99m not aware of=
 any
 >     Aidan> open bug reports involving it.
 >=20
 > "Two wrongs make a right"?

=E2=80=9CTwo irrelevancies remain irrelevant,=E2=80=9D is closer to my fe=
eling on it ...

 >     Aidan> There is one place, in console-x.c, and I just introduced
 >     Aidan> it. Looks like I=E2=80=99ll be using the Qhpc #define in mo=
re than
 >     Aidan> one place, whee.
 >=20
 > Nobody said that working on XEmacs wouldn't be "work".  :-P

Nobody said there=E2=80=99d be much more English than code, either ...

--=20
=E2=80=9CI, for instance, am gung-ho about open source because my family =
is being
held hostage in Rob Malda=E2=80=99s basement. But who fact-checks me, or =
Enderle,
when we say something in public? No-one!=E2=80=9D -- Danny O=E2=80=99Brie=
n