================================================================
Dear Bug Team!
Over the past week, I have migrated to a new platform: Solaris
10 on AMD64. It has been pretty smooth. However, I think there
is a bug in Save Options (or I don't understand it). On the
options menu, I chose a Font and Font Size. But, when I restart
xemacs, this choice is not brought in and I have do it again.
Here's what custom.el looks like:
(custom-set-variables)
(custom-set-faces
'(default ((t (:size "18pt" :family "Lucidatypewriter"))) t))
Am I doing something wrong or is it xemacs-beta?
Thanks,
Rodney

Rodney Sparapani wrote:
> ================================================================
> Dear Bug Team!
>
> Over the past week, I have migrated to a new platform: Solaris
> 10 on AMD64. It has been pretty smooth. However, I think there
> is a bug in Save Options (or I don't understand it). On the
> options menu, I chose a Font and Font Size. But, when I restart
> xemacs, this choice is not brought in and I have do it again.
> Here's what custom.el looks like:
>
> (custom-set-variables)
> (custom-set-faces
> '(default ((t (:size "18pt" :family "Lucidatypewriter")))
t))
>
> Am I doing something wrong or is it xemacs-beta?
>
> Thanks,
>
> Rodney
Hi Gang:
Apparently this is a bug in beta. The behavior in stable is as
anticipated.
Thanks,
Rodney

For me, user-init-file is nil. Shouldn't that be set to something?
If you set it correctly (with a trailing directory character), then
beta will save your settings, but it does not read them back in when you
restart XEmacs. I tried to update this bug report. But, it crashed
like this:

Oh wait. I get it. user-init-file is supposed to be nil unless set
via the command-line, right? The documentation for this variable is
extremely terse. In any case, to rephrase the bug report. It's not
Save Options that does not work. The Options are in fact Saved.
However, for beta, they are never Restored (is that what it is called).
And, the bonus bug is the crash from the tracker.
Rodney
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

And it's in ~/.xemacs/init.el? Did you try loading it with the Load
Init Files button? If not, would you try that? If that works, I'm
really not sure what might be going wrong. Mike, any ideas?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Rodney Sparapani writes:
> > Please invoke xemacs -vanilla, then evaluate `(find-user-init-file)'.
> >
> So, user-init-file is still nil, but
In xemacs -vanilla, it should be nil.
> (find-user-init-file)
>
> does find it.
And it's in ~/.xemacs/init.el? Did you try loading it with the Load
Init Files button? If not, would you try that? If that works, I'm
really not sure what might be going wrong. Mike, any ideas?

> And it's in ~/.xemacs/init.el? Did you try loading it with
the Load
> Init Files button? If not, would you try that? If that works, I'm
> really not sure what might be going wrong. Mike, any ideas?
>
No, it's loaded. But custom.el is not loaded.

What's the value of `custom-file'? Could you do an edebug on
`load-user-init-file' and see what happens with the bit that's supposed
to load `custom-file'?
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Michael Sperber wrote:
> What's the value of `custom-file'? Could you do an edebug on
> `load-user-init-file' and see what happens with the bit that's supposed
> to load `custom-file'?
>
Very strange. custom-file is nil. However, load-user-init-file works
around that, identifies the correct file, loads it, but the customization
never occurs?!?

Michael Sperber wrote:
> So, just to make sure I understand, it's really the code saved into
> ~/.xemacs/custom.el that doesn't work? I.e. it doesn't have an effect
> if you load it via, say, M-x load-file?
>
That's right. It does not have an effect.

there's a bug in the tracker that I haven't been able to work on yet.
For some reason it is not providing full email addresses for the user,
probably when issues are submitted by email (I think the web interface
for registering does check this). This bug is issue325 in the tracker.
I've fixed the nost list of issue411 to refer to your fully registered
user 'rsparapa', so this error will not occur here again.
I think you can actually do this yourself by editing the nosy list.
You can just delete any nosy user that appears in such a traceback, as
they can't get mail anyway.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

In general, please report tracker tracebacks as new tracker bugs,
not
under the issue where they appeared.
For the particular case of "couldn't send email" like this:

Sorry, that was my bad. But, I'm having difficult finding bugs.
For example I had an awful time finding Issue 411. Search for
save doesn't find it, neither does option, but options works:
(the title is Save Options Doesn't Work?). I guess that is
another tracker bug that I should report, right?
But, I'm wondering if this tracker is worth it. Now, we have to
add tracker bugs (and fix them) which are added burdens. Also, I
haven't seen a lot of activity on the bugs that I have posted.
Believe me, I know all about free software so I wasn't expecting a
rose garden. However, I'm sort of anti-tracker at the moment.
--
Rodney Sparapani Center for Patient Care & Outcomes Research (PCOR)
Sr. Biostatistician http://www.mcw.edu/pcor
4 wheels good, 2 wheels better! Medical College of Wisconsin (MCW)
WWLD?: What Would Lombardi Do? Milwaukee, WI, USA
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

But, I'm wondering if this tracker is worth it. Now, we have to
add tracker bugs (and fix them) which are added burdens.

Fixing most of them is not a big deal when I get around to it (try
using the search screen from the sidebar and setting module to
tracker, group on status, sort descending on activity). Whether to
report them or not is up to you. I hope you will.

Also, I haven't seen a lot of activity on the bugs that I have
posted.

Agreed, you're not going to see much activity on your bugs, but I
don't think that should be considered a tracker problem. That's an
issue of developer time, which has been scarce recently.
Try searching on status=closed, with reason displayed and status
omitted. That will give you some sense of the activity (you can
ignore the "superseded" bugs since they're almost all dupes of one
sort or another, but the rest required some sort of developer
activity). If nothing else, that's one benefit of the tracker.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

================================================================
Dear Bug Team!
Over the past week, I have migrated to a new platform: Solaris
10 on AMD64. It has been pretty smooth. However, I think there
is a bug in Save Options (or I don't understand it). On the
options menu, I chose a Font and Font Size. But, when I restart
xemacs, this choice is not brought in and I have do it again.
Here's what custom.el looks like:
(custom-set-variables)
(custom-set-faces
'(default ((t (:size "18pt" :family "Lucidatypewriter"))) t))
Am I doing something wrong or is it xemacs-beta?

What does M-x customize-face RET default RET claim immediately after
startup?
Are you using Xft or a straight X build? If Xft, is Lucidatypewriter
available in a scalable font on your host?
FWIW, I suspect this is an XEmacs bug. The menus have never been
properly refactored for Xft.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

What does M-x customize-face RET default RET claim immediately after
startup?
Are you using Xft or a straight X build? If Xft, is Lucidatypewriter
available in a scalable font on your host?
FWIW, I suspect this is an XEmacs bug. The menus have never been
properly refactored for Xft.

I like Xft and use it myself but didn’t enable it in the openSUSE
package because there are still quite a few problems and maybe not
everybody likes it.
Therefore, quite a while ago, I asked Stephen whether one could choose
between Xft and X11 core fonts in XEmacs at runtime. Unfortunately,
this is not (yet) possible.
But maybe I could make Xft easily accessible for all users of the
openSUSE packages by building XEmacs twice, once with Xft disabled and
once with Xft enabled.
Probably everything except the binary and the dump files is the same for
both types of build, is that correct?
In that case I would need only about 22 M to offer an xemacs-xft
RPM-package which could contain a binary /usr/bin/xemacs-xft
and its dump file and require the main xemacs RPM package:
mfabian＠magellan:~$ ll /usr/bin/xemacs* -h
-rwxr-xr-t 1 root root 11M 2008-06-09 03:59 /usr/bin/xemacs*
-rw-r--r-- 1 root root 11M 2008-06-09 03:59 /usr/bin/xemacs-21.5-b28-4845e342.dmp
mfabian＠magellan:~$
--
Mike FABIAN <mfabian(a)suse.de&gt; http://www.suse.de/~mfabian
睡眠不足はいい仕事の敵だ。
I � Unicode
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

I like Xft and use it myself but didn’t enable it in the openSUSE
package because there are still quite a few problems and maybe not
everybody likes it.
Therefore, quite a while ago, I asked Stephen whether one could choose
between Xft and X11 core fonts in XEmacs at runtime. Unfortunately,
this is not (yet) possible.

Yeah, I tried to implement this. It requires a refactoring of the
console/device code which I was unable to do workably at the time.

Rodney Sparapani <rsparapa(a)mcw.edu&gt; さんは書きました:
> I gave up on Xft.
I like Xft and use it myself but didn’t enable it in the openSUSE
package because there are still quite a few problems and maybe not
everybody likes it.
Therefore, quite a while ago, I asked Stephen whether one could choose
between Xft and X11 core fonts in XEmacs at runtime. Unfortunately,
this is not (yet) possible.

Hmm, it isn't enough to disable Xft with --with-xft=no?
I'm also considering turning off Xft (with --with-xft=no) in the Gentoo
ebuild that I want to move to the main Gentoo repository shortly.
Kind regards,
Hans
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

On Fri, 13 Jun 2008 16:02:30 +0200, Mike FABIAN wrote:
> Rodney Sparapani <rsparapa(a)mcw.edu&gt; さんは書きました:
>
>> I gave up on Xft.
>
> I like Xft and use it myself but didn’t enable it in the openSUSE
> package because there are still quite a few problems and maybe not
> everybody likes it.
>
> Therefore, quite a while ago, I asked Stephen whether one could choose
> between Xft and X11 core fonts in XEmacs at runtime. Unfortunately,
> this is not (yet) possible.
Hmm, it isn't enough to disable Xft with --with-xft=no?

But then you *cannot* use Xft.
And if you enable it with ‘--with-xft=yes’ you can use *only*
Xft and no X11 core fonts anymore.
It would be better to be able to choose this not at compile time but at
runtime.

> Hmm, it isn't enough to disable Xft with --with-xft=no?
But then you *cannot* use Xft.
And if you enable it with ‘--with-xft=yes’ you can use *only* Xft and no
X11 core fonts anymore.
It would be better to be able to choose this not at compile time but at
runtime.

Aha, I didn't pick up on the fact that you were talking about runtime.
This also explains my horrible experience with Xft, I just didn't pick up
on this fact when I tested it and was annoyed that XEmacs wouldn't use my
favorite bitmapped fontset anymore. I guess I'll have to try again using
the Xft font names this time.

With Gentoo USE flags we can let the users decide if they want xft, so we
could be a bit more flexible here. I think I'll do a bit more testing and
probably leave the functionality as a USE flag for our users.
Kind regards,
Hans
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

On Thu, 19 Jun 2008 12:16:46 +0200, Mike FABIAN wrote:
> Hans de Graaff <graaff(a)gentoo.org&gt; さんは書きました:
>> Hmm, it isn't enough to disable Xft with --with-xft=no?
>
> But then you *cannot* use Xft.
>
> And if you enable it with ‘--with-xft=yes’ you can use *only* Xft and no
> X11 core fonts anymore.
>
> It would be better to be able to choose this not at compile time but at
> runtime.
Aha, I didn't pick up on the fact that you were talking about runtime.
This also explains my horrible experience with Xft, I just didn't pick up
on this fact when I tested it and was annoyed that XEmacs wouldn't use my
favorite bitmapped fontset anymore. I guess I'll have to try again using
the Xft font names this time.

Most bitmap fonts can be used via Xft as well (as long as they are
Latin1 or Unicode fonts). I.e. even with Xft you can get (almost) the
same look of your XEmacs using almost the same bitmap fonts as with X11
core fonts. But the setup is different and the font names are different.
And it will be somewhat slower.
--
Mike FABIAN <mfabian(a)suse.de&gt; http://www.suse.de/~mfabian
睡眠不足はいい仕事の敵だ。
I � Unicode
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Hi Hans
You wrote:
Hans> With Gentoo USE flags we can let the users decide if they want
Hans> xft, so we could be a bit more flexible here. I think I'll do a
Hans> bit more testing and probably leave the functionality as a USE
Hans> flag for our users.
That sound good. Some words on how to do the transition to xft will probably
do a lot of good I think. I spent some hours with that the first time
anyway.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

That sound good. Some words on how to do the transition to xft will
probably
do a lot of good I think. I spent some hours with that the first time
anyway.

That can be done easily with a post-install message, possibly referring
to an upgrade guide. I think it would be useful to have such an upgrade
guide in general. The etc/NEWS file of xemacs 21.5.x contains a little
bit of information about it, but I think this could be expanded on.
Kind regards,
Hans
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

That can be done easily with a post-install message, possibly
referring
to an upgrade guide. I think it would be useful to have such an upgrade
guide in general. The etc/NEWS file of xemacs 21.5.x contains a little
bit of information about it, but I think this could be expanded on.

Mike FABIAN writes:
> It would be better to be able to choose this not at compile time
> but at runtime.
I might add that GNU is trying to do that, and they're having a
horrible time.

You have chosen the right conjunction, namely "and" rather than "so".
I don't think that the runtime selectability/order per se is that
problematic. It is more like the interface for this selectability is
not really good for customization (but then the same holds for startup
fonts and startup geometry and a few other things that you better do via
X resources).
There are quite a few rough edges being smoothed out concerning font
setup in Emacs right now, yes. But runtime/compiletime is really just a
minor wrinkle in the mess: rather it is the new font selection code all
in all that needs ironing out.
And "horrible time" is an exaggeration, I think.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

>> Therefore, quite a while ago, I asked Stephen whether one
could choose
>> between Xft and X11 core fonts in XEmacs at runtime. Unfortunately,
>> this is not (yet) possible.
>
> Hmm, it isn't enough to disable Xft with --with-xft=no?
But then you *cannot* use Xft.
And if you enable it with ‘--with-xft=yes’ you can use *only*
Xft and no X11 core fonts anymore.

Mike FABIAN wrote:
> >> Therefore, quite a while ago, I asked Stephen whether one could choose
> >> between Xft and X11 core fonts in XEmacs at runtime. Unfortunately,
> >> this is not (yet) possible.
> >
> > Hmm, it isn't enough to disable Xft with --with-xft=no?
>
> But then you *cannot* use Xft.
>
> And if you enable it with ‘--with-xft=yes’ you can use *only*
> Xft and no X11 core fonts anymore.
Which, AFAICT, precludes connecting to an X server which doesn't
support the RENDER extension.

No, Xft works also on X servers which don’t support the RENDER
extension (Xft1 didn’t but that was long ago).
It is slightly slower on X servers which don’t support the RENDER
extension but not so slow that I really notice.
--
Mike FABIAN <mfabian(a)suse.de&gt; http://www.suse.de/~mfabian
睡眠不足はいい仕事の敵だ。
I � Unicode
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

It is slightly slower on X servers which don't support the
RENDER
extension but not so slow that I really notice.

I find it to be perceptibly slower over even a 100MB network; YMMV. I
agree this is not a reason to avoid it at this stage, as Xft is
unbearably slow over the net.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

I'm also considering turning off Xft (with --with-xft=no) in the
Gentoo
ebuild that I want to move to the main Gentoo repository shortly.

XEmacs without anti-aliased fonts looks horrendously ugly, IMHO, and I
can't think of an application that doesn't use anti-aliased fonts.
Maybe vi? (OK, OK, cheap shot, I retract the slur.)
I use Xft all the time, and have done so with both 21.4 and 21.5, but
I use non-standard configure options:
$ ./configure \
--with-xft=emacs,menubars,tabs,gauges \
--with-gnome \
--with-mule=no \
--with-package-path=/usr/local/lib/xemacs/xemacs-packages
Note (unless these have been fixed): "--with-xft=yes" does not do the
same as what I use even though it appears to, and "--with-gtk" doesn't
do anything, which is why I haven't included it.
A caveat: Although I get anti-aliased fonts with the above, I don't
always get the fonts I specify. Bold fonts, in particular, are
problematic, and show up larger than they should.
--- Vladimir
--
Vladimir G. Ivanovic
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

XEmacs without anti-aliased fonts looks horrendously ugly, IMHO, and
I
can't think of an application that doesn't use anti-aliased fonts.

GNU Emacs is one. If you want to know why people are reluctant to
default to Xft, skim the last couple of months of emacs-devel.
XEmacs's implementation of anti-aliased fonts is probably in no better
shape.

I use Xft all the time, and have done so with both 21.4 and 21.5, but
I use non-standard configure options:
$ ./configure \
--with-xft=emacs,menubars,tabs,gauges \
--with-gnome \
--with-mule=no \
--with-package-path=/usr/local/lib/xemacs/xemacs-packages
Note (unless these have been fixed): "--with-xft=yes"

This hasn't been fixed, it's on my list, but every time I feel up to
working on configure, autocrap releases again, and I'm *forced* to
work on it, after which I have no appetite for working on it.

Just to provide feedback here: these options use GNOME 1.x and GTK+-1.x,
both of which are deprecated in Gentoo. We no longer offer these options
for XEmacs as part of the installation.
Kind regards,
Hans
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

default to Xft, skim the last couple of months of emacs-devel.
XEmacs's implementation of anti-aliased fonts is probably in no better
shape.
> I use Xft all the time, and have done so with both 21.4 and 21.5, but
> I use non-standard configure options:
>
> $ ./configure \
> --with-xft=emacs,menubars,tabs,gauges \
> --with-gnome \
> --with-mule=no \
> --with-package-path=/usr/local/lib/xemacs/xemacs-packages
>
> Note (unless these have been fixed): "--with-xft=yes"
This hasn't been fixed, it's on my list, but every time I feel up to
working on configure, autocrap releases again, and I'm *forced* to
work on it, after which I have no appetite for working on it.

> "--with-gtk" doesn't do anything
It is implied by --with-gnome. Specifying --with-gnome enforces
--with-gtk.
> A caveat: Although I get anti-aliased fonts with the above, I don't
> always get the fonts I specify. Bold fonts, in particular, are
> problematic, and show up larger than they should.
Patches welcome.

> This hasn't been fixed, it's on my list, but every time I
feel up to
> working on configure, autocrap releases again, and I'm *forced* to
> work on it, after which I have no appetite for working on it.
CMake? SCons?

Vladimir> CMake? SCons?
Both of these build systems seems to have interesting features
indeed. However, isn't both lacking in the respect that the end user,
eg the user building XEmacs from sources, needs to have them?
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

>>>>> Vladimir wrote:
Vladimir> CMake? SCons?
Both of these build systems seems to have interesting features
indeed. However, isn't both lacking in the respect that the end user,
eg the user building XEmacs from sources, needs to have them?

The build requirements are really not that onerous. I don't have any
experience with either system, so I don't speak authoritatively and
I'm not pushing either option, but here's what I've found out:
SCons depends on just Python (already installed in all Linux
distributions) and CMake has no additional requirements. Both systems
are available pre-packaged for Gentoo, Fedora 9, Debian/Ubuntu and
apparently cygwin, so the overhead for a person wishing to build an
XEmacs that would use them is not high. I don't know about
pre-packaged versions for Windows or Mac OS X, but both claim to run
and build (natively) for those environments.
The tradeoff seems to be XEmacs build maintainer time (and sanity) vs
a small, possibly zero, user/builder overhead. (It turns out that both
were installed on my Gentoo and Fedora systems.) Since I'm not the
XEmacs build maintainer, officially I don't care.
That being said, I'm partial to the idea of replacing a build
environment based on make and autotools. As a person with a passing
interest in programming languages, I'd prefer SCons because it uses
Python, a full-fledged, modern, widely-used, multi-paradigm,
programming environment that comes with many, many libraries with even
more available as add-ons.
But, as I said, I'll defer to those who are directly affected by the
choice of build system: it's not my call (just as Mercurial wasn't).
--- Vladimir
--
Vladimir G. Ivanovic
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

on 06/28/2008 04:20 PM Mats Lidell said the following:
>>>>>> Vladimir wrote:
>
> Vladimir> CMake? SCons?
>
> Both of these build systems seems to have interesting features
> indeed. However, isn't both lacking in the respect that the end user,
> eg the user building XEmacs from sources, needs to have them?
The build requirements are really not that onerous. I don't have any
experience with either system, so I don't speak authoritatively and I'm
not pushing either option, but here's what I've found out:
SCons depends on just Python (already installed in all Linux
distributions) and CMake has no additional requirements. Both systems
are available pre-packaged for Gentoo, Fedora 9, Debian/Ubuntu and
apparently cygwin, so the overhead for a person wishing to build an
XEmacs that would use them is not high. I don't know about pre-packaged
versions for Windows or Mac OS X, but both claim to run and build
(natively) for those environments.
The tradeoff seems to be XEmacs build maintainer time (and sanity) vs a
small, possibly zero, user/builder overhead. (It turns out that both
were installed on my Gentoo and Fedora systems.) Since I'm not the
XEmacs build maintainer, officially I don't care.
That being said, I'm partial to the idea of replacing a build
environment based on make and autotools. As a person with a passing
interest in programming languages, I'd prefer SCons because it uses
Python, a full-fledged, modern, widely-used, multi-paradigm, programming
environment that comes with many, many libraries with even more
available as add-ons.
But, as I said, I'll defer to those who are directly affected by the
choice of build system: it's not my call (just as Mercurial wasn't).
--- Vladimir

Is this a serious consideration? As a Solaris and OS X user, I have
often struggled with the autotools. It seems like most free software
assumes linux. And, the autotools suffer from the same bias. Having
said that, I've become pretty good at debugging the autotools and
building almost everything that I have tried on both of my platforms
(with a few notable exceptions, subversion being one of them, what is
with all of those dependencies?!?).
So, I have very mixed feelings about this proposal. On the one hand,
I'd be delighted to never have to debug the autotools again. On the
other hand, I don't know python nor cmake. Maybe there should be a
transitional period? For the record, both python and cmake are
available for Solaris as binary packages so that should not be an issue
(and subversion is also available now, thank god). I haven't
investigated binary packages on OS X recently so maybe someone else can
fill us in.
Rodney
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

The build requirements are really not that onerous. I don't have
any
experience with either system, so I don't speak authoritatively and I'm not
pushing either option, but here's what I've found out:
SCons depends on just Python (already installed in all Linux distributions)
and CMake has no additional requirements. Both systems are available
pre-packaged for Gentoo, Fedora 9, Debian/Ubuntu and apparently cygwin, so
the overhead for a person wishing to build an XEmacs that would use them is
not high. I don't know about pre-packaged versions for Windows or Mac OS X,
but both claim to run and build (natively) for those environments.
The tradeoff seems to be XEmacs build maintainer time (and sanity) vs a
small, possibly zero, user/builder overhead. (It turns out that both were
installed on my Gentoo and Fedora systems.) Since I'm not the XEmacs build
maintainer, officially I don't care.
That being said, I'm partial to the idea of replacing a build environment
based on make and autotools. As a person with a passing interest in
programming languages, I'd prefer SCons because it uses Python, a
full-fledged, modern, widely-used, multi-paradigm, programming environment
that comes with many, many libraries with even more available as add-ons.
But, as I said, I'll defer to those who are directly affected by the choice
of build system: it's not my call (just as Mercurial wasn't).

I have used scons. My experience was that it was very good at
eliminating lots of mess and confusion for the features of autotools +
Makefile that it supports out of the box. The problem I had is that
it didn't support everything I needed out of the box. That left me
with the necessity of writing a bunch of Python code. I eventually
gave up and went back to autotools + Makefile.
On the other hand, the stuff I needed that scons did not support out
of the box is not needed by the XEmacs build system, either. It is
possible that it could simplify our build system. We won't know until
somebody tries. I doubt this proposal will go anywhere unless
somebody steps up to the plate and demonstrates a fully (or at least
mostly) functional replacement build system.
--
Jerry James
http://loganjerry.googlepages.com/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

2008/6/28 Vladimir G. Ivanovic <vgivanovic(a)comcast.net&gt;:
> The build requirements are really not that onerous. I don't have any
> experience with either system, so I don't speak authoritatively and I'm not
> pushing either option, but here's what I've found out:

As a mere user who builds his own copy of xemacs, I don't want to have
to learn another build system and download yet another set of packages
(that I would have to build myself[1]) just so I can build xemacs.
But if a new build system really helps the main developers, then go
ahead. I'll either bite the bullet, or just start using precompiled
binaries.
Ray
[1] Prebuilt things tend to go where I don't have write privileges, and
getting the IT guys to do it takes forever, and then it ends up being
available on only one machine, which is almost never what I want.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Vladimir> The build requirements are really not that onerous.
No, not onerous but still different. So it is a matter of what matters
most: having a slightly nonstandard build system or struggling with
the standard that everyone already has. The burden on the maintainer
vs the ease of the user!?
Vladimir> [...]
Vladimir> I'd prefer SCons ....
SCons sounds interesting enough so I'll give it a test just to see
what it can do.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

It does use antialiased fonts nowadays in the development version. But
frankly, I don't think them a substantial improvement over 10x20 (quite
a nice bitmap font). A good hand-designed pixel font makes the best use
of screen contrast. I agree that digitized outlines suck for that
purpose and antialiasing helps.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

I really don't think those are going to be much help. Agreed,
autoconf is a really crufty technology from the point of view of a
build system, but its database of platform quirks is still unmatched
AFAIK.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

I use Xft all the time, and have done so with both 21.4 and 21.5, but
I
use non-standard configure options:
$ ./configure \
--with-xft=emacs,menubars,tabs,gauges \ --with-gnome \
--with-mule=no \
--with-package-path=/usr/local/lib/xemacs/xemacs-packages

Yes, the current Gentoo xemacs ebuild (in our xemacs overlay) uses the
same --with-xft settings. Given the feedback on the list I think I'll
leave Xft as an option controlled by a USE flag.
Kind regards,
Hans
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

on 06/26/2008 10:35 PM Hans de Graaff said the following:
>On Thu, 26 Jun 2008 10:09:42 -0700, Vladimir G. Ivanovic wrote:
>It's a matter of picking the right font. My XEmacs without Xft looks
>quite nice even compared to the other anti-aliased applications.
Which fonts do you use?

-adobe-courier-medium-r-normal--10-100-75-75-m-60-iso8859-15
at least for me, on a 1600x1200 screen. At such a font size, I
personally find that the fuzzyness that anti-aliasing adds impairs
readability. The high-frequency edges are necessary when a lowercase
'e' fits in 5x5 pixels.
OG.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

on 06/26/2008 10:35 PM Hans de Graaff said the following:
> On Thu, 26 Jun 2008 10:09:42 -0700, Vladimir G. Ivanovic wrote: It's a
> matter of picking the right font. My XEmacs without Xft looks quite
> nice even compared to the other anti-aliased applications.
Which fonts do you use?

Vladimir> Which fonts do you use?
This is my .Xresources (If everything actually has a meaning in there
I'm not sure but this is what I came up with when I switched over to
Xft.)
----------------------------------------------------------------------
!! For xft enabled XEmacs
XEmacs*Tabs.fcFontName: Arial-6
XEmacs*menubar*xftFont: Arial-6
XEmacs.modeline.attributeFont: Arial-9
XEmacs.default.attributeFont: monospace-11
XEmacs.scrollBarWidth: 12
*popup*xftFont: Arial-6
*menubar*FontSet: -*-helvetica-bold-r-*-*-*-80-*-*-*-*-iso8859-*
XEmacs*Dialog*Font: -*-helvetica-bold-r-*-*-*-80-*-*-*-*-iso8859-*
----------------------------------------------------------------------
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

XEmacs without anti-aliased fonts looks horrendously ugly, IMHO, and
I can't think of an application that doesn't use anti-aliased fonts.
Maybe vi? (OK, OK, cheap shot, I retract the slur.)
I use Xft all the time, and have done so with both 21.4 and 21.5, but
I use non-standard configure options:

What do you use XEmacs for? Because XEmacs has such a diverse user base
it is interesting what some people consider "absolute must" and others
are "meh".
I tend to have two types of apps. I edit a lot of code and spend a lot
of time looking at stuff with terminal windows. For this I am happy
without anti-aliased fonts. Probably just because I am used to it.
The other type of app I use is more graphically oriented: web browser,
mail client, IM. These are usually anti-aliased.
And getting back to usage, there was a comment on this list along the
lines of "everybody needs unicode support". The only time I touch
unicode is for some strings in windows drivers (such as the registry
path). I have never needed to display unicode, so I always wondered
what people used it for in XEmacs.
Sorry for the rambling.
Cheers,
Sean
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Mike> I like Xft and use it myself but didn’t enable it in the
Mike> openSUSE package because there are still quite a few problems
Mike> and maybe not everybody likes it.
Could you elaborate. What problems eg what is needed to make it
usable? What is there to dislike?
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

>>>>> Mike wrote:
Mike> I like Xft and use it myself but didn't enable it in the
Mike> openSUSE package because there are still quite a few problems
Mike> and maybe not everybody likes it.
Could you elaborate. What problems eg what is needed to make it
usable? What is there to dislike?

For me the font menu not working correctly is an issue. These days I
expect not to have to fiddle with .Xdefaults or .Xresources or whatever it's
called now just to change a font.
I think there's also a problem in setting up the size of the initial frame,
it's usually too big for my screen.
Robert
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

2008/6/19 Mats Lidell <matsl(a)xemacs.org&gt;:
> >>>>> Mike wrote:
>
> Mike> I like Xft and use it myself but didn't enable it in the
> Mike> openSUSE package because there are still quite a few problems
> Mike> and maybe not everybody likes it.
>
> Could you elaborate. What problems eg what is needed to make it
> usable? What is there to dislike?
>
For me the font menu not working correctly is an issue. These days I
expect not to have to fiddle with .Xdefaults or .Xresources or whatever it's
called now just to change a font.
I think there's also a problem in setting up the size of the initial frame,
it's usually too big for my screen.

I really don’t care at all about the font menu. With some fiddling
around I managed to set fonts which I like.
But this might be different for other users. Normal users might not be
able to get tweak the font setup according to their taste.
Of course I could try to set what I think is a reasonable font setup as
the default in an openSUSE package.
But experience shows that people have different opinions about fonts and
not everybody will agree with my choice of fonts.
Also redisplay with Xft seems to be slower than with X11 core fonts.
Some tuning might still be possible but Xft will never be as fast as X11
core fonts.
For me this is not a problem at all. For me it is still fast enough
although my hardware is already ancient. But I know from several bug
reports that some users can get very exited even about very minor
performance differences.
Therefore I would like to offer users an easy choice. Best would
be to set an option in ~/.xemacs/init.el whether to use Xft or not.
But as this is currently not possible, I think I’ll build XEmacs twice,
once with Xft and once without and add an xemacs-xft package, i.e.
then there will be the following xemacs packages on openSUSE:
xemacs binaries, elc files and all other stuff needed to run
xemacs-el .el files (only those which are *not* required to run)
xemacs-info .info files
xemacs-packages basically the sumo tarball, stuff needed to run
xemacs-packages-el .el files from the sumos (only those which are *not* required to
run)
xemacs-packages-info .info files from the sumos
xemacs-xft will contain only /usr/bin/xemacs-xft and its dump file
I think by adding such a “xemacs-xft” package I can give users an easy
way to try out XEmacs with Xft without having to download different
packages from an obscure non-standard repository and without having to
force it on everybody because /usr/bin/xemacs will still use X11 core
fonts and users who want to try Xft can start /usr/bin/xemacs-xft.
--
Mike FABIAN <mfabian(a)suse.de&gt; http://www.suse.de/~mfabian
睡眠不足はいい仕事の敵だ。
I � Unicode
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

>>>>> Mike wrote:
Mike> I like Xft and use it myself but didn’t enable it in the
Mike> openSUSE package because there are still quite a few problems
Mike> and maybe not everybody likes it.
Could you elaborate. What problems eg what is needed to make it
usable? What is there to dislike?

For me there is nothing significant to dislike about XEmacs Xft, for me
the advantages far outweigh the disadvantages.
But I doubt that everybody will agree.
Some people *will* complain about Xft being slower, some people
will complain about the difficult font setup.
--
Mike FABIAN <mfabian(a)suse.de&gt; http://www.suse.de/~mfabian
睡眠不足はいい仕事の敵だ。
I � Unicode
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Some people *will* complain about Xft being slower, some people
will complain about the difficult font setup.

All this talk about xft convinced me to try it. So I turned it on. I'm
not convinced I like it better, but I am willing to give it a try.
A couple of things right of the bat... what font do people use? I find
the fonts are too big and look great, or are too small. I can't find an
in-between. I mainly use a laptop, so size matters ;)
When I select a font using Options->Font, it doesn't do anything. Is
this disabled under xft?
If I set the font using X properties, both the Options->Font and
Options->Fontsize say "Cannot parse current font". Not really a
problem, I just wonder if this is expected, or if I am specifying the
font wrong.
Last, I cannot set the menubar font using:
XEmacs*menubar.font: -*-lucida-medium-r-*-*-*-80-100-100-*-*-*-*
The menubar font is too large for my liking. I don't use the menubar
much. To be honest I keep it enabled for the people who say XEmacs is
hard to use.
Cheers,
Sean
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

A couple of things right of the bat... what font do people use? I
find
the fonts are too big and look great, or are too small. I can't find an
in-between. I mainly use a laptop, so size matters ;)

On a 1024x735 Mac iBook I use
XEmacs.default.attributeFont: Bitstream Vera Sans Mono-14
XEmacs*Tabs.fcFontName: Bitstream Charter-14:italic
XEmacs*menubar.fcFontName: Bitstream Bitstream Vera Sans-12:bold
XEmacs*modeline.attributeFont: Bitstream Charter-12
The FreeFonts aren't too bad IMO, either, but Bitstream is nicer and
the repertoire is more complete. (There are also much nicer fonts
available, that I could use but they're not available on my Linux
systems AFAIK.)

Last, I cannot set the menubar font using:
XEmacs*menubar.font: -*-lucida-medium-r-*-*-*-80-100-100-*-*-*-*

No, you can't. The Xft font resources are currently fcFontName, not
font, because they have a different syntax from XLFDs, which is
<family>-<size>[:key=value...]. Xft font resources also have a
different internal representation (X font resources are automatically
converted to XFontStruct*, while Xft font resources are char*). The
resources named 'font' are not used at all if Xft is enabled for that
domain (ie, any of emacs, tabs, gauges, menubars).
If you build with '--with-xft=nomenubars,...', then the resource above
should work (but I haven't tested it).
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta