We should set NoDisplay=true on the gnu emacs .desktop file. Its going
to be very rare that this is launched from the menus, and by removing
the file we get rid of the "Programming" category on default installs.

FWIW, I think disabling the menu item is a bad idea in the first
place, I use it all the time for XEmacs (and one of the first things I
do on new installations is to drag&drop that menu icon to the KDE
panel for quick launch).
Further, IMO it is the wrong solution to the Programming category
problem. Instead, it'd be better if all text editors would be located
in the "Accessories" category. That's where for example Kate and
KWrite are on FC1 KDE (can't verify later FCx versions now).
So, could you consider removing the NoDisplay=true, but also remove
the Development category from the Emacs and XEmacs desktop files?
(And add Utility if necessary, or whatever to get it shown where other
text editors are.) Reopening for comments.

Emacs, for all its charms, uses completely different UI conventions
than our desktop (or Windows or MacOS for that matter). Its a beast
from another age. I think its great to have Emacs on the system for
programmers and for people accustomed to Unix, but we don't really
want it exposed to people by default.
That said, I would be leary about removing it from the default install
given emacs' role in fixing a busted system. Its sort of on the level
of bash or gnome-terminal (we could make an argument for moving that
out of the default too...).
I see two solutions that meet these constraints:
1) Have NoDisplay=true on the .desktop file
2) Don't include the .desktop file with emacs but include an
"emacs-desktop-menus" package that just adds the (visible) .desktop
file. Put it in the software development component, but don't install
it by default. Still install the core emacs package by default.
(2) is more of a PITA because it requires an extra package, but would
at least mean emacs appears in the menus when you do a more full
install, doesn't show up by default, but is still present from the
terminal by default.

My .02â¬: a separate subpackage for the menu entry is overkill, weird,
and inconsistent with the rest of the distro. And vi is the editor
that people use to fix busted systems, that's expected to be available
everywhere, Emacs not.
Seth, why not use the "correct" Category (ie. the same as for other
text editors) for the .desktop entry? If you insist, keep the
NoDisplay=true (which I still maintain is a, er, suboptimal solution
for the original problem), but the categories could be "fixed" anyway?

By removing that line from the .desktop file and doing it the usual
way... that's what I'll be doing anyway if the shipped package has
NoDisplay=true.
And whether NoDisplay=true is there or not, as said I would find it
logical if Emacs and XEmacs would be placed in Accessories (or
wherever other text editors are) -> the Categories could be changed in
any case.

So is there no difference between having "NoDisplay=true"
and no .desktop file at all? When I added "NoDisplay=true"
I naively assumed one would still be able to add Emacs to
the panel easy and have its icon appear in "Run Application"
dialog etc.
Unfortunately it is probably too late to revert this change for fc3 now. :-(

The programming category is the correct place for emacs. As much as
it might be a text editor like gedit it is really a development
environment. I mean emacs even has a mail and news reader! :-)
The separate package solution seems like a viable way of acheiving our
goal of not having emacs in the menus by default and allow people who
want the emacs launcher to have it. Perhaps it's a little overkill
for the .desktop file to own an entire package, but having a
'Programming' category with only one item, which is emacs is overkill
in many other ways.

Ville, I kinda agree that Emacs and XEmacs are a little big
to be considered Accessories: not that I really understand
what "Accessories" are anyway - probably I'm being unfair but it
seems to me to be somewhat of a mish-mash of programs that don't fit
into the other categories. Though I also agree that the
Programming category doesn't feel like an exact fit either
even if it is a bit closer than Accessories IMO.
Bryan, how do people find out about the emacs-desktop-menu package?
On the other hand you can argue that since Emacs is included
in a default install currently, then it doesn't belong in the
Programming category (Programming is surely for devel related
packages).

Jens, Good point. I guess basically I'd like to see the WS and other releases
include the emacs-desktop-menu package, but not the Desktop.
People shouldn't be using the Desktop product as a development environment, it
doesn't even include gcc or other common libraries. Emacs is really only a
development tool, I doubt that most desktop users will find emacs to be an easy
to use text editor. So I'm assuming that only developers will be looking for
the emacs-desktop-menu package and they would probably be able to create a
launcher of their own; it's just a hassle.
So what are we supposed to do? Confuse the regular Desktop users with the Emacs
entry or make the lives or a few developers simpler for a single moment in time
when they add the icon to their panel. I'm going with the latter.
As far as the Category goes, I think Programming is the best especially compared
to the other categories. However something like 'Kitchen Sink' be the best for
Emacs.. ;-)

Ok, I see the point, and partially agree. The separate menu item
subpackage would still suck :/
But my personal concerns are really related to the XEmacs, not GNU
Emacs package. Would it be possible to revert the NoDisplay=true from
the XEmacs package, without introducing kludgy subpackages? XEmacs is
not installed by default (nor with other groups except Everything
IIRC) so the initial Programming menu problem does not really exist
with it. Please don't punish XEmacs users because of an
unfortunate/undecided situation with the GNU Emacs package...

Ville, I agree I don't think we need a separate menu item
package for XEmacs since it is not installed by default. :)
I'll revert the XEmacs change in the next build.
As for Emacs, I guess I take Bryan's Desktop point of view.
So if we're going to decide this in comps, then for my last
question: what are we going to do for Fedora Core 4 - install
the Emacs .desktop file by default or not? :)

Then again I'm still (relunctantly:) thinking that hp's suggestion
actaully makes some sense: I mean what Bryan is saying about Desktop vs
Workstation is close to saying that really only WS users need Emacs
but not Desktop users (by default). So for RHEL would it not make
as much sense to just not install Emacs by default for DT but
only for WS, etc? But that probably isn't going to fly since
DT and WS actually have identical comps afaict. For FC we would
probably still want to install Emacs by default since FC users tends to
be developers or power users.
But this would still leave the lone Emacs sitting in the Programming
submenu for a default Desktop install: so then one could arguably take
hp's suggestion literally and only install Emacs for devel installs...
Have I gone full circle yet? (-:

I'm not really seeing a clear consensus here. With regards to comps,
is the following acceptable?
A) Leave emacs in the editors group, but mark it optional there.
B) Add emacs to the development-tools group, marked as default.

(In reply to comment #30)
> A) Leave emacs in the editors group, but mark it optional there.
^^ I'm reading this as the Programming category
Yes, for the Desktop optional and in Programming category
> B) Add emacs to the development-tools group, marked as default.
Yes, for the Workstation default and same category

Bryan's answer amounts to Mike's (B) I think, right?
Hmmm, Bryan, putting Emacs (and by consequence XEmacs) into
the Programming package category feels real strange,
but perhaps one just needs to get used to it?
So I think I prefer
Shouldn't there really be some matchup between package
categories and the submenus on the application menu.
We have Editor category, so can't we have an Editor
app submenu?
Anyway, can't Emacs and XEmacs appear both in the Editors
and Programming categories: being off by default in the former
and Emacs on by default in the latter?

I'm sorry for being unclear. I meant to implement both A and B.
In A, I really meant the editors group. This is a group in the comps
file (comps controls how packages are organized in the installer). I
was not talking about the kind of groups that one specifies in a spec
file. (There is no "Programming" group in comps).