5:45 a.m.
Ar an ceathrú lá is fiche de mí na Nollaig, scríobh mike.kupfer(a)xemacs.org:
(moved to xemacs-beta)
Hi Aidan, I've got a couple questions about the gnus patch.
First, I'm nervous about XEmacs-specific patches that I would have to
apply every time I resync with upstream.
Yeah; I need to ask the Gnus people to apply it too. But for the moment I’m
worried about XEmacs-specific compatibility.
Is there some difference between XEmacs char-tables and GNU Emacs
char-tables that keeps us from using aref/aset?
Yes. The XEmacs char tables are opaque objects, not vectors.
Okay, and now I check, I realise my “portable” code fails on GNU
Emacs. Here’s a version that works there, where char-tables are sequences
and really close to being vectors, though not quite:
(defun-when-void put-display-table (range value display-table)
"Set the value for char RANGE to VALUE in DISPLAY-TABLE. "
(if (sequencep display-table)
(aset display-table range value)
(put-char-table range value display-table)))
(defun-when-void get-display-table (character display-table)
"Find value for CHARACTER in DISPLAY-TABLE. "
(if (sequencep display-table)
(aref display-table character)
(get-char-table character display-table)))
The GNU Emacs Info page for display tables says
A display table is actually a char-table (*note Char-Tables::)
with `display-table' as its subtype.
and it uses aset in its example.
Failing that, have you discussed this change with the gnus team
(ding(a)gnus.org)? Or is there at least some canonical way to tag
XEmacs-specific changes, to make resyncs easier?
Second, you appear to be introducing multiple copies of
put-display-table and get-display-table, both in this patch set and in
the patches you committed to xemacs-base and misc-games. Shouldn't
there be just one copy in the packages tree, presumably in xemacs-base?
disp-table.el, which provides the display table code--make-display-table,
frob-display-table, describe-display-table, and in
http://mid.gmane.org/18288.1954.87217.762309＠parhasard.net ,
put-display-table and get-display-table--is in core. Yeah, there’s a decent
argument that it might be better in packages, but it isn’t there for the
moment. There isn’t any other obvious place to put these two functions, IMO,
and moving them away from #'make-display-table and #'describe-display-table
will make for less clear code.
The defun-when-void means any existing definition won’t be overridden.
--
¿Dónde estará ahora mi sobrino Yoghurtu Nghé, que tuvo que huir
precipitadamente de la aldea por culpa de la escasez de rinocerontes?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
7:48 p.m.
New subject: [SPAM] Re: [PATCH] Abstract out a display-table-specific API (2)
Aidan Kehoe writes:
Ar an ceathrú lá is fiche de mí na Nollaig, scríobh
mike.kupfer(a)xemacs.org:
> First, I'm nervous about XEmacs-specific patches that I
would have to
> apply every time I resync with upstream.
Yeah; I need to ask the Gnus people to apply it too.
That's the best solution, but IIRC Gnus currently aims at supporting
Emacs 21, 22, and 23, as well as multiple XEmacsen---spanning about
four different redisplay mechanisms. Expect difficulties in getting
it right. :-(
Mike, although CVS has a lot of problems, its merge capabilities are
not much worse than any other system (in principle, anyway, assuming
you don't interact with a CVS bug). For this kind of thing, you
shouldn't have to actually worry about the merge very often---CVS will
take care of it. The simplest thing to do is make a "vendor branch"
which does nothing but track upstream's releases, then merge that into
the XEmacs CVS mainline.
However, my advice would be to keep a private Mercurial (or other
modern system) repository. I know from tracking emacs-devel
discussions that Emacs Gnus (not to be confused with larsi Gnus,
unfortunately) is moving a lot of libraries traditionally provided by
Gnus into other parts of Emacs. We've done the same but I'm pretty
sure that the Emacs guys are making somewhat different decisions. I
suspect that this may end up being reflected upstream in Gnus itself.
This means that a SCM that can explicitly track file renames may be of
great help. I haven't run into that myself (I've done renames, but
never had any imposed on me) so I hesitate to make recommendations,
but I know that git, Mercurial, and Darcs all have explicit "rename"
commands, and I believe bzr does too.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
8:15 p.m.
New subject: [PATCH] Abstract out a display-table-specific API (2)
Ar an séú lá is fiche de mí na Nollaig, scríobh Stephen J. Turnbull:
Aidan Kehoe writes:
> Ar an ceathrú lá is fiche de mí na Nollaig, scríobh
> mike.kupfer(a)xemacs.org:
> > First, I'm nervous about XEmacs-specific patches that I would have
> > to apply every time I resync with upstream.
>
> Yeah; I need to ask the Gnus people to apply it too.
That's the best solution, but IIRC Gnus currently aims at supporting
Emacs 21, 22, and 23, as well as multiple XEmacsen---spanning about
four different redisplay mechanisms. Expect difficulties in getting
it right. :-(
Hmm? Historically, in both XEmacs and GNU Emacs display tables were vectors.
GNU moved to a fucked non-vector implementation that also gives t to
#'sequencep, and I want to move to a reasonably clean implementation that
uses char tables. Mike’s query should have cleared this up--it hadn’t
occurred to me previously that GNU would want people to pay attention to
(length (make-display-table)) in a non-Mule world, but that’s about as crazy
as things can get, I think.
--
¿Dónde estará ahora mi sobrino Yoghurtu Nghé, que tuvo que huir
precipitadamente de la aldea por culpa de la escasez de rinocerontes?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
9:41 p.m.
New subject: [SPAM] Re: [PATCH] Abstract out a display-table-specific API (2)
Aidan Kehoe writes:
Ar an séú lá is fiche de mí na Nollaig, scríobh Stephen J. Turnbull:
> Aidan Kehoe writes:
>
> > Ar an ceathrú lá is fiche de mí na Nollaig, scríobh
> > mike.kupfer(a)xemacs.org:
>
> > > First, I'm nervous about XEmacs-specific patches that I would have
> > > to apply every time I resync with upstream.
> >
> > Yeah; I need to ask the Gnus people to apply it too.
>
> That's the best solution, but IIRC Gnus currently aims at supporting
> Emacs 21, 22, and 23, as well as multiple XEmacsen---spanning about
> four different redisplay mechanisms. Expect difficulties in getting
> it right. :-(
Hmm? Historically, in both XEmacs and GNU Emacs display tables were vectors.
Sure. Ben moans about that in disp-table.el, does he not?
I want to move to a reasonably clean implementation that uses char
tables.
Which is going to require maintaing two APIs unless you can convince
GNU to go to a char-table-based implementation. As long as things
like `(length display-table)' are available, you can bet that someone
(probably a Gnus developer ;-) will find a use for it. All I mean by
"difficulties" is that this is likely to become one of those recurring
points where you have to pay attention.
Gnus will undoubtedly DTRT (define an internal API that works with
both XEmacs and GNU Emacs), but I doubt that will be universal.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
12:21 p.m.
New subject: [PATCH] Abstract out a display-table-specific API (2)
On Tue, Dec 25 2007, Stephen J. Turnbull wrote:
Aidan Kehoe writes:
> Ar an ceathrú lá is fiche de mí na Nollaig, scríobh mike.kupfer(a)xemacs.org:
> > First, I'm nervous about XEmacs-specific patches that I would have to
> > apply every time I resync with upstream.
>
> Yeah; I need to ask the Gnus people to apply it too.
Please do.
That's the best solution, but IIRC Gnus currently aims at
supporting
Emacs 21, 22, and 23,
Correct.
as well as multiple XEmacsen
XEmacs 21.4 and up.
---spanning about four different redisplay mechanisms. Expect
difficulties in getting it right. :-(
Mike, although CVS has a lot of problems, its merge capabilities are
not much worse than any other system (in principle, anyway, assuming
you don't interact with a CVS bug). For this kind of thing, you
shouldn't have to actually worry about the merge very often---CVS will
take care of it. The simplest thing to do is make a "vendor branch"
which does nothing but track upstream's releases, then merge that into
the XEmacs CVS mainline.
However, my advice would be to keep a private Mercurial (or other
modern system) repository. I know from tracking emacs-devel
discussions that Emacs Gnus (not to be confused with larsi Gnus,
unfortunately)
"Emacs Gnus" (= Gnus in the Emacs trunk) is the same as "larsi Gnus"
(Gnus trunk from cvs.gnus.org), only some files (general purpose libs
not depending on Gnus) have been moved from emacs/lisp/gnus to other
places.
is moving a lot of libraries traditionally provided by Gnus into
other parts of Emacs. We've done the same but I'm pretty sure that
the Emacs guys are making somewhat different decisions. I suspect
that this may end up being reflected upstream in Gnus itself.
There are no plans to reflect that in Gnus CVS. (At least I don't see
a strong benefit.)
This means that a SCM that can explicitly track file renames may be
of
great help. I haven't run into that myself (I've done renames, but
never had any imposed on me) so I hesitate to make recommendations,
but I know that git, Mercurial, and Darcs all have explicit "rename"
commands, and I believe bzr does too.
Miles Bader maintains an arch repository of Gnus (and Emacs) which he
also uses to sync Gnus branches, Gnus and Emacs and various Emacs
branches (see the "arch-tag" in every file).
Bye, Reiner.
--
,,,
(o o)
---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
7 p.m.
New subject: [PATCH] Abstract out a display-table-specific API (2)
Reiner Steib writes:
"Emacs Gnus" (= Gnus in the Emacs trunk) is the same as
"larsi Gnus"
(Gnus trunk from cvs.gnus.org), only some files (general purpose libs
not depending on Gnus) have been moved from emacs/lisp/gnus to other
places.
I seem to recall Richard suggesting moving some functions from one
file to another. Is my memory incorrect? Even if this time the
functions weren't moved, didn't he leave the possibility open for
future cases?
There are no plans to reflect that in Gnus CVS. (At least I
don't see
a strong benefit.)
OK. So we can assume that for the foreseeable future, Gnus
maintainers (upstream to some extent, but defintely downstream) are
going to have to be aware of several different organizations of the
code they maintain. This may have an impact on *our* decision to move
to a modern SCM for our packages.
Miles Bader maintains an arch repository of Gnus (and Emacs) which
he
also uses to sync Gnus branches, Gnus and Emacs and various Emacs
branches (see the "arch-tag" in every file).
I'm aware of that. However, as logical as the UI of Arch sounds when
Tom Lord explains it, it doesn't work out that way in practice. Since
Mike K already knows and likes Mercurial, that will work for us. I
don't really see a big advantage to moving to a Arch-to-Mercurial
workflow either.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
7:37 p.m.
New subject: [PATCH] Abstract out a display-table-specific API (2)
On Wed, Jan 02 2008, Stephen J. Turnbull wrote:
Reiner Steib writes:
> "Emacs Gnus" (= Gnus in the Emacs trunk) is the same as "larsi
Gnus"
> (Gnus trunk from cvs.gnus.org), only some files (general purpose libs
> not depending on Gnus) have been moved from emacs/lisp/gnus to other
> places.
I seem to recall Richard suggesting moving some functions from one
file to another. Is my memory incorrect?
I don't recall that any functions were moved (but I might be wrong).
Even if this time the functions weren't moved, didn't he
leave the
possibility open for future cases?
Yes, but these moves would most probably be synched to Gnus CVS as
well.
> Miles Bader maintains an arch repository of Gnus (and Emacs)
[...]
I'm aware of that. However, as logical as the UI of Arch sounds when
Tom Lord explains it, it doesn't work out that way in practice. Since
Mike K already knows and likes Mercurial, that will work for us. I
don't really see a big advantage to moving to a Arch-to-Mercurial
workflow either.
I just wanted to mention that it exists.
Bye, Reiner.
--
,,,
(o o)
---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
10:35 p.m.
New subject: [PATCH] Abstract out a display-table-specific API (2)
Uwe, can I ask you to look at the thread starting with this message?
http://mid.gmane.org/18288.3344.67997.394271＠parhasard.net
You’re listed as the maintainer of the x-symbol package, but your
＠xemacs.org address bounced.
--
¿Dónde estará ahora mi sobrino Yoghurtu Nghé, que tuvo que huir
precipitadamente de la aldea por culpa de la escasez de rinocerontes?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
6193
days inactive
6207
days old
7 comments
3 participants
participants (3)
-
Aidan Kehoe -
Reiner Steib -
Stephen J. Turnbull