Ok, I'll add that in the next build, which should be before test3.

Hey Jens, did this make it in? I'm not seeing it in the latest Rawhides.

Should get fixed in 21.3-15.

Looks to be fixed.

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.

Fine by me.  Seth?

Why don't we just move Emacs out of the default desktop install and
put it in the Software Development component or whatever it's called.

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.

Accessing Emacs from the menus is probably very rare, so I would
suggest we stick with (1). But I have no problems with (2). 

In either case, removing from the FC3 YellowPad and retitling.

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?

With "NoDisplay=true" how is one supposed to get Emacs onto
the panel if one wants to? It wasn't obvious to me anyway when I tried.

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. :-(

Fwiw, I agree with Ville that adding a separate subpackage
just for this seems a bit silly.  I suggest putting Emacs
and XEmacs in "Accessories -> Other" for now.

AFAIK the only practical difference between a .desktop file with
NoDisplay=true and no .desktop file at all is that the former allows
the application to show up in eg. various [Right Click]->"Open
with..." -style functions, even if it's not shown in the menus.

See also the NoDisplay docs at
http://freedesktop.org/Standards/desktop-entry-spec/desktop-entry-spec-0.9.4.html#id2444496

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? (-:

In case you're still looking for opinions: I think following hp's
suggestion and removing NoDisplay=true would be OK.

Ok, re-assigning to comps.

Of course Emacs should still be listed under Editors in anaconda.
What I'm requesting is that Emacs not be installed by default
when doing a FC Desktop install.  Is that possible?

Fwiw I turned on emacs in the menu again in emacs-21.3-18 in rawhide.

Has it also been moved into development category instead of being in
the default selection as HP suggested?

Rahul, nothing has happened yet, but that is the current suggestion yes.

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).

Mike, yep, doing both A and B sounds good. :-)

If you add Emacs to Programming please add XEmacs there too
for consistency.

Ok, sounds good to me too. :-)

A and B implemented. xemacs added to development-tools also, but
listed as optional.