Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!hplabs!hplabsz!mayer From: mayer@hplabsz.HPL.HP.COM (Niels Mayer) Newsgroups: comp.windows.x Subject: Re: HP text widget Message-ID: <3054@hplabsz.HPL.HP.COM> Date: 9 Mar 89 04:00:25 GMT References: <3032@hplabsz.HPL.HP.COM> <6858@phoenix.Princeton.EDU> <1770@umbc3.UMBC.EDU> Reply-To: mayer@hplabs.hp.com (Niels Mayer) Organization: Hewlett-Packard Labs, Software Technology Lab, Palo Alto, CA. Lines: 43 Summary: Expires: Sender: Followup-To: In article <1770@umbc3.UMBC.EDU> alex@otter.UMBC.EDU (alex) writes: @In article <3032@hplabsz.HPL.HP.COM>, mayer@hplabsz.HPL.HP.COM (Niels Mayer) writes: @> from TextEdit.c status @> --------------- ----------- @> InsertLine can't find it in r3 @> DeleteChar changed to Delete (?) @ @ If you remove InsertLine and change DeleteChar to Delete, the problems @with 'i' and 'd' go away aaaah.. but of course! boy do i feel stupid! @ but that brings up a more intereting question... @ @ What appears to be happening is since the toolkit can't identify @"InsertLine" it matches it to "I" without even a warning. I wouldn't expect @this, especially in light of the fact that it will produce warnings about @multiply decined keys, ie: @ @ I: something()\n\ @ InsertLine: something()\n\ @ @produces a warning about a redefined Key! On the other hand, I shouldn't feel that stupid. I'd consider that behaviour to be a BUG, or at least a MISFEATURE. This should be fixed pronto since translationtables are something that USERS might diddle with -- simply mispelling a symbolic keyname in the translationtable would cause the application to just gobble up whatever random character happened to be at the head of the mispelled name. All that, with no warning. Not exactly USER friendly. While I'm complaining, I also think that the actions carried out by matching on a sequence of keys should be independent of the order in which elements of the translationtable are listed -- can't the translation table compiler figure that out? It's incredibly bogus that I can't just append or prepend an arbitrary keybinding to a txlationtable -- the way things are set up, I have to "always put more specific events in the table before more general ones." (Xt Intrinsics doc, p. 128). This can make modifying an existing translation table a nightmare, especially if that translation table is sitting in somebody elses program in a library. -- Niels.