12:11 p.m.
XEmacs 21.0 is winding down to a close. The latest scheduled release
date is (7/31[1]). Where do you want to go tomorrow?
Ideally, XEmacs 21.1 is in feature freeze now. There are a ton of
bugs to be fixed. It doesn't necessarily have to be the case, but
it's just my feeling.
I'm personally very pleased with XEmacs 21.0. It does just about
everything I want it to do, and no more.
One possible way is to split the development trees such that we have a
rigidly controlled stable branch (21.x) and a no-holds-barred
development tree.
The biggest problem for a legacy app like Emacs is maintenance. There
are plenty of areas where XEmacs shows its age. Two of which are in
the character/line oriented (re)display and the non-standard Lisp
extension language engine.
I have tentatively approved Michael Sperber's plan for addressing Lisp
Engine updates. As I understand it, it does not involve commitment to
anything specific until all the issues have been hashed out. It will
also involve an extended migration period of at least a year. I'm
less worried about that (so long as there's consensus on where we're
going) since the current development tree has been separated from the
release tree for at least that long.
My *only* goal at this point in time is to maintain the longevity and
vitality of XEmacs. After we've hashed this out a bit I'll take the
discussion to c.e.x.
*All* input is welcome.
Footnotes:
[1] Bonus points for anyone who knows what the significance of that
date is.
1:58 a.m.
>>>> "sb" == SL Baur
<steve(a)vmailer.xemacs.org> writes:
sb> XEmacs 21.0 is winding down to a close. The latest scheduled
sb> release date is (7/31[1]). Where do you want to go tomorrow?
As long as we're wishin'...
Mule should be reincarnated. Ben Wing did a great job of making the
multi-byte-character-oriented text code intelligible, and there's an
immense amount of useful, even essential, LISP-level code.
However something needs to be done about the interface (eg, to avoid
the need for an installed mule-base to build a Mule XEmacs). We also
need to sort out the dependencies among Mule proper, LEIM, and Quail
so that not-yet-fully-supported ports from FSF code (eg, Ethiopian)
don't break XEmacs's ability to build. Although maybe that can be
considered a bug to be sorted out in 21.1.
It would be nice to get Olivier's flavored (1-, 2-, 4-byte) text
objects, with bytes, ISO-8859, UCS-2, and UCS-4 as the internal codes.
sb> Ideally, XEmacs 21.1 is in feature freeze now. There are a
sb> ton of bugs to be fixed. It doesn't necessarily have to be
sb> the case, but it's just my feeling.
Sounds reasonable.
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +1 (298) 53-5091
9:23 a.m.
At 03:26 AM 7/2/98 +0200, Olivier Galibert wrote:
On Mon, Jun 29, 1998 at 09:58:22AM +0900, Stephen J. Turnbull wrote:
> It would be nice to get Olivier's flavored (1-, 2-, 4-byte) text
> objects, with bytes, ISO-8859, UCS-2, and UCS-4 as the internal codes.
I'm still working on that, but writing a PhD takes a *lot* of time :/
Enjoy it while it lasts :)
andy
---------------------------------------------------------------------------
" .sigs are like your face - rarely seen by you and uglier than you think"
Dr Andy Piper, Technical Architect, Parallax Solutions Ltd
mail: andyp(a)parallax.co.uk web: www.parallax.co.uk/~andyp
12:26 p.m.
This file contains a RealAudio attachment. If you can't understand it,
try
http://www.666.com/audio/mail/19980630-5-gsm-8k.wav
SL Baur wrote:
XEmacs 21.0 is winding down to a close. The latest scheduled
release
date is (7/31[1]). Where do you want to go tomorrow?
Ideally, XEmacs 21.1 is in feature freeze now. There are a ton of
bugs to be fixed. It doesn't necessarily have to be the case, but
it's just my feeling.
I'm personally very pleased with XEmacs 21.0. It does just about
everything I want it to do, and no more.
One possible way is to split the development trees such that we have a
rigidly controlled stable branch (21.x) and a no-holds-barred
development tree.
The biggest problem for a legacy app like Emacs is maintenance. There
are plenty of areas where XEmacs shows its age. Two of which are in
the character/line oriented (re)display and the non-standard Lisp
extension language engine.
I have tentatively approved Michael Sperber's plan for addressing Lisp
Engine updates. As I understand it, it does not involve commitment to
anything specific until all the issues have been hashed out. It will
also involve an extended migration period of at least a year. I'm
less worried about that (so long as there's consensus on where we're
going) since the current development tree has been separated from the
release tree for at least that long.
My *only* goal at this point in time is to maintain the longevity and
vitality of XEmacs. After we've hashed this out a bit I'll take the
discussion to c.e.x.
*All* input is welcome.
Footnotes:
[1] Bonus points for anyone who knows what the significance of that
date is.
--
Ben Wing
- If this message is long and typed, someone else typed it for me
- If it has a .rm (RealAudio) attachment, see
http://www.real.com/products/player/downloadrealplayer.html?wp=dl0498
- If this doesn't work and there's a GSM WAV attachment, see
http://xanim.va.pubnix.com/home.html
2:24 a.m.
On Sun, Jun 28, 1998 at 04:11:40AM -0700, SL Baur wrote:
I have tentatively approved Michael Sperber's plan for addressing
Lisp
Engine updates. As I understand it, it does not involve commitment to
anything specific until all the issues have been hashed out. It will
also involve an extended migration period of at least a year. I'm
less worried about that (so long as there's consensus on where we're
going) since the current development tree has been separated from the
release tree for at least that long.
Just to put some gasoline on the fire, what about and ILU-like
approach to extension language independence ?
ftp://ftp.parc.xerox.com/pub/ilu/ilu.html
We could have Common lisp, Java, Scheme and Perl simultaneously ;-)
OG.
PS: I think XEmacs is too old for such an approach, but anyway, the
idea is fun.
5:05 p.m.
I never replied to this:
at 04:11 AM 6/28/98 -0700, SL Baur wrote:
XEmacs 21.0 is winding down to a close. The latest scheduled release
date is (7/31[1]). Where do you want to go tomorrow?
Ideally, XEmacs 21.1 is in feature freeze now. There are a ton of
bugs to be fixed. It doesn't necessarily have to be the case, but
it's just my feeling.
I would prefer for feature freeze to be relaxed for features that don't
exist under mswindows but do under X. If the final output of the 21.x
schedule is an mswindows editor that is virtually identical to the X
version I would be happy.
I'm personally very pleased with XEmacs 21.0. It does just about
everything I want it to do, and no more.
It does more than I believed possible back in January ;)
One possible way is to split the development trees such that we have a
rigidly controlled stable branch (21.x) and a no-holds-barred
development tree.
cvs should make this easy.
The biggest problem for a legacy app like Emacs is maintenance. There
are plenty of areas where XEmacs shows its age. Two of which are in
the character/line oriented (re)display and the non-standard Lisp
extension language engine.
1. I would primarily like to see some *much* flashier graphic support in
XEmacs. The sad fact is that flashness is going to sell it to new users
followed by useability. That's what sets XEmacs apart from FSFmacs IMHO. To
that end here are some random thoughts:
1a) Pixel based tab stops. We have to have these to support proportional
width fonts properly. I petitioned Chuck to do it but I think he got pulled
onto other things before he could look at it.
1b) Columns, or text areas or linked buffers. Basically someway of keeping
text in certain areas of the screen. Even allowing scrollbar linkage of
side-by-side buffers would probably suffice.
1c) General frame-based rather than buffer based graphics display. Maybe
done by overlaying frame graphics over buffer graphics. This would allow us
to add cool stuff to the look and feel of frames and do precise graphics in
a frame (char pos based graphics is a bit hit and miss). Even better if we
had 1b so that we could keep text out of the graphics areas.
1d) Proper sub-window support including widgets in buffers - i.e. so that
you could embed proper toolkit-based scrollbars, buttons, toolbars,
selection boxes etc in a buffer. widget.el is ok but pretty limited.
1e) gif animation.
2) I've mentioned CORBA support ;) It would be nice to browse the name
service, say, with dired. A proper lisp binding would allow cool debugging
of CORBA services.
3) unify url base file finding. So for instance you could type in:
ftp://somehost/
or
http://somehost/
or
iiop://somehost/
maybe someone has done this already?
That's all! ;)
andy
---------------------------------------------------------------------------
" .sigs are like your face - rarely seen by you and uglier than you think"
Dr Andy Piper, Technical Architect, Parallax Solutions Ltd
mail: andyp(a)parallax.co.uk web: www.parallax.co.uk/~andyp
5:49 p.m.
Andy Piper wrote:
1a) Pixel based tab stops. We have to have these to support
proportional
width fonts properly. I petitioned Chuck to do it but I think he got pulled
onto other things before he could look at it.
I've also advocated this in the past. In a Mule XEmacs, there's no
such thing as a monospaced font (consider VM's summary buffer when a
name contains Japanese characters).
Also, allowing text to be truncated to the next tab stop would be
useful, so that you can display tables easily.
1d) Proper sub-window support including widgets in buffers - i.e. so
that
you could embed proper toolkit-based scrollbars, buttons, toolbars,
selection boxes etc in a buffer. widget.el is ok but pretty limited.
This would also be very useful.
One question that crosses my mind is whether an XEmacs window should
actually be a distinct widget. Presently, each frame consists of a
single window, with scrollbars embedded within it. The `windows' are
just the areas of a single window which aren't occupied by some other
widget.
--
Glynn Clements <glynn(a)sensei.co.uk>
3:06 a.m.
Glynn Clements writes:
Andy Piper wrote:
> 1a) Pixel based tab stops. We have to have these to support proportional
> width fonts properly. I petitioned Chuck to do it but I think he got pulled
> onto other things before he could look at it.
I've also advocated this in the past. In a Mule XEmacs, there's no
such thing as a monospaced font (consider VM's summary buffer when a
name contains Japanese characters).
I would like to second (third?) this most excellent suggestion... for
me, lack of proper support for proportional fonts is one of the most
major (and highly visible) flaws in XEmacs.
Pixel-based tab stops, and fixing the support for fonts in Customize
(which seems seriously screwed-up) would be so much more
bang-for-the-buck than changing the Lisp engine.
Personally, I think giving up Elisp, over which we (I mean, you guys)
have complete control, could turn out to be a disaster. What happens
when you have technical disagreements with, or simply different
objectives than, the maintainers of the "independently maintained"
lisp substrate?
Just my $0.002, don't want to fan the flames any more on this red-hot
subject...
5:28 a.m.
>>>> "Glynn" == Glynn Clements
<glynn(a)sensei.co.uk> writes:
Glynn> Andy Piper wrote:
> 1a) Pixel based tab stops. We have to have these to support
proportional
> width fonts properly. I petitioned Chuck to do it but I think he got pulled
> onto other things before he could look at it.
Glynn> I've also advocated this in the past. In a Mule XEmacs, there's no
Glynn> such thing as a monospaced font (consider VM's summary buffer when a
Glynn> name contains Japanese characters).
That's not completely true. If the Kanji characters are in a font
exactly twice as wide as the ASCII characters, and lisp code uses
(char-width) properly, then display of column-oriented buffers should
be correct. So perhaps VM's lisp code could be more careful. The key
thing is that it is wrong to assume that inserting one character
increases the current column by one.
Many Japanese users have their fonts set up so that this 2:1 width
ratio holds.
Martin
5:41 a.m.
Martin Buchholz writes:
>>>>> "Glynn" == Glynn Clements
<glynn(a)sensei.co.uk> writes:
Glynn> Andy Piper wrote:
>> 1a) Pixel based tab stops. We have to have these to support proportional
>> width fonts properly. I petitioned Chuck to do it but I think he got pulled
>> onto other things before he could look at it.
Glynn> I've also advocated this in the past. In a Mule XEmacs, there's no
Glynn> such thing as a monospaced font (consider VM's summary buffer when a
Glynn> name contains Japanese characters).
That's not completely true. If the Kanji characters are in a font
exactly twice as wide as the ASCII characters, and lisp code uses
(char-width) properly, then display of column-oriented buffers should
be correct. So perhaps VM's lisp code could be more careful. The key
thing is that it is wrong to assume that inserting one character
increases the current column by one.
I tried it a while ago. It didn't work because the pixel width
of wide chars (such as the Kanji glyphs) were not even multiples
of the default face's font width. So the text was truncated
incorrectly and the columns were messed up. I didn't know about
glyph-width at the time. Using that would probably work better.
5:52 a.m.
>>>> "Kyle" == Kyle Jones
<kyle_jones(a)wonderworks.com> writes:
Kyle> Martin Buchholz writes:
> >>>>> "Glynn" == Glynn Clements
<glynn(a)sensei.co.uk> writes:
>
Glynn> Andy Piper wrote:
> >> 1a) Pixel based tab stops. We have to have these to
support proportional
> >> width fonts properly. I petitioned Chuck to do it but I think he got pulled
> >> onto other things before he could look at it.
>
Glynn> I've also advocated this in the past. In a Mule XEmacs,
there's no
Glynn> such thing as a monospaced font (consider VM's summary buffer when a
Glynn> name contains Japanese characters).
>
> That's not completely true. If the Kanji characters are in a font
> exactly twice as wide as the ASCII characters, and lisp code uses
> (char-width) properly, then display of column-oriented buffers should
> be correct. So perhaps VM's lisp code could be more careful. The key
> thing is that it is wrong to assume that inserting one character
> increases the current column by one.
Kyle> I tried it a while ago. It didn't work because the pixel width
Kyle> of wide chars (such as the Kanji glyphs) were not even multiples
Kyle> of the default face's font width. So the text was truncated
Kyle> incorrectly and the columns were messed up. I didn't know about
Kyle> glyph-width at the time. Using that would probably work better.
Since the 2:1 ratio is REALLY important to many Japanese users (with
any application), they tend to use *jis0201 fonts for ASCII, and the
equivalent *jis0208 fonts for Kanji. These fonts seem to always come
in pairs which have a 2:1 width ratio. Implementing the following was
a condition of my continued employment at Sun.
`x-use-halfwidth-roman-font' is a compiled Lisp function
-- loaded from "/home/martin/x/mule-packages/lisp/mule-base/mule-x-init.elc"
(x-use-halfwidth-roman-font FULLWIDTH-CHARSET ROMAN-REGISTRY)
Documentation:
Maybe set charset registry of the 'ascii charset to ROMAN-REGISTRY.
Do this only if:
- the current display is an X device
- the displayed width of FULLWIDTH-CHARSET is twice the displayed
width of the 'ascii charset, but only when using ROMAN-REGISTRY.
Traditionally, Asian characters have been displayed so that they
occupy exactly twice the screen space of ASCII (`halfwidth')
characters. On many systems, e.g. Sun CDE systems, this can only be
achieved by using a national variant roman font to display ASCII.
Martin
9638
days inactive
9644
days old
11 comments
9 participants
participants (9)
-
Andy Piper -
Ben Wing -
Charles G Waldman -
Glynn Clements -
Kyle Jones -
Martin Buchholz -
Olivier Galibert -
SL Baur -
Stephen J. Turnbull