9:30 a.m.
I hope you don't mind me redirecting this to the list.
Mats Lidell writes:
Hi Stephen,
>>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes:
> I disagree, but ... revisit us around Christmas. We'll see.
Are you just considering what half a year with GPLv3 or later
possibility will bring or are you sitting on some information you are
not sharing publicly?
I know that I want to get some work done on XEmacs this summer. More
on precisely what that means shortly, once I actually start committing
some time. I suppose some others will too. For example, I know
Aidan's busy with his professional work, but obviously he has enough
time to read the list and enough interest to thank Hans. I imagine he
still has a few Common Lisp itches to scratch.
Also, I don't expect to, say, "catch up to GNU" by then, I'm just
saying I hope the project will show visible progress and activity by
then.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
11:48 p.m.
New subject: Future of XEmacs
>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes:
I hope you don't mind me redirecting this to the list.
No problem.
Also, I don't expect to, say, "catch up to GNU" by
then, I'm just
saying I hope the project will show visible progress and activity by
then.
Sounds promising.
I'm getting more convinced that upgrading existing packages in the
tree. even introducing new packages, is the right tool to use. That
way we will focus on improving functionality users use and at the same
time find what APIs we need to improve to be compatible with GNU.
Most of all I think it is much easier than to introduce core
functionality in isolation. It is really just to pick a package, see
whether it has been upgraded upstream and try to sync. That will
trigger some things we need to adress possibly in the core etc.
We had a recent gnus update. What other packages do you think are
falling behind and needs to be upgraded?
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:57 a.m.
New subject: Future of XEmacs
Mats Lidell wrote:
We had a recent gnus update. What other packages do you think are
falling behind and needs to be upgraded?
An update to the calendar package would be nice. The version that I
sometimes use at work (bundled with Emacs) provides a nice
pretty-printed display of events, so there's no need to keep the diary
file sorted.
mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5:03 p.m.
New subject: Future of XEmacs
Mike Kupfer wrote:
Mats Lidell wrote:
> We had a recent gnus update. What other packages do you think are
> falling behind and needs to be upgraded?
An update to the calendar package would be nice. The version that I
sometimes use at work (bundled with Emacs) provides a nice
pretty-printed display of events, so there's no need to keep the diary
file sorted.
mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
auctex should be upgraded (my call)
reftex as well.
I also think it would be nice to have org-mode as a Xemacs package,
however on the org-mode mailing list, there are almost no Xemacs
users..... which makes me believe that this is no high priority...
Uwe Brauer
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
11:16 p.m.
New subject: Future of XEmacs
>>>> Uwe Brauer <oub(a)mat.ucm.es> writes:
I also think it would be nice to have org-mode as a Xemacs package,
however on the org-mode mailing list, there are almost no Xemacs
users..... which makes me believe that this is no high priority...
I want org-mode too but until now I have not wanted it badly enough to
get it working. I think Michael Sperber is working on this but I don't
know the status.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
7:24 a.m.
New subject: Future of XEmacs
Mats Lidell <matsl(a)xemacs.org> writes:
>>>>> Uwe Brauer <oub(a)mat.ucm.es> writes:
> I also think it would be nice to have org-mode as a Xemacs package,
> however on the org-mode mailing list, there are almost no Xemacs
> users..... which makes me believe that this is no high priority...
I want org-mode too but until now I have not wanted it badly enough to
get it working. I think Michael Sperber is working on this but I don't
know the status.
It's on my list: Every few weeks, I synch with upstream org-mode to at
least see to it that the most important stuff works. I can't promise
any completion date for the package - some help would be much
appreciated.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
2:12 p.m.
New subject: Future of XEmacs
Well I use orgmode for the following things:
- The table editor, which has, via calc a spreadsheet,
which can be exported to csv. The editor can also be
used in LaTeX files, which for me is extremely
convenient.
- org-preview-latex-fragment which allows to preview
latex formulas as png, in *any* sort of file or
buffer. I use this for example in matlab files.
Preview-latex offers a similar functionality
for auctex but only for LaTeX files.
- Org-mime-htmlize, which allows to insert Latex math
formulas as png in an htmlized email. Like this
$\int f(x)dx=0$
which I use very often in my emails.
I think Michael Sperber is working on this but I don't
know the status.
Right, Carsten Dominik thought of stopping Xemacs support
for orgmode, since he uses GNU Emacs and observed very few
Xemacs users on the orgmode list. Fortunately Michael
stepped in and saved the Xemacs support. (For example the
table support I mentioned above).
org-preview-latex-fragment did not work for Xemacs, but
thanks to Julian B. I was able to find a patch for Xemacs and
submitted some it some month ago..
However as far as know org-mode < vs 7 works well with
Xemacs 21.4.X but only 21.5.X works with org-mode >vs
7. That is why I don't know whether it makes really sense to
provide orgmode as a xemacs pkg.
Uwe
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5:37 a.m.
New subject: Future of XEmacs
Uwe Brauer writes:
I also think it would be nice to have org-mode as a Xemacs package,
however on the org-mode mailing list, there are almost no Xemacs
users..... which makes me believe that this is no high priority...
FWIW, Bastien disagrees and cared enough to mention it to me
personally (although we were already involved in a conversation about
GSoC).
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5:22 a.m.
New subject: Future of XEmacs
Mats Lidell writes:
>>>>> Stephen J Turnbull <stephen(a)xemacs.org>
writes:
I'm getting more convinced that upgrading existing packages in
the
tree. even introducing new packages, is the right tool to use.
Of course. But remember what started this thread: a developer who was
having trouble using XEmacs with the packages he wanted.
Most of all I think it is much easier than to introduce core
functionality in isolation.
Problem is, Emacsen in general don't have "isolation", and GNU Emacs
is way worse than XEmacs on this ground. We need both approaches, or
we'll just cruftify rapidly. Most of the actual development work I've
done on XEmacs has been to fix *shit* ported from GNU Emacs hastily,
just enough to work for the developer involved, who typically then
disappears. (To be honest, most of it was reasonable in GNU, it was a
porting job that didn't account for the real technical differences
between XEmacs and GNU, but some of it already was pretty icky.)
I agree with your assessment that we'll make a lot of progress by
upgrading packages, and I don't want to discourage anyone from doing
that. But let's at least pray for some folks who want to do generic
syncs and true ports of Emacs concepts to XEmacs code.
We had a recent gnus update. What other packages do you think are
falling behind and needs to be upgraded?
All of them. ;-) I'm currently working on VM, off and on, lately more
off than on.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
11:31 p.m.
New subject: Future of XEmacs
>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes:
Of course. But remember what started this thread: a developer who
was having trouble using XEmacs with the packages he wanted.
Well, introducing new packages can really trigger a lot of things that
we don't have support for. So that is good to do!
[...] Most of the actual development work I've done on XEmacs
has
been to fix *shit* ported from GNU Emacs hastily, [...]
Well, I'm just suggesting upgrading as a tool to drive the
development. Each problem should be solved appropriately. Some times a
rewrite is the right thing and sometimes adding functionality to the
core is needed.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
8:52 p.m.
New subject: Future of XEmacs
Am 27.07.2012 00:31, schrieb Mats Lidell:
>>>>> Stephen J Turnbull <stephen(a)xemacs.org>
writes:
> Of course. But remember what started this thread: a developer who
> was having trouble using XEmacs with the packages he wanted.
Well, introducing new packages can really trigger a lot of things that
we don't have support for. So that is good to do!
> [...] Most of the actual development work I've done on XEmacs has
> been to fix *shit* ported from GNU Emacs hastily, [...]
Well, I'm just suggesting upgrading as a tool to drive the
development. Each problem should be solved appropriately. Some times a
rewrite is the right thing and sometimes adding functionality to the
core is needed.
Yours
Hi,
while going on certainly is honorable, it might pay to analyze the reasons of the relative
fall-behind last years.
Why GNU Emacs got that many contributions and XEmacs didn't - at least in relation?
AFAIU its a technical question basically.
It's not about contributions, but about getting rid...
Cheers,
Andreas
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:31 a.m.
New subject: Future of XEmacs
Andreas Röhler writes:
Why GNU Emacs got that many contributions and XEmacs didn't - at
least in relation?
It's very simple, really. Emacsen are basically tied to GNU APIs and
UIs, which are ancient and boring, and aren't attracting young, active
developers (even those who use Emacs daily). Most people who work on
Emacsen for many years (ie, the backbone developers) are old-style
hackers with a strong FSF affiliation, so they chose Emacs and aren't
going to move to XEmacs or SXEmacs no matter how good the technology
is.
AFAIU its a technical question basically.
Not at all. Technically, it has been repeatedly proved that XEmacs
can catch up to GNU very quickly with a much smaller amount of effort
applied than the original development took. It's all social/
political.
It's not about contributions, but about getting rid...
Of who? Me? ;-)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
8:32 a.m.
New subject: Future of XEmacs
Am 28.07.2012 04:31, schrieb Stephen J. Turnbull:
Andreas Röhler writes:
> Why GNU Emacs got that many contributions and XEmacs didn't - at
> least in relation?
It's very simple, really. Emacsen are basically tied to GNU APIs and
UIs, which are ancient and boring, and aren't attracting young, active
developers (even those who use Emacs daily). Most people who work on
Emacsen for many years (ie, the backbone developers) are old-style
hackers with a strong FSF affiliation, so they chose Emacs and aren't
going to move to XEmacs or SXEmacs no matter how good the technology
is.
> AFAIU its a technical question basically.
Not at all. Technically, it has been repeatedly proved that XEmacs
can catch up to GNU very quickly with a much smaller amount of effort
applied than the original development took. It's all social/
political.
> It's not about contributions, but about getting rid...
Of who? Me? ;-)
No, pointed at a technical issue.
While at GNU Emacs people are implementing new features and fixing bugs, at XEmacs
considerable energies seem consumed by dealing with packages.
The backside of this its-already-all-done-for-you approach, which packages seems to
implement, outweights its benefits.
Don't think packages have been a bad idea from the very beginning. For now however,
experienced the result of it's implementation for years, it's definitly time to
discuss it.
Please let people write and load code as easy as with GNU Emacs.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4:27 p.m.
New subject: Future of XEmacs
Andreas Röhler writes:
While at GNU Emacs people are implementing new features and fixing
bugs, at XEmacs considerable energies seem consumed by dealing with
packages.
You're wrong. If you think otherwise, ask Norbert directly how much
burden it is on him. For everybody else, 99% of their effort goes
into implementing features and fixing bugs, and it would be even
higher if we were doing a lot of development because people would be
sufficiently in practice that they don't need to ask questions about
who commits in the top-level.
There are two real issues with packages. The first is the $prefix/lib
vs. $prefix/share mess, which mostly affects users rather than
developers, but needs fixed (and is gradually improving in 21.5).
This is a difficult issue because it crosses versions, and 21.5 is not
yet ready to replace 21.4 for many users.
The other is the build-in-tree issue. This is a tradeoff; on the one
hand, it does involve more developer resources, because you have to
have the whole tree, keep it updated, and so on. On the other hand,
it reduces the amount of resources required to work on core, and
imposes a discipline on high-level APIs.
Please let people write and load code as easy as with GNU Emacs.
I have no idea what you mean by that.
I gather you haven't noticed ELPA yet, either.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5:55 p.m.
New subject: Future of XEmacs
> On Mon, 30 Jul 2012 00:27:19 +0900, "Stephen J.
Turnbull" <stephen(a)xemacs.org> wrote:
Andreas Röhler writes:
> While at GNU Emacs people are implementing new features and fixing
> bugs, at XEmacs considerable energies seem consumed by dealing with
> packages.
There are two real issues with packages. The first is
the $prefix/lib vs. $prefix/share mess, which mostly
affects users rather than developers, but needs fixed
(and is gradually improving in 21.5). This is a
difficult issue because it crosses versions, and 21.5
is not yet ready to replace 21.4 for many users.
I am not sure what you mean.
For me the structure
lisp/auctex
man/auctex
is cumbersome. I would prefer the other way around
auctex/lisp
auctex/man
Etc.
Another point is the numbering system. I think it would be
best to adapt a debian like numbering scheme.
We use the version numbers the authors provide and indicate
our chances by letter suffixes.
Example: auctex (officical version 11.86, Xemacs version
11.85) should be named as
auctex-11.85-a
And any modification we do (but not the official auctex team
should be denoted by the suffix, like
auctex-11.85-b etc etc.
This would also help to know which packages are outdated and
which are not.
Last but not least if we had something like debian's alien,
a pkg which converts a bundle of lisp files into out pkg
system, that would be a great leap forward.
I gather you haven't noticed ELPA yet, either.
BTW how
compares our pkg system with ELPA?
Uwe
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
8:20 p.m.
New subject: Future of XEmacs
Uwe Brauer wrote:
Another point is the numbering system. I think it would be
best to adapt a debian like numbering scheme.
We use the version numbers the authors provide and indicate
our chances by letter suffixes.
I'd like to see the author (upstream) version information made more
visible, too, though it's fairly low on my personal priority list.
Being able to support a wide range of upstream version formats is
non-trivial.
mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:22 a.m.
New subject: Future of XEmacs
Mike Kupfer writes:
Uwe Brauer wrote:
> Another point is the numbering system. I think it would be
> best to adapt a debian like numbering scheme.
> We use the version numbers the authors provide and indicate
> our chances by letter suffixes.
I'd like to see the author (upstream) version information made more
visible, too, though it's fairly low on my personal priority list.
Being able to support a wide range of upstream version formats is
non-trivial.
Once we provide and make discoverable a way to extract that
information, I don't see why my suggestion in my reply to Uwe about
using a list of version information (author-version xemacs-revno
xemacs-revid) wouldn't do the trick. Perhaps there should be one more
field which would be the email address of the release authority -- for
the "official" packages, something like packages(a)xemacs.org (NOT
viteno(a)xemacs.org! Norbert might want to release his own unofficial
packages, and it shouldn't change if Norbert retires or goes on
leave). And it probably should be a plist.
It's only when you try to serialize all that information in one string
that is easy for a POSIX shell to work with that life gets hard. We
don't have that problem. In the official package sources, we can work
with revids. In XEmacs, we can use Lisp data structures.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
7:26 p.m.
New subject: Future of XEmacs
Stephen J. Turnbull wrote:
Mike Kupfer writes:
> Uwe Brauer wrote:
>
> > Another point is the numbering system. I think it would be
> > best to adapt a debian like numbering scheme.
> > We use the version numbers the authors provide and indicate
> > our chances by letter suffixes.
>
> I'd like to see the author (upstream) version information made more
> visible, too, though it's fairly low on my personal priority list.
> Being able to support a wide range of upstream version formats is
> non-trivial.
Once we provide and make discoverable a way to extract that
information, I don't see why my suggestion in my reply to Uwe about
using a list of version information (author-version xemacs-revno
xemacs-revid) wouldn't do the trick.
That does look like a plausible approach. Having our own monotonically
increasing counter (xemacs-revno) would let us sidestep the parsing
issues that come with the Debian scheme.
I'd want to consider some of the edge cases, though, like what happens
if we end up moving to another source code control system for some
reason. Not that I want to encourage that, or even that I think such a
move is likely; I just want to make sure we don't paint ourselves into a
corner. I suppose that if the integer revision number is not
transferable, we could always introduce some sort of epoch number.
I still have a mild desire for putting the author version in the package
tarball name, but that's mostly because I haven't figured out how to
make PUI work from behind my employer's firewall. Then again, the right
answer there is probably to change PUI or EFS, not the tarball file
name.
mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
7:42 p.m.
New subject: Future of XEmacs
Mike Kupfer writes:
I'd want to consider some of the edge cases, though, like what
happens if we end up moving to another source code control system
for some reason.
I think that's something to worry about when it happens. I'd rather
avoid the "epoch" solution, though.
that's mostly because I haven't figured out how to make PUI
work
from behind my employer's firewall. Then again, the right answer
there is probably to change PUI or EFS, not the tarball file name.
I think the right thing to do is to use HTTP, as SXEmacs does.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:21 p.m.
New subject: Future of XEmacs
Stephen J. Turnbull wrote:
Mike Kupfer writes:
> I'd want to consider some of the edge cases, though, like what
> happens if we end up moving to another source code control system
> for some reason.
I think that's something to worry about when it happens. I'd rather
avoid the "epoch" solution, though.
Yeah, I'd consider it a solution of last resort.
> that's mostly because I haven't figured out how to make
PUI work
> from behind my employer's firewall. Then again, the right answer
> there is probably to change PUI or EFS, not the tarball file name.
I think the right thing to do is to use HTTP, as SXEmacs does.
Agreed.
mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:06 a.m.
New subject: Future of XEmacs
Uwe Brauer writes:
>> On Mon, 30 Jul 2012 00:27:19 +0900, "Stephen J.
Turnbull" <stephen(a)xemacs.org> wrote:
> There are two real issues with packages. The first is
> the $prefix/lib vs. $prefix/share mess, which mostly
> affects users rather than developers, but needs fixed
> (and is gradually improving in 21.5). This is a
> difficult issue because it crosses versions, and 21.5
> is not yet ready to replace 21.4 for many users.
I am not sure what you mean.
I mean that in 21.4, configure assumes that XEmacs's package Lisp will
be installed into something like /usr/local/lib/xemacs, and in 21.5,
the corresponding default is /usr/local/share/xemacs. This change was
made for FHS conformance but it's annoying to those who use both.
For me the structure
lisp/auctex
man/auctex
is cumbersome. I would prefer the other way around
auctex/lisp
auctex/man
That's a completely different issue. Lobby Mike Sperber about it.
He's been refusing to consider a change in this for a decade or so.
I'm not going to work on it myself because it's really not that big a
deal to work with, but changing this looks like it is going to be
hairy.
Another point is the numbering system. I think it would be
best to adapt a debian like numbering scheme.
This doesn't really make that much sense. On the one hand, RMS
refuses to put versions on libraries developed within Emacs. (Which
makes sense because Emacs developers feel free to change APIs around,
so the only version that really makes sense is that of Emacs itself.)
We use the version numbers the authors provide
For externally maintained packages we already mostly do. But for many
packages there is no external version.
I don't really see a point in maintaining an XEmacs release number
once that's been done. What we should do instead is bake the
Mercurial revno into the package somewhere, and provide APIs and
commands for extracting them. (We actually already have most of
what's needed in the pkginfo library, but they're not well documented
and even more poorly advertised.)
This would also help to know which packages are outdated and
which are not.
M-x list-packages will tell you that.
Last but not least if we had something like debian's alien,
a pkg which converts a bundle of lisp files into out pkg
system, that would be a great leap forward.
I don't see how it would be a "great leap". The part of the process
that can be automated is both simple and well-documented in the
LispRef "Creating Packages" node. Anything more that is required
beyond copying the example files and filling in the blanks with data
relevant to your package is not going to be automatable.
> I gather you haven't noticed ELPA yet, either.
BTW how compares our pkg system with ELPA?
We won't know for several years. I think they're going to run into
big problems in a few years as ELPA expands. Currently almost all
packages have no dependencies outside the Emacs core. That makes
generating an ELPA package simple. But this simplicity is deceptive,
because (1) as the core changes, the packages will need to be updated
and they'll experience the same kind of skew problems we do, and (2)
as packages start to depend on each other, they'll need to add
dependencies. I expect some massive flamewars over (1) because the
Emacs maintainers' position is effectively that there's only one
release of Emacs that they need to worry about compatibility with, and
that's the upcoming one. And packages aren't their problem.
On the other hand, ELPA could work very well if they adopt flexible
rules for incorporating new packages into Emacs so that "only depends
on core" restriction continues to be satisfied for the majority of
packages.
Finally, there's the wild card that there's more than one ELPA. GNU
ELPA insists on the same conditions that apply to Emacs (including
copyright assignment, IIRC). Other ELPAs do not. This could get very
messy if there's version skew or dependencies across ELPAs.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
8:11 p.m.
New subject: Future of XEmacs
Andreas Röhler wrote:
While at GNU Emacs people are implementing new features and fixing
bugs, at XEmacs considerable energies seem consumed by dealing with
packages.
Yes and no. Personally, I'm spending a fair amount of time dealing with
the packages that I own, but a lot of that has to do with infrastructure
problems over the past few years and the fact that I'm still fairly new
at this. On the other hand, if I weren't working on packages, I
probably wouldn't be spending much time on new features, because XEmacs
already does more or less what I want from it.
The backside of this its-already-all-done-for-you approach, which
packages seems to implement, outweights its benefits.
I don't think the evidence supports that conclusion.
mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
11:41 p.m.
New subject: Future of XEmacs
>>>> Andreas Röhler <andreas.roehler(a)online.de>
writes:
Don't think packages have been a bad idea from the very
beginning. For now however, experienced the result of it's
implementation for years, it's definitly time to discuss it.
The package system is like distributions are for linux. You get a set
of packages that work together.
Please let people write and load code as easy as with GNU Emacs.
You are not limited to just the package system. Other code can be used
with XEmacs just as easily as with GNU Emacs.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
11:28 p.m.
New subject: Future of XEmacs
>>>> Andreas Röhler <andreas.roehler(a)online.de>
writes:
while going on certainly is honorable, it might pay to analyze the
reasons of the relative fall-behind last years.
I find nothing honorable about it at all. It is an open source project
I happen to find fun to hack on. If you by fall-behind mean lack of
developers I guess it is just that there are fewer of us now that
finds this fun.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5:09 p.m.
New subject: Future of XEmacs
On Wed, Jul 25, 2012 at 3:48 PM, Mats Lidell <matsl(a)xemacs.org> wrote:
We had a recent gnus update. What other packages do you think are
falling behind and needs to be upgraded?
Since you asked, I'd like an updated font-lock.
I tried my hand at it a while ago, and there are lots of dependencies to
things that don't exist (or have different names) in xemacs. After a bit
of hacking, I stopped. I just don't know enough to make it happen in a
reasonable amount of time and/or effort. but I'm willing to try again.
And since Thunderbird is slowly dying, I may have to get email working
again with gnus or vm or mh-e again. (But so much email uses html these
days, it's annoying to read them with gnus.)
Ray
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:36 a.m.
New subject: Future of XEmacs
Raymond Toy <toy.raymond(a)gmail.com> writes:
(But so much email uses html these days, it's annoying to read
them
with gnus.)
It isn't anymore. Recent gnus comes with a simple renderer, which makes
it acceptable to read htmlized emails.
Ray
Best regards, Michael.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
11:39 p.m.
New subject: What version of Gnus supports html rendering (was: Future of XEmacs)
>>>> Michael Albinus <michael.albinus(a)gmx.de>
writes:
It isn't anymore. Recent gnus comes with a simple renderer,
which
makes it acceptable to read htmlized emails.
From what version of gnus is that supported?
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
10:14 a.m.
New subject: What version of Gnus supports html rendering
Mats Lidell <matsl(a)xemacs.org> writes:
>>>>> Michael Albinus <michael.albinus(a)gmx.de>
writes:
> It isn't anymore. Recent gnus comes with a simple renderer, which
> makes it acceptable to read htmlized emails.
From what version of gnus is that supported?
It was announced with No Gnus v0.11. I use shr.el, and it works
fine. However, the announcement restricts this to Emacs 24 - I don't
know, whether this has been ported to XEmacs, when gnus was upgraded
recently in the packages repo.
The announcement mail said
* two new HTML renderers -- one based on w3m, if you're not using Emacs
24, and one totally built-in called shr (Simple HTML Renderer), if
you're using Emacs 24
Best regards, Michael.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
8:04 p.m.
New subject: What version of Gnus supports html rendering
Michael Albinus wrote:
Mats Lidell <matsl(a)xemacs.org> writes:
>>>>>> Michael Albinus <michael.albinus(a)gmx.de> writes:
>
>> It isn't anymore. Recent gnus comes with a simple renderer, which
>> makes it acceptable to read htmlized emails.
>
> From what version of gnus is that supported?
It was announced with No Gnus v0.11. I use shr.el, and it works
fine. However, the announcement restricts this to Emacs 24 - I don't
know, whether this has been ported to XEmacs, when gnus was upgraded
recently in the packages repo.
No, I'm afraid that was just to update to 5.10.10. I'll update my Gnus
git tree and try to figure out what's the most recent stable version.
Since No Gnus is done, the stable version should have shr.
* two new HTML renderers -- one based on w3m, if you're not using
Emacs
24, and one totally built-in called shr (Simple HTML Renderer), if
you're using Emacs 24
I'll try to figure out what dependencies shr has on Emacs 24.
mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:23 p.m.
New subject: What version of Gnus supports html rendering
On 29 Jul 2012, Mike Kupfer uttered the following:
I'll try to figure out what dependencies shr has on Emacs 24.
The biggest one would have to be
,----
| libxml-parse-html-region is a built-in function in `C source code'.
|
| (libxml-parse-html-region START END &optional BASE-URL)
|
| Parse the region as an HTML document and return the parse tree.
| If BASE-URL is non-nil, it is used to expand relative URLs.
`----
--
NULL && (void)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:28 a.m.
New subject: What version of Gnus supports html rendering
Nix writes:
On 29 Jul 2012, Mike Kupfer uttered the following:
> I'll try to figure out what dependencies shr has on Emacs 24.
The biggest one would have to be
,----
| libxml-parse-html-region is a built-in function in `C source code'.
That shouldn't be too hard to implement as an ELL, so it can even be
used by 21.4.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
7:20 p.m.
New subject: Future of XEmacs
Mats Lidell <matsl(a)xemacs.org> writes:
We had a recent gnus update. What other packages do you think are
falling behind and needs to be upgraded?
Upgrading Tramp is on my todo. I don't know, whether it falls into the
"needs to be upgraded" category, 'tho.
Yours
Best regards, Michael.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
8:29 a.m.
New subject: Future of XEmacs
Mats Lidell writes:
I'm getting more convinced that upgrading existing packages in
the
tree[,] even introducing new packages, is the right tool to use
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
org-mode?
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4498
days inactive
4503
days old
32 comments
10 participants
participants (10)
-
Andreas Röhler -
Giacomo Boffi -
Michael Albinus -
Michael Sperber -
Mike Kupfer -
Nix -
Raymond Toy -
Stephen J. Turnbull -
The XEmacs Package Smoketest -
Uwe Brauer