6:35 p.m.
Are there any views on the future of Quail in XEmacs?
I've been going back to the problem of getting Quail working properly
in isearch. I'm almost there, but it is, if you'll excuse my French, a
total bloody nightmare. isearch-mode is a twisty self-connecting maze,
and so is Quail, so the combination is a 4D twisty multiply
self-connecting maze with singularities of of hideous complexity.
(The fact that XEmacs has three different definitions of what the
minibuffer is, doesn't help, and caused me much grief until I
understood it. And since they play fast and loose with events and
buffers, the Lisp debugger was pretty much useless.)
In FSFmacs, it works much more neatly, because there are a couple more
hooks into Quail. It also looks neater, because of a couple more
variables which were left out in XEmacs.
I have to change Quail anyway even to get my stuff working, so if I
were to bring in a few of the FSF changes, would you accept it into
the standard packages, along with an updated isearch-mode ?
(I usually work from the 21.4 codebase, but I guess there's no reason
why the mods in the 21.5 isearch-mode.el shouldn't go back into 21.4
too, if there's ever another release.)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
11:29 p.m.
Ar an ceathrú lá déag de mí Feabhra, scríobh Julian Bradfield:
[...] I have to change Quail anyway even to get my stuff working, so
if I
were to bring in a few of the FSF changes, would you accept it into the
standard packages, along with an updated isearch-mode ?
I’d accept it, and be happy to commit it.
(I usually work from the 21.4 codebase, but I guess there's no
reason
why the mods in the 21.5 isearch-mode.el shouldn't go back into 21.4
too, if there's ever another release.)
--
“Apart from the nine-banded armadillo, man is the only natural host of
Mycobacterium leprae, although it can be grown in the footpads of mice.”
-- Kumar & Clark, Clinical Medicine, summarising improbable leprosy research
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
10:23 p.m.
On 2011-02-14, Julian Bradfield <jcb+xeb(a)xemacs.org> wrote:
I have to change Quail anyway even to get my stuff working, so if I
were to bring in a few of the FSF changes, would you accept it into
the standard packages, along with an updated isearch-mode ?
Hm. On looking into a bit further, FSF have extended the architecture
so that their read_char() calls the input method directly - it is
expected to take the event, read any more events that it needs, and
return a list of translated events.
The equivalent in XEmacs would be for Fnext_event() to call the current
input method on a command event (or just keypress events?), in order
to get translated events.
On the face of it, this looks like a good idea, because it puts the
input method where it logically belongs, instead of hacking it in via
a mess of keymap munging - indeed, the quail minor mode goes away
entirely.
Of course, adopting this would be quite a major change, and the quail
package would have to have both old and new versions, loading the
appropriate one for the XEmacs it was invoked by.
I feel this is probably the Right Thing, but it may be too big a
thing.
Thoughts?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
2:07 a.m.
Julian Bradfield writes:
The equivalent in XEmacs would be for Fnext_event() to call the
current
input method on a command event (or just keypress events?), in order
to get translated events.
I think to be compatible with XIM (which AFAIK is still the API for
input methods in X) it would need to be at the keypress level. It
might even need
I feel this is probably the Right Thing, but it may be too big a
thing.
Vin is the final authority on 21.4, but I would advise him not to
merge such code to 21.4 until it has been stabilized in 21.5, and
probably not even then. Probably even in 21.5 it should be done on a
branch, but I would have no objection to supporting that branch (eg,
by publishing it as a sibling to the "xemacs" branch on alioth) and
presuming that it would get merged in a timely fashion when a
*reasonable* level of functionality and stability is achieved.
However, I can't speak for others. Mike in particular seems to be in
a hurry to make a public release, and if so this would have to be
merged after such a release.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4247
days inactive
4250
days old
3 comments
4 participants
participants (4)
-
Aidan Kehoe -
Julian Bradfield -
Julian Bradfield -
Stephen J. Turnbull