8:11 p.m.
So when I install Xemacs there are useless items on the Tools menu marked
"Games" and "Calendar". How do I access them? They are all greyed
out. Or
if they don't really exist, why are they even listed?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/mailman/listinfo/xemacs-beta
6:14 a.m.
~ writes:
So when I install Xemacs there are useless items on the Tools menu
marked "Games" and "Calendar". How do I access them? They are all
greyed out. Or if they don't really exist, why are they even
listed?
They're listed because in a standard installation, they're present.
They are categories of application, and I guess you don't have the
relevant Lisp packages installed.
How you install additional Lisp packages depends on how you installed
XEmacs and what kind of system you are using.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/mailman/listinfo/xemacs-beta
10:13 a.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
~ writes:
> So when I install Xemacs there are useless items on the Tools menu
> marked "Games" and "Calendar". How do I access them? They are
all
> greyed out. Or if they don't really exist, why are they even
> listed?
They're listed because in a standard installation, they're present.
They are categories of application, and I guess you don't have the
relevant Lisp packages installed.
How you install additional Lisp packages depends on how you installed
XEmacs and what kind of system you are using.
What use is a package system when the user interface is cluttered up by
everything that _could_ be installed?
It would appear a good idea to me if the respective menu entries were
added by autoloads contained in the package.
The package autoloads are expensive in startup time; getting some
payback over monolithicness would seem appropriate.
--
David Kastrup
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/mailman/listinfo/xemacs-beta
12:25 p.m.
David Kastrup writes:
It would appear a good idea to me if the respective menu entries
were added by autoloads contained in the package.
Maybe, but it's not a no-brainer. The presence of a menu entry makes
the feature more discoverable. Without it, you'd have to read the
docs (including knowing where to find them; they come with the package
in many cases, Catch-22!) to know that these features are available.
This information is not necessarily available from M-x list-packages;
that list is at the package level, not the menu entry level.
It's not like menu space is that scarce at top-level in XEmacs
currently, and the organization in XEmacs 21.5 is pretty good IMO.
(Ben did it, no "H" necessary. ;-)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/mailman/listinfo/xemacs-beta
12:47 p.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
David Kastrup writes:
> It would appear a good idea to me if the respective menu entries
> were added by autoloads contained in the package.
Maybe, but it's not a no-brainer. The presence of a menu entry makes
the feature more discoverable.
Poor excuse. If there is no obvious way to get from the greyed-out menu
entry to an installed package providing it, it just serves to annoy the
user.
For people wanting to discover everything, there is Sumo. People not
installing it presumably _want_ a customized XEmacs. There is little
point then in advertising parts of the uncustomized XEmacs by cluttering
the user interface with non-functional elements.
If a less than Sumo XEmacs is strictly inferior not just in
functionality but also usability and simplicity than Sumo, the package
system provides _only_ disadvantages to the user when compared to a
monolithic system like Emacs.
Another case of "As opposed to Emacs, XEmacs comes with a gun!",
unfortunately mounted rigidly pointing at the user's foot.
--
David Kastrup
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/mailman/listinfo/xemacs-beta
3:42 p.m.
David Kastrup writes:
Poor excuse. If there is no obvious way to get from the greyed-out
menu entry to an installed package providing it, it just serves to
annoy the user.
There is an obvious way: ask on XEmacs-Beta. :-)
For people wanting to discover everything, there is Sumo. People
not installing it presumably _want_ a customized XEmacs.
In practice, that usually turns out not to be the case. They *think*
they want a customized (usually spelled s-l-i-m) XEmacs, then discover
they want the kitchen sink after all.
If a less than Sumo XEmacs is strictly inferior not just in
functionality but also usability and simplicity than Sumo, the
package system provides _only_ disadvantages to the user when
compared to a monolithic system like Emacs.
Not at all.
1. "make beta; make check" is *way* faster than just "make
bootstrap".
("What's good for the developers trickles down to the users.")
2. New packages can be officially released without a SUMO release, and
without an XEmacs release.
3. Upgraded packages can be made available much faster than XEmacs
releases.
4. Experimental versions of *some* packages can be installed, and will
upgrade smoothly when officially released.
5. APIs used by packages tend to drift rather than fault. (This has
its ups and downs, but IMO the users get a better experience.)
6. It keeps Tom Tromey busy. Ie, packages seem to be pretty popular at
Emacs Central, too,
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/mailman/listinfo/xemacs-beta
4:12 p.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
David Kastrup writes:
> Poor excuse. If there is no obvious way to get from the greyed-out
> menu entry to an installed package providing it, it just serves to
> annoy the user.
There is an obvious way: ask on XEmacs-Beta. :-)
You likely prefer your car to explode when running out of gas. That
way, it is obvious to the driver that he has a problem.
> For people wanting to discover everything, there is Sumo.
People
> not installing it presumably _want_ a customized XEmacs.
In practice, that usually turns out not to be the case. They *think*
they want a customized (usually spelled s-l-i-m) XEmacs, then discover
they want the kitchen sink after all.
"You get the choice: you can either take the Sumo offering." "Or
what?"
"Or else." "What else is there?" "Why would you want something
else?"
"What other choice do I have?" "Isn't it good that you have the
choice?" "Which choice?" "Whether you take Sumo." "Or
what?" "Isn't
Sumo good enough for you?" "How should I know if I don't know the other
options?" "You don't want to know the other options."
"Why?" "You
just don't. Be glad you have the choice. Don't waste it by choosing
wrong. Ask us if you have problems."
Sounds like election rituals in non-democratic states.
--
David Kastrup
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/mailman/listinfo/xemacs-beta
3:15 a.m.
-----Original Message-----
From: Stephen J. Turnbull
Sent: Tuesday, August 24, 2010 1:14 AM
To: Ə
Cc: xemacs-beta(a)xemacs.org
Subject: Grey Matter
They're listed because in a standard installation, they're
present.
They are categories of application, and I guess you don't have the
relevant Lisp packages installed.
How you install additional Lisp packages depends on how you installed
XEmacs and what kind of system you are using.
I simply ran the setup program and did specify that I wanted all the
options.
Funny thing but GNU emacs seems to not have this problem.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/mailman/listinfo/xemacs-beta
8:37 a.m.
New subject: Menu discoverability (was Re: Grey Matter)
David Kastrup writes:
> It would appear a good idea to me if the respective menu entries
> were added by autoloads contained in the package.
Stephen J. Turnbull wrote:
Maybe, but it's not a no-brainer. The presence of a menu entry
makes
the feature more discoverable.
Unfortunately the menus fall short of XEmacs' usual standard of
discoverability. Often I've wished I could see the elisp command that
a menu item would execute, by hovering over it or something. For
example the Print entry on the File menu: On my system (WinXP,beta29)
the Print entry works whereas M-x print-buffer RET doesn't (it seems
to think I have a UNIX style print spooler) - but I can't figure out
what it does in order to bind it to a key or such.
regards, Anders
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/mailman/listinfo/xemacs-beta
9:07 a.m.
New subject: Menu discoverability
On Wed, 25 Aug 2010 09:37:28 +0200, Anders wrote:
Often I've wished I could see the elisp command that a menu item
would
execute, by hovering over it or something.
It would be cool if C-h <click menu entry> would show the documentation
of the command that the menu entry would run if clicked directly.
Alternatively put the "show what" on one of the other mouse-buttons,
say, the middle one.
Just an idea,
Adam
--
"But we are stubborn." Adam Sjøgren
asjo(a)koldfront.dk
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/mailman/listinfo/xemacs-beta
10 a.m.
New subject: Menu discoverability (was Re: Grey Matter)
Anders J. Munch writes:
Unfortunately the menus fall short of XEmacs' usual standard of
discoverability. Often I've wished I could see the elisp command
that a menu item would execute, by hovering over it or something.
Hovering is a good idea. I've opened issue728.
However, there's also a way to do it manually: C-h k (also available
from the Help menu, but pretty deeply buried), then select the command
from the menu.
Oops, I misspelled your name in the issue. Sorry!
Steve
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/mailman/listinfo/xemacs-beta
10:26 a.m.
New subject: Menu discoverability
asjo(a)koldfront.dk (Adam Sjøgren) writes:
On Wed, 25 Aug 2010 09:37:28 +0200, Anders wrote:
> Often I've wished I could see the elisp command that a menu item would
> execute, by hovering over it or something.
It would be cool if C-h <click menu entry> would show the
documentation of the command that the menu entry would run if clicked
directly.
Huh? C-h k <click menu entry> works fine with Emacs. I'd suppose that
the same holds for XEmacs.
--
David Kastrup
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/mailman/listinfo/xemacs-beta
10:27 a.m.
New subject: Menu discoverability
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
Anders J. Munch writes:
> Unfortunately the menus fall short of XEmacs' usual standard of
> discoverability. Often I've wished I could see the elisp command
> that a menu item would execute, by hovering over it or something.
Hovering is a good idea. I've opened issue728.
I'd consider it saner to implement mouse-over help for menus like Emacs
has.
--
David Kastrup
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/mailman/listinfo/xemacs-beta
10:39 a.m.
New subject: Menu discoverability
On Wed, 25 Aug 2010 11:26:08 +0200, David wrote:
Huh? C-h k <click menu entry> works fine with Emacs. I'd
suppose that
the same holds for XEmacs.
Ah, yes, in my mind the 'k' became "key", and I didn't even think to
try
this combination. It works fine in XEmacs as well.
Best regards,
Adam
--
"But we are stubborn." Adam Sjøgren
asjo(a)koldfront.dk
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/mailman/listinfo/xemacs-beta
11:37 a.m.
New subject: Menu discoverability
On Wed, 25 Aug 2010 11:26:08 +0200, David wrote:
> Huh? C-h k <click menu entry> works fine with Emacs. I'd suppose
that
> the same holds for XEmacs.
Adam "Sjøgren" wrote:
Ah, yes, in my mind the 'k' became "key", and I
didn't even think to try
this combination.
Same here. Now that I know it's there, it's easy to find, I found a
mention in the info pages as well.
It's also on the menu, under Help|Commands, Variables, Keys|Describe Key.
Perhaps the item should be labeled "Describe Key/Menu Item" instead.
- Anders
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/mailman/listinfo/xemacs-beta
12:05 p.m.
New subject: Menu discoverability
"Anders J. Munch" <ajm(a)flonidan.dk> writes:
> On Wed, 25 Aug 2010 11:26:08 +0200, David wrote:
>
> > Huh? C-h k <click menu entry> works fine with Emacs. I'd suppose
> that
> > the same holds for XEmacs.
>
Adam "Sjøgren" wrote:
> Ah, yes, in my mind the 'k' became "key", and I didn't even
think to try
> this combination.
Same here. Now that I know it's there, it's easy to find, I found a
mention in the info pages as well.
It's also on the menu, under Help|Commands, Variables, Keys|Describe Key.
Perhaps the item should be labeled "Describe Key/Menu Item" instead.
In Emacs, it is
Help/Describe/Describe Key or Mouse Operation
and the menu entry has a tooltip
"Display documentation of a command bound to a key, a click, or a menu-item"
Since Emacs had wagonloads of usability and menu entry fights in the
last few years on its developer list, it might make sense for someone to
do an entry for entry comparison and see whether some of what Emacs
ended up with might be an improvement for XEmacs.
--
David Kastrup
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/mailman/listinfo/xemacs-beta
2:27 p.m.
New subject: Menu discoverability
David Kastrup writes:
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
> Anders J. Munch writes:
>
> > Unfortunately the menus fall short of XEmacs' usual standard
> > of discoverability. Often I've wished I could see the elisp
> > command that a menu item would execute, by hovering over it or
> > something.
>
> Hovering is a good idea. I've opened issue728.
I'd consider it saner to implement mouse-over help for menus
like
Emacs has.
Well, yes, that's why I refer to issue590 (which quotes your opinions
on the matter at some length) in that issue. Perhaps there could be a
"show-gui-item-commands" minor mode that shows what various GUI
objects (like toolbar buttons, menubar regions, and menu items are
bound to, in addition to help).
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/mailman/listinfo/xemacs-beta
6:08 a.m.
~ writes:
I simply ran the setup program and did specify that I wanted all
the options. Funny thing but GNU emacs seems to not have this
problem.
They *can't* have this problem. GNU Emacs doesn't provide a package
system; you get absolutely everything they offer, no less, and no
more. They've seen the light; the next version of GNU Emacs will
provide a package system. My bet is that the one after that will be
similar to XEmacs's (i.e., most applications will be provided
separately), as the burden on developers of bootstrapping a whole
system from scratch has become very large, and will only get larger as
more packages are added.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/mailman/listinfo/xemacs-beta
8:17 a.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
~ writes:
> I simply ran the setup program and did specify that I wanted all
> the options. Funny thing but GNU emacs seems to not have this
> problem.
They *can't* have this problem. GNU Emacs doesn't provide a package
system; you get absolutely everything they offer, no less, and no
more. They've seen the light; the next version of GNU Emacs will
provide a package system. My bet is that the one after that will be
similar to XEmacs's (i.e., most applications will be provided
separately), as the burden on developers of bootstrapping a whole
system from scratch has become very large, and will only get larger as
more packages are added.
That's not my bet. Emacs is still on its forward path to providing a
consistent IDE and that means advancing forward on several fronts at
once in a more or less interlocked manner.
There is nothing yet in the packager that would sensibly deal with
version dependencies. I know from AUCTeX that it has been an absolute
pain to provide compatibility with Emacs 20.4(?) APIs because XEmacs has
not bothered keeping up. Lagging 5 to 10 years behind the core
usability because of packages wanting to apply to more than the latest
version of Emacs is a severe brake. At the current level of
sophistication, packaging of core parts will just be useful for letting
various parts bitrot at independent speed.
--
David Kastrup
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/mailman/listinfo/xemacs-beta
2:19 p.m.
David Kastrup writes:
version dependencies. I know from AUCTeX that it has been an
absolute pain to provide compatibility with Emacs 20.4(?) APIs
because XEmacs has not bothered keeping up.
It's more than a "bother" to keep up; it's illegal. Until we get the
GPLv3 stuff nailed down, which is slowly coming along.
Lagging 5 to 10 years behind the core usability
Oh, come on, David. Lagging 5 to 10 years behind core usability
doesn't bother you at all when it's XEmacs that is ahead.
I don't blame you for wanting a single Emacs API to target, but don't
blame us because some of your users still prefer XEmacs despite an
alleged 5 to 10 year lag. As always, it's your choice what to
support, and I've been reminding you of that fact for many years now.
I will remind you that Richard and Stefan do not have your qualms
about supporting old versions of anything. They support only the
current release (and for some definitions of "support", the
development code). Stefan's reasonable about adopting XEmacs practice
in many cases, but he doesn't care about compatibility enough to do it
any way but the way he thinks best. I'm pretty sure that he and
Yidong will deal with integrating CEDET etc in the same way.
That's not my bet. Emacs is still on its forward path to
providing
a consistent IDE and that means advancing forward on several fronts
at once in a more or less interlocked manner.
Fine. Keep the parts that the IDE depends on in core at least until
the APIs settle down, and maybe forever if the IDE stuff turns out to
be mission-critical to all Emacs users. I don't think that should
include Gnus, calc, calendar, and maybe not even org-mode, though.
Just moving Gnus and calc out of the core distribution would make a
huge difference in time to bootstrap.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/mailman/listinfo/xemacs-beta
6:46 p.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
David Kastrup writes:
> version dependencies. I know from AUCTeX that it has been an
> absolute pain to provide compatibility with Emacs 20.4(?) APIs
> because XEmacs has not bothered keeping up.
It's more than a "bother" to keep up; it's illegal. Until we get the
GPLv3 stuff nailed down, which is slowly coming along.
XEmacs has not synched consistently for much longer than GPLv3 has been
around.
> Lagging 5 to 10 years behind the core usability
Oh, come on, David. Lagging 5 to 10 years behind core usability
doesn't bother you at all when it's XEmacs that is ahead.
XEmacs is not in the habit of being ahead concerning programmer
convenience.
I will remind you that Richard and Stefan do not have your qualms
about supporting old versions of anything.
They are not interested in XEmacs at all. Why should they?
> That's not my bet. Emacs is still on its forward path to
providing
> a consistent IDE and that means advancing forward on several fronts
> at once in a more or less interlocked manner.
Fine. Keep the parts that the IDE depends on in core at least until
the APIs settle down, and maybe forever if the IDE stuff turns out to
be mission-critical to all Emacs users. I don't think that should
include Gnus, calc, calendar, and maybe not even org-mode, though.
Just moving Gnus and calc out of the core distribution would make a
huge difference in time to bootstrap.
Computers grow faster than Emacs, so the situation gets more tolerable
in time overall rather than the other way round. Gnus has a CVS (or
whatever its repository is) of its own; so the situation is a bit
different from upstream calc which lives just in Emacs' repository.
The Emacs package repository will IMO not likely get populated much from
stuff currently in Emacs proper rather than externally developed
packages.
--
David Kastrup
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/mailman/listinfo/xemacs-beta
9:08 p.m.
On Sat, 28 Aug 2010 19:46:49 +0200, David wrote:
Computers grow faster than Emacs, so the situation gets more
tolerable
in time overall rather than the other way round. Gnus has a CVS (or
whatever its repository is) of its own; so the situation is a bit
different from upstream calc which lives just in Emacs' repository.
The Gnus repository is in git these days: http://git.gnus.org/
Best regards,
Adam
--
"Angels can fly because they take themselves lightly." Adam Sjøgren
asjo(a)koldfront.dk
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/mailman/listinfo/xemacs-beta
4997
days inactive
5003
days old
21 comments
5 participants
participants (5)
-
Adam Sjøgren -
Anders J. Munch -
David Kastrup -
Stephen J. Turnbull -
Ə