Alt vs Meta?
15 years, 9 months
Raymond Toy
This is somewhat off-topic, but it does relate to XEmacs.
On my solaris box, gnome-terminals want to use Alt key to do
command-line editing with bash. But after decades (gasp!) of XEmacs
usage, I want to use Meta key. (Note that xterms work just fine with
Meta).
The Sun keyboard basically looks like this:
CapsLock | Alt | Meta (diamond) | spacebar | Meta (diamond) | Compose | Alt graph
The Alt key is just a little to far to the left to reach easily with
my thumb.
I tried to make the Meta_L key be the same Alt. This works for
gnome-terminals, but breaks XEmacs because Alt is not Meta, so all the
Meta commands I'm used to don't work because I'm really pressing Alt.
Googling for xemacs and Alt key shows some interesting threads, but
not quite this one.
I could just use plain xterms, but gnome-terms look nicer with the
anti-aliases fonts.
Ray
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Re: Fwd: sign off on XEmacs 21.5
15 years, 9 months
Stephen J. Turnbull
David Kastrup writes:
> So try it for once.
It's in process, I believe Uwe is fighting with dotsrc's CVS server at
this very minute.
All I'm asking of you is that you wait to judge the product until it's
out, at least as a CVS branch.
If your developers really want to stop working on AUCTeX on XEmacs,
let them. I'll be disappointed, but it's no business of mine to do
more than say "I'm disappointed," since the only resource I have to
offer to you is Uwe and maybe Mats. (Of course I'll certainly solicit
help from any users who write us about AUCTeX, but I can't offer their
help until they do.)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Re: Fwd: sign off on XEmacs 21.5
15 years, 9 months
Stephen J. Turnbull
David Kastrup writes:
> > Stop trolling, David. Of course it's not acrimonious and frustrating
> > that you provided users with a solution.
>
> Fine. So do tell what "acrimony" and "frustration" was caused by our
> "package" surprisingly popping up years after somebody bothered updating
> the XEmacs package in Sumo.
I told you already: none. The acrimony and frustration were caused by
your attempts to tell us how to do our work, and our decision not to
follow your advice.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
xemacs: couldn't deduce a bold version of the font
15 years, 9 months
Raymond Toy
I'm getting the following messages in *Warnings*, but I don't know
where it's coming from. I'd like to get rid of them. This happens
with xemacs -vanilla too. This is on Solaris 10, running my own CVS
build from sources on 2008-06-01.
Any hints?
Ray
(1) (font/warning) xemacs: couldn't deduce a bold version of the font
"-dt-interface user-medium-r-normal-s*utf*-*-*-*-*-*-*-*-*".
Please specify X resources to make the bold face
visually distinguishable from the default face.
For example, you could add one of the following to $HOME/Emacs:
XEmacs.bold.attributeFont: -dt-*-medium-i-*
or
XEmacs.bold.attributeForeground: hotpink
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Re: Fwd: sign off on XEmacs 21.5
15 years, 9 months
Stephen J. Turnbull
David Kastrup writes:
> _If_ you are lucky, the results will be comparable, but not reached by
> the same means.
Well, sure. But isn't that the kind of argument you've never been
willing to accept when I make it? You're the one who's been insisting
for years that all that matters is the installation tarball unpacks in
the right places.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Re: Fwd: sign off on XEmacs 21.5
15 years, 9 months
Stephen J. Turnbull
David Kastrup writes:
> > This led directly to a lot of acrimony and frustration that was
> > certainly avoidable.
>
> Oh come on. Our "package" filled a void that had been open for years.
> The alternative would have been to let XEmacs users be locked out for
> another few years from getting updates of the package. If it is
> acrimonous and frustrating that somebody pitches in to make things work
> for the user, you have to adjust your priorities.
Stop trolling, David. Of course it's not acrimonious and frustrating
that you provided users with a solution. Nobody ever suggested that
you should stop distributing it; nobody ever tried to tell AUCTeX how
to manage its internal affairs.
> I assert that we can't produce and test the configuration that will at
> some point of time finally be distributed by XEmacs. The startup files
> are different. The file organization is different. The
> preconfiguration is different. The manner in which the respective files
> are found are different. The manner in which version information is
> injected into code and documentation is different.
>
> A test for our "package" is not representative for how your package
> works.
This is a very bizarre claim. You say that you have a "package" that
is in every way the same as what we would distribute. Well, in that
case we should be able to aim for the same thing and it will work the
same, and can be tested the same way.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Re: cvs server is extremely slow.
15 years, 9 months
Aidan Kehoe
Ar an naoiú lá de mí Iúil, scríobh Stephen J. Turnbull:
> Uwe Brauer writes:
>
> > Is there something I can do about it, some proxy setting?
>
> Not that I know of. This seems to be a problem with the network
> between your and dotsrc, or something intermittent, as I don't see a
> problem from California or Japan. (Full CVS update of 21.4 and of the
> Web site in about 2 min each, which is typical.) Aidan has reported
> very slow connections to dotsrc several times, too; maybe he's figured
> out something.
Yes; "be happy I'm using Mercurial most of the time."
I asked on the lists a few months ago (the last time Uwe had this problem)
about moving the packages to Mercurial, and the consensus was in favour of
it. Mike (Sperber), you had a script to import CVS into hg, right? Was that
yours, or a standard tool?
> It's also possible that updating doesn't exercise the server in the
> same way, but I would guess the problem is the network.
--
¿Dónde estará ahora mi sobrino Yoghurtu Nghé, que tuvo que huir
precipitadamente de la aldea por culpa de la escasez de rinocerontes?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Re: Fwd: sign off on XEmacs 21.5
15 years, 9 months
Stephen J. Turnbull
David Kastrup writes:
> I think you are missing a part of the history here. It was Nix, an
> XEmacs developer,
AFAIK, Nix is a GCC developer who preferred XEmacs for his editor. He
has a total of 6 or 7 credits in our ChangeLogs for core, and only 10
in packages, none in AUCTeX.[1] He definitely was never a reviewer,
and he doesn't have, and AFAIK never had, CVS or Hg commit privilege.
One real smart guy, but I can't claim him as one of ours. If you're
going to claim he's an XEmacs developer, please, please, deliver him
(and his skills) to us!
> [R]ather the build process wrapped system dependencies into the
> package, so the finished package would be system-specific and
> distribution from Sumo not doing people a favor.
I remember that.
> Later preview-latex became an integrated part of AUCTeX, and we
> basically extended the XEmacs-centric (but not XEmacs-blessed) package
> build process used for preview-latex to encompass all of AUCTeX.
I am indeed missing that part of the history. Which, of course,
implies that nobody in XEmacs asked you to do that work or suggested
that you do it or cooperated in doing it. Why you thought Nix was "an
XEmacs developer" I don't know. I suggest you ask him, or yourself.
I certainly never told you he was.
He also never mentioned the work he was doing on AUCTeX's build
process on XEmacs channels AFAIK, although I knew he was interested in
AUCTeX.
> Now if an XEmacs developer of the quality of Nix is not able to come up
> with a packaging according to your guidelines, what does this tell you?
That he's not an XEmacs developer, of course.
> If it takes XEmacs developers years to come up with a packaging meeting
> your guidelines, what does this tell you?
That it took years to find people with the skills and interest to do
it.
AFAIK only a couple of man-weeks have actually gone into the most
recent work, which AIUI is pretty much independent of earlier
attempts. You'd have to ask Uwe and Mats.
This low effort is almost certainly due to the work Nix (and the
AUCTeX dev team) did on AUCTeX, as you described. It is unfortunately
not the fruit of cooperation with XEmacs, but of cooperation between
an AUCTeX-and-XEmacs user and the AUCTeX developers. But we had no
clue what you were doing. That was Uwe's task, to keep track, but he
probably wasn't aware of the significance of the changes Nix was
making. Closer cooperation between the core of XEmacs development and
that of AUCTeX would surely have sped up the process of getting to
where we are today.
> That we stop getting in your way of doing everything according to your
> own ideas.
When did you get in our way? I certainly haven't noticed AUCTeX in my
way. Personally I have this problem that I respond to your posts in
unproductive ways, but that's not AUCTeX-specific.
> Basically I would stop asking our developers to do testing or catering
> for XEmacs. It's pretty useless, anyway, since the tested configuration
> will not get permitted into XEmacs distribution.
That's a strange thing to say. Presumably, the configuration on which
you run functional tests *is* the XEmacs package configuration. So it
*will* get into the distribution. Users (or you) are welcome to
report bugs if the configuration produced by Mats and Uwe is not as
expected. It will also get further testing (which may or may not be
redundant) in the process of being built (and tested, if tests are
provided) in-tree.
As far as I can tell, we *are* on the verge of an XEmacs packaged
version of AUCTeX that satisfies our criteria, as well as being vastly
improved in terms of timeliness from AUCTeX's point of view. So from
my point of view while a lot of the things you say were arguable 6
months ago, they really are quite inapplicable to the current
situation.
Footnotes:
[1] This means that he contributed very little to XEmacs package
infrastructure maintenance. He may have had substantial contributions
to package functionality that would be logged in upstream (renamed)
ChangeLogs.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Library search path
15 years, 9 months
Vladimir G. Ivanovic
[See xemacs info, node 3.3, "Startup Paths::How XEmacs finds
Directories and Files"]
The documentation says that $HOME/.xemacs/xemacs-packages is searched
for libraries, but experimentation ('M-x load-library RET <library>
RET', where <library> only exists in $HOME/.xemacs/xemacs-packages)
with "xemacs --vanilla" shows that it is not. Which is correct, the
docs or the program?
Also, where ever the info (texi) files mention '<root>/lib/' or
'$prefix/lib/' that should (at least) be changed to '<root>/share/' or
'$prefix/share', right?
--- Vladimir
--
Vladimir G. Ivanovic
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta