12:08 p.m.
>>>> "Stephen" == Stephen J Turnbull
<turnbull(a)sk.tsukuba.ac.jp> writes:
Stephen> Reviving this thread in view of active interest in
Stephen> scheduling a public release on both xemacs-beta and
Stephen> xemacs-review.
Stephen> [Is there a Lisp function for getting the archive URL
Stephen> from a message ID? Actually doing the searches by hand
Stephen> is kinda painful (for some reason recently my HTTP
Stephen> connectivity has sucked, I think it's local network
Stephen> mismanagement). If I could just queue them up to be
Stephen> dumped in a buffer it would be cool.]
I suggested making the XEmacs mailing lists searchable for Message ID,
based on the fact that they are contained in HTML comments anyways.
This has never been implemented.
Remember that the archive is a few days behind, it can't currently be
used to refer to recent articles.
HTTP URL IDs would be ideal to keep track of things though.
Stephen> Since there's a lot of stuff here, I suggest that if you
Stephen> have issues to add, can confirm that one has been
Stephen> resolved, or want to say that a particular issue is
Stephen> irrelevant to a near-future release, do it in this
Stephen> thread.
Stephen> If you want to discuss any of the particular points, try
Stephen> to start a new thread (or reply to an existing
Stephen> alternative thread).
Stephen> Gunnar Everman has posted several BTS reports; I guess
Stephen> those should be at least evaluated and presumably fixed
Stephen> before release.
Stephen> Gunnar (if you're watching), do you have a summary handy,
Stephen> or should I go filter the archives?
Stephen> The John A Turner <turner(a)blueskystudios.com> list from
Stephen> <14831.4977.793843.120439(a)denmark.blueskystudios.com>:
Stephen> o the dired customize prob reported here remains:
Stephen>
http://www.xemacs.org/list-archives/xemacs-beta/200002/msg00139.html
Stephen> Fixed, per Charles Waldman and Michael Sperber. A package issue,
Stephen> anyway, but dired/efs are too important to the core to ignore.
Stephen> I believe this fix has been applied in the current dired package?
dired is kept externally by Michael Sperber.
The last three updates were these:
1998-12-09 SL Baur <steve(a)altair.xemacs.org>
* Makefile.dired: Remove conflicting install: target.
1998-05-05 SL Baur <steve(a)altair.xemacs.org>
* dired-xemacs.el (dired-install-menubar): Use easy-menu for
adding menus to menubar.
1998-02-17 Michael Sperber [Mr. Preprocessor]
<sperber(a)informatik.uni-tuebingen.de>
* diff.el: Region stays for diff-beginning-of-buffer and
diff-end-of-buffer.
Is an XEmacs package which hasn't been updated in two years to be
called "maintained"?
Stephen> o focus being lost after pressing Done in a Customize buffer - I
still
Stephen> see the problem on both Irix and win32 - I do use
focus-follows-mouse
Stephen>
http://www.xemacs.org/list-archives/xemacs-beta/200001/msg00202.html
Stephen> o the weirdness in Motif buttons, both in dialogs and in Customize
Stephen> buffers - best report was this one, which has pics:
Stephen>
http://www.xemacs.org/list-archives/xemacs-beta/200010/msg00241.html
Stephen> giacomo boffi <giacomo.boffi(a)polimi.it> in
Stephen> <14832.25010.115179.114817(a)boffi95.stru.polimi.it>
Stephen> o faces bold, italic, bold-italic don't react to size changes
Stephen> Raymond Toy <toy(a)rtp.ericsson.se>:
Stephen> o When fontifying a buffer, the progress bar moves
Stephen> very very slowly and fontification takes forever (>
Stephen> many seconds). However, if I just move the mouse
Stephen> around in the window, the progress bar zips by very
Stephen> quickly, and fontification finishes in less than a
Stephen> second.
Stephen> o A possibly related problem: I start up xemacs and
Stephen> gnus from the command line and have it iconified. It
Stephen> gets stuck somewhere loading up something. As soon
Stephen> as I deiconify it, it zips right along.
Stephen> Raymond Toy's 21.2.3[67] on Solaris/GCC 2.95.2 crashes:
Stephen> <200011072055.PAA22167(a)edgedsp4.ericsson.COM> (and thread)
Stephen> <4nr94dp9lc.fsf_-_(a)rtp.ericsson.se>
Stephen> My own agenda for Mule (not previously published), no particular
Stephen> priority order:
Stephen> o Audit for synchs and feature additions that don't
Stephen> work with Mule (eg, people have patched/intend to
Stephen> patch smtpmail and ps-print in ways that cause data
Stephen> loss and other wastage under Mule)
smtpmail:
Steve, please don't limit yourself to vetoing and auditing.
I have offered to patch smtpmail as per your recommendation.
Further discussion revealed more underlyng problems.
This is the latest status I have and don't plan to do anything further
on the subject:
SJT> From: "Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp>
SJT> Subject: Re: smtpmail: auth + starttls support
SJT> To: Simon Josefsson <sj(a)extundo.com>
SJT> Cc: Adrian Aichner <adrian(a)xemacs.org>, Steve Youngs
<youngs(a)xemacs.org>,
SJT> xemacs-review(a)xemacs.org
SJT> Date: Tue, 14 Nov 2000 18:47:32 +0900 (JST)
SJT> Message-ID: <14865.2612.169221.665492(a)turnbull.sk.tsukuba.ac.jp>
SJT> References: <iluhf5qd50b.fsf(a)barbar.josefsson.org>
SJT> <un1f8jfef.fsf(a)rapier.ecf.teradyne.com>
SJT> <iluaeb79ynk.fsf(a)barbar.josefsson.org>
SJT> <u4s1f5q47.fsf(a)rapier.ecf.teradyne.com>
SJT> <14860.49082.769703.470071(a)turnbull.sk.tsukuba.ac.jp>
SJT> <u3dgy4w9h.fsf(a)rapier.ecf.teradyne.com>
SJT> <uy9yq3g45.fsf(a)rapier.ecf.teradyne.com>
SJT> <14863.15759.122121.129382(a)turnbull.sk.tsukuba.ac.jp>
SJT> <ilu8zqociq2.fsf(a)barbar.josefsson.org>
SJT> <14863.64831.190240.498205(a)turnbull.sk.tsukuba.ac.jp>
SJT> <iluofzjriuu.fsf(a)barbar.josefsson.org>
SJT> Xref: ZJ75T xemacs-review:1704
SJT>
SJT> >>>>> "Simon" == Simon Josefsson <sj(a)extundo.com>
writes:
SJT>
SJT> >> Yuck. This is not good. smtpmail-code-conv-from is defvar'd,
SJT> >> set, or bound somewhere, using a Mule function. That probably
SJT> >> needs to be protected.
SJT>
SJT> Simon> Judging from the variable documentation for
SJT> Simon> smtpmail-code-conv-from is for tiny-mime. Grepping through
SJT> Simon> all Emacs and XEmacs-packages show no hits (except
SJT> Simon> smtpmail), so I guess it's only used by tiny-mime.
SJT>
SJT> OK, I've looked at the code, I couldn't help myself. smtpmail, as is,
SJT> can not be used from Mule at all, except as a backend to a
SJT> full-featured MIME-capable MUA. Using it as the delivery agent for
SJT> plain message-mode or sendmail-mode _will_ destroy your mail if you
SJT> don't use ISO-8859-1 (I am not entirely sure that is safe, but it
SJT> might be).
<lines deleted by Adrian>
SJT> I'll try to get to this by the weekend. In the meantime, I hope
SJT> nobody using Mule uses it.
SJT>
SJT>
SJT> --
SJT> University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
SJT> Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
SJT> _________________ _________________ _________________ _________________
SJT> What are those straight lines for? "XEmacs rules."
ps-print-nomule:
I almost have a patch for ps-print-nomule ready.
I am not qualified to work in the mule version.
Best regards,
Adrian
Stephen> o Fix the autodetection so that only the most common
Stephen> encodings for each environment are autodetected in
Stephen> that environment by default; if there is no language
Stephen> environment set, autodetection is not done. This is
Stephen> a noticable semantic change but at the current pace
Stephen> of release we should do it for the next release and
Stephen> hope most Mule users set language environment.
Stephen> o Partial Windows 12xx support for many values of
Stephen> `xx'.
Stephen> o Windows 12xx graphic glyph support. (Can be done
Stephen> any time.)
Stephen> o (Desirable) Update the fill code, partial synch to
Stephen> FSF 20.7, and fix the kinsoku
Stephen> trailing-whitespace-is-significant bug (FSF still has
Stephen> it). Probably will take time to shake out, though.
>>>> "Hrvoje" == Hrvoje Niksic
<hniksic(a)arsdigita.com> writes
Stephen> (on xemacs-review):
Hrvoje> I'm also worried by the portable dumping. That part seems
Hrvoje> to have reached the mythical 80%/20% border where it
Hrvoje> _appears_ to be finished, but in reality is far from that.
Hrvoje> (Specifically, there's no alternative for purespace,
Hrvoje> it seems to consume a lot more memory, and
Hrvoje> it seems to be slower.)
Stephen> More pdumper:
>>>> "Troy" == Troy Noble
<troy.noble(a)channelpoint.com> writes in
Stephen>
<03E742431696D311BD1B00062938251703DFA5AB(a)cpex1.channelpoint.com>:
Troy> (setq-default ) on an opaque type doesn't work properly
Troy> after the dumper reloads it into memory.
>>>> "Hrvoje" == Hrvoje Niksic
<hniksic(a)arsdigita.com> writes
Stephen> (on xemacs-review):
Hrvoje> The one good consequence of the core/packages separation
Hrvoje> is that releasing XEmacs is not as hard as it used to be.
Stephen> Are the bad consequences relevant to the issues list, for either
Stephen> fixing or improvement, or is there absolutely nothing that can be done
Stephen> about them without remerging the packages into the core?
Stephen> --
Stephen> University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573
JAPAN
Stephen> Institute of Policy and Planning Sciences Tel/fax: +81 (298)
53-5091
Stephen> _________________ _________________ _________________
_________________
Stephen> What are those straight lines for? "XEmacs rules."
--
Adrian Aichner
mailto:adrianï¼ xemacs.org
http://www.xemacs.org
1:26 p.m.
New subject: Audits and vetos [was: Issues outstanding, redux (summary)]
>>>> "APA" == Adrian Aichner
<adrian(a)xemacs.org> writes:
Stephen> o Audit for synchs and feature additions that don't work
Stephen> with Mule (eg, people have patched/intend to patch
Stephen> smtpmail and ps-print in ways that cause data loss and
Stephen> other wastage under Mule)
APA> smtpmail:
APA> Steve, please don't limit yourself to vetoing and auditing.
I don't. My message that you cited still has 3.5 days left in my
deadline, OK? Getting this right is not an easy thing; mail is a
bitch, and I'm not a mail specialist. Nor is Mule trivial, at least I
know something about that. And I never heard of smtpmail until
Simon's patch the other day, let alone looked at it. Testing it will
be time-consuming, as I have never explicitly specified a mailer
backend for xemacs before; I'll have to figure out how to do that.
Not to mention coming up with a few test cases.
APA> I have offered to patch smtpmail as per your recommendation.
Adrian, I don't know when the current version of smtpmail was checked
in or by whom, but it is BROKEN. Not after Simon's patch. The one
currently being distributed in mail-lib.
Any attempt to send non-ISO-8859-1 characters by smtpmail as it stands
will turn every single one of them into a tilde, to the best of my
knowledge. The fact that we haven't had any bug reports about it
leads me to hope that I've analyzed it incorrectly. Still I am
unwilling to approve a patch until I have reason to believe it doesn't
make things worse than they already are. Adding features that would
attract users to the package is making things worse, unless there are
some safeguards put in place to keep it from doing harm.
The patch you proposed to ps-print would do a similar thing for
printing from Mule; at least ps-print would merely waste paper.
The point is not any particular patch; it's just random luck that the
two cases I know of right now are these two.
But surely there are more of these in the code base by now. I don't
review every patch for Mule implications; maybe I should have, and
I'll start trying to do more, but EVERYTHING on xemacs-patches is a
LOT of traffic. Auditing for this kind of thing is necessary for a
release. People will be VERY angry if they lose mail because of this.
APA> ps-print-nomule:
APA> I almost have a patch for ps-print-nomule ready. I am not
APA> qualified to work in the mule version.
And it will be reviewed for Mule implications even though it is
nominally "non-Mule," and it will be vetoed if it causes problems if
invoked from a Mule XEmacs.
At which point if other reviewers feel that the benefits of the patch
to non-Mule users outweigh the problems for Mule, the veto will be
overridden. That's the way the process is supposed to work.
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
2:08 p.m.
New subject: Issues outstanding, redux (summary)
Adrian Aichner writes:
Is an XEmacs package which hasn't been updated in two years to be
called "maintained"?
Indeed. This is a very demoralizing situation.
Mr. Preprocessor has an ambitious proposal to overhaul XEmacs' GC
mechanism but seems to have lost interest in the pedestrian, boring
task of maintaining dired. Dired-related patches seem to disappear
into the Black Hole of Tuebingen. This certainly de-motivates people
from attempting to make fixes to this code. Michael, if you no longer
have time or volition to maintain this package, how about handing it
off to someone else?
But I fear that it's not just dired which is languishing.
A month or so ago, when I first read Ben Wing's assertion that "XEmacs
is in its death throes" my reaction was "How can he say that?". But
the more I think about it, the more I tend to agree.
What this project needs is strong leadership, of the sort that Steve
Baur provided during the 20.x/21.x cycle. Right now it seems to be
drifting aimlessly, with people making all sorts of destabilizing
changes with no eye toward a release.
Consider the number of hours wasted by new users getting tripped up by
our package system, and by us having to answer their questions ("Well,
see, you have to have some of the packages installed already before
you can use the package system to install packages. Why don't you
just forget about the packages and use the Sumo?"). Or the number of
hours squandered on the massively destabilizing (and dubiously useful)
"gutter" feature? Throw into the mix a partially working portable
dumper which slows things down and introduces subtle new bugs.
Sigh... it's hard to see how any of this is leading in any kind of
postive direction...
I think that it might just be time to push some of the
"not-ready-for-prime-time" features into a new 21.3 version, and try
to get a stable, working 21.2 out the door over the next few months.
I think this would be a shot in the arm for the vitality of this
project.
8773
days inactive
8773
days old
2 comments
3 participants
participants (3)
-
Adrian Aichner -
Charles G Waldman -
Stephen J. Turnbull