3:50 p.m.
What's the status of font-lock and derived.el in XEmacs nowadays,
regarding sync with GNU Emacs?
I've understood that font-lock may be a bit controversial topic, but
there are a couple of *-faces and the :inherit stuff that might be
useful to have in XEmacs also.
derived.el seems quite different in XEmacs from what it is in Emacs,
which makes it difficult to sync other modes since they seem to be using
it increasingly much and it seems to have some nice goodies. derived.el
is in core now, and a grep to the current source tree reveals that it is
(possibly) only in use in help.el and list-mode.el there. Would it be
possible/useful to move it into xemacs-base?
Also, I think an up to date easy-mmode.el should be included in some
package, preferably xemacs-base. There is a version of it in pcl-cvs,
but IMO that's not the correct place for it, and this version seems
pretty outdated.
Having these three up to date (with Emacs) would make it much easier to
sync other modes as well as incorporate new ones. It is _possible_ to
work around most of the missing functionality, but it certainly isn't
fun or beautiful :)
Comments?
--
Ville Skyttä
ville.skytta(a)xemacs.org
5:11 a.m.
On 17 Apr 2002, Ville Skytt wrote:
What's the status of font-lock and derived.el in XEmacs
nowadays,
regarding sync with GNU Emacs?
[...]
derived.el seems quite different in XEmacs from what it is in Emacs,
which makes it difficult to sync other modes since they seem to be
using it increasingly much and it seems to have some nice goodies.
I have run into problems with this being out of date every now and then
with tools that look very interesting.
It would be good to see someone sync it up. :)
Daniel
--
You know you'll always be drifting
You know you'll never be found
A servant, so empty, you'll never make a sound
-- Switchblade Symphony, _Naked Birthday_
12:47 a.m.
|--==> "VS" == Ville Skytt <Ville> writes:
VS> I've understood that font-lock may be a bit controversial topic, but
VS> there are a couple of *-faces and the :inherit stuff that might be
VS> useful to have in XEmacs also.
Yeah, that'd be pretty nifty.
VS> derived.el seems quite different in XEmacs from what it is in Emacs,
VS> which makes it difficult to sync other modes since they seem to be using
VS> it increasingly much and it seems to have some nice goodies. derived.el
VS> is in core now, and a grep to the current source tree reveals that it is
VS> (possibly) only in use in help.el and list-mode.el there. Would it be
VS> possible/useful to move it into xemacs-base?
Anything's possible. But what do we gain from moving a piece of
dumped lisp into the packages?
VS> Also, I think an up to date easy-mmode.el should be included in some
VS> package, preferably xemacs-base. There is a version of it in pcl-cvs,
VS> but IMO that's not the correct place for it, and this version seems
VS> pretty outdated.
Yep, no problem with doing this. I'll move the file then you can sync
it.
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
11:01 a.m.
>>>> "SY" == Steve Youngs
<youngs(a)xemacs.org> writes:
SY> Anything's possible. But what do we gain from moving a piece
SY> of dumped lisp into the packages?
Faster approval and distribution of improvements, and all of the
versions that can use packages (ie, >=20.4) stay in synch (maybe ;-).
The con is that derived.el may want to use XEmacs internals.
I'd say that it would be real nice if Ville would look at packagizing
it, although it might not really be feasible to move it out of core.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
11:18 p.m.
On Wed, 2002-05-01 at 02:47, Steve Youngs wrote:
VS> I've understood that font-lock may be a bit
controversial topic, but
VS> there are a couple of *-faces and the :inherit stuff that might be
VS> useful to have in XEmacs also.
Yeah, that'd be pretty nifty.
Ok, I'll see if I can find time to do a (at least) partial sync soon.
VS> derived.el seems quite different in XEmacs from what it is
in Emacs,
VS> which makes it difficult to sync other modes since they seem to be using
VS> it increasingly much and it seems to have some nice goodies. derived.el
VS> is in core now, and a grep to the current source tree reveals that it is
VS> (possibly) only in use in help.el and list-mode.el there. Would it be
VS> possible/useful to move it into xemacs-base?
Anything's possible. But what do we gain from moving a piece of
dumped lisp into the packages?
Well, the ability to actually _use_ the new functionality in packages
without having to worry about backwards compatibility for XEmacsen that
do not have the new stuff. Looking from the packages side, it would not
be too useful to update for example derived.el in XEmacs 21.5 with Emacs
21.2, since packages could still not use it as they have to support 21.1
and 21.4 too. Plus the usual benefits for lisp in packages vs in core;
quicker, better targeted change/bugfix/update cycle etc?
Ah, and for these reasons it would be nice to have font-lock in packages
too, but I see there is some C code (src/font-lock.c) related to it,
might be a trickier one to move? Maybe this is why font-lock is still
in core and not in fsf-compat or xemacs-base though many
font-lock-*-face docs say "It is present only for horrid FSF
compatibility reasons."?
By "possible" I meant stuff like what happens if an XEmacs with
dumped/in-core foo.el installs and uses a package with a new version of
foo.el? Warnings? Which version will actually be used? Other
problems?
VS> Also, I think an up to date easy-mmode.el should be included
in some
VS> package, preferably xemacs-base. There is a version of it in pcl-cvs,
VS> but IMO that's not the correct place for it, and this version seems
VS> pretty outdated.
Yep, no problem with doing this. I'll move the file then you can sync
it.
Cool. I'll take a look after the move has happened.
--
Ville Skyttä
ville.skytta(a)xemacs.org
5:57 a.m.
>>>> "Ville" == Ville Skytt <Ville>
writes:
Ville> By "possible" I meant stuff like what happens if an XEmacs
Ville> with dumped/in-core foo.el installs and uses a package with
Ville> a new version of foo.el? Warnings? Which version will
Ville> actually be used? Other problems?
If you require it, the preloaded version will be used. If you
load-library it, the package version should be used with the default
load-path.
You will get shadowing warnings at build time (maybe) and in bug
reports, but not in ordinary operation.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
8041
days inactive
8056
days old
5 comments
4 participants
participants (4)
-
Daniel Pittman -
Stephen J. Turnbull -
Steve Youngs -
Ville Skyttä