Issue98

classification
Title [PATCH] Abstract out a display-table-specific API (2)
Type defect Module core code 21.4, gnus, misc-games, xemacs-base
Severity inelegant Platform N/A
Keywords Nosy List mike.kupfer
explanation
process
These controls should only be changed by committers and tracker administrators.
Status chatting   Reason
Superseder   Submitted 2007-12-30.23:41:19
Priority normal   Assigned To

Created on 2008-01-19.04:58:06 by stephen, last changed 2008-02-18.04:09:31 by mike.kupfer.

Messages
msg372 [hidden] ([hidden]) Date: 2008-01-19.06:43:15
  Message-ID: <18866.1198955430@rawbw.com>
>>>>> "Aidan" == Aidan Kehoe <kehoea@parhasard.net> writes:

MikeK> What I'm saying is that there should only be *one* copy in
MikeK> packages, for use by all the packages.  But your patches
MikeK> introduce duplicates in gnus, xemacs-base, misc-games, etc.
MikeK> Instead, put one copy in xemacs-base (case-table.el?  new file?),
MikeK> and all the other packages can use that copy, yeah?

Aidan> That introduces new package dependencies, something I'm not in
Aidan> a hurry to do given how much Mike Sperber fucked up the package
Aidan> build last time he did so. 

I can understand your reluctance, particularly since I don't know how
well defun-when-void and autoloads play together.  But having multiple
copies of the same function is leaving a bunch of stones around for
people to stumble over later, particularly if the function definition
ever needs to change.

I can probably be talked into adding the defuns to gnus on a temporary
basis, so that your changes to 21.5 don't get delayed too much.  But I'd
really like to have a "get well" plan first.

Would the package-future.el that Stephen recently proposed be a good
place to put put-display-table and get-display-table, using
defun-when-void?

mike

_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta@xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
msg371 [hidden] ([hidden]) Date: 2008-01-19.06:43:15
  Message-ID: <18294.22006.570696.622378@parhasard.net>
Ar an ceathrú lá is fiche de mí na Nollaig, scríobh Mike Kupfer: 

 > >>>>> "Aidan" == Aidan Kehoe <kehoea@parhasard.net> writes:
 > 
 > MikeK> Second, you appear to be introducing multiple copies of
 > MikeK> put-display-table and get-display-table, both in this patch set and
 > MikeK> in the patches you committed to xemacs-base and misc-games.
 > MikeK> Shouldn't there be just one copy in the packages tree, presumably in
 > MikeK> xemacs-base?
 > 
 > Aidan> disp-table.el, which provides the display table
 > Aidan> code--make-display-table, frob-display-table,
 > Aidan> describe-display-table, and in
 > Aidan> http://mid.gmane.org/18288.1954.87217.762309@parhasard.net ,
 > Aidan> put-display-table and get-display-table--is in core. Yeah,
 > Aidan> there's a decent argument that it might be better in packages,
 > Aidan> but it isn't there for the moment. 
 > 
 > I'm not sure we're understanding each other.  I can understand having
 > the functions in core in 21.5, plus a version in packages using
 > defun-when-void for 21.4.  What I'm saying is that there should only be
 > *one* copy in packages, for use by all the packages.  But your patches
 > introduce duplicates in gnus, xemacs-base, misc-games, etc.  Instead,
 > put one copy in xemacs-base (case-table.el?  new file?), and all the
 > other packages can use that copy, yeah?

That introduces new package dependencies, something I’m not in a hurry to do
given how much Mike Sperber fucked up the package build last time he did
so. (And he still hasn’t fixed it!) The Gnus folk will probably approach the
thing differently anyway, and define a mm-put-display-table, but that is
their decision.
msg124 [hidden] ([hidden]) Date: 2008-01-19.04:58:06
  Message-ID: <87tzm61mgf.fsf@uwakimon.sk.tsukuba.ac.jp>
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@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@xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
msg123 [hidden] ([hidden]) Date: 2008-01-19.04:58:06
  Message-ID: <87zlvrievs.fsf@uwakimon.sk.tsukuba.ac.jp>
Mike Kupfer writes:

 > >>>>> "ST" == Stephen J Turnbull <stephen@xemacs.org> writes:
 > 
 > ST> The real solution is to have a standard-library package (or package
 > ST> suite) which is shared between all reasonably recent XEmacs
 > ST> versions.  (This is the real long-term motivation for the
 > ST> "bundled-packages" work.)  Versions of XEmacs without C support for
 > ST> certain features would have to do without, or perhaps use
 > ST> inefficient Lisp versions.
 > 
 > Is the plan that standard-library is available as an unbundled package,
 > as well as being delivered with a given version of core?

"Plan"?  No plan yet.  The "batteries included" distribution (core +
packages) is an old ambition of Martin's, to tell the truth, and I see
it as a really easy way to make it easier for new users to get into
XEmacs.

The general idea is that the standard-library would be the stuff that
is documented in the Lispref but written in Lisp.  I'd like to see
advances in font-lock and things like that be available to 21.4 users.
But I haven't thought carefully about how to make it work (thus
gaffes like "oh, go ahead and use functions that won't be available at
runtime, it'll just work...." :-P ).

_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta@xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
msg122 [hidden] ([hidden]) Date: 2008-01-19.04:58:06
  Message-ID: <878x3b699c.fsf@uwakimon.sk.tsukuba.ac.jp>
mike.kupfer@xemacs.org writes:

 > >>>>> "ST" == Stephen J Turnbull <stephen@xemacs.org> writes:
 > 
 > ST> Make them defsubsts.  ;-)
 > 
 > ST> I'm not really joking about this case: I think it's a reasonable
 > ST> answer even though a bit fragile.  However, I acknowledge it's not a
 > ST> good generic answer.
 > 
 > I think a good generic answer would be to have 2 "futures" files: one
 > for compile-time fixups and one that's available at run time, probably
 > as part of xemacs-base.
 > 
 > How does that sound?

The potential problem is that we don't have a good way to inform users
that they need Version X.Y of xemacs-base.  If putting
runtime-future.el into xemacs-base was a good solution, I don't see
why we'd need a separate compile-time version.

Also, if you put it into xemacs-base, it gets compiled.  The inability
to run uncompiled macros from bytecode means that in principle every
version of XEmacs needs a different compiled version of xemacs-base.
The history of the APEL package shows that this is a practical
problem, too.

The real solution is to have a standard-library package (or package
suite) which is shared between all reasonably recent XEmacs versions.
(This is the real long-term motivation for the "bundled-packages"
work.)  Versions of XEmacs without C support for certain features
would have to do without, or perhaps use inefficient Lisp versions.

_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta@xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
History
Date User Action Args
2008-02-18 04:09:31mike.kupfersetseverity: inelegant
nosy: + mike.kupfer
module: + core code 21.4, gnus, misc-games, xemacs-base
priority: normal
platform: + N/A
type: defect
2008-01-19 06:43:15mike.kupfer1setmessages: + msg372
2008-01-19 06:43:15aidansetmessages: + msg371
2008-01-19 04:58:06stephensetmessages: + msg124
2008-01-19 04:58:06stephensetstatus: new -> chatting
messages: + msg123
2008-01-19 04:58:06stephencreate