Bug 132567 - move Emacs into Development packages since category is Programming
move Emacs into Development packages since category is Programming
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: comps (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-09-14 15:10 EDT by Seth Nickell
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-04 20:22:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Seth Nickell 2004-09-14 15:10:08 EDT
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.
Comment 1 Jens Petersen 2004-09-21 04:33:29 EDT
Ok, I'll add that in the next build, which should be before test3.
Comment 2 Seth Nickell 2004-09-27 13:14:05 EDT
Hey Jens, did this make it in? I'm not seeing it in the latest Rawhides.
Comment 4 Jens Petersen 2004-09-29 08:11:10 EDT
Should get fixed in 21.3-15.
Comment 5 Ray Strode [halfline] 2004-09-29 16:36:50 EDT
Looks to be fixed.
Comment 6 Ville Skyttä 2004-10-18 05:23:34 EDT
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.
Comment 7 Jens Petersen 2004-10-18 09:41:15 EDT
Fine by me.  Seth?
Comment 8 Havoc Pennington 2004-10-18 17:53:55 EDT
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.
Comment 9 Seth Nickell 2004-10-21 17:40:27 EDT
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.
Comment 10 Seth Nickell 2004-10-21 17:43:08 EDT
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.
Comment 11 Ville Skyttä 2004-10-21 18:03:15 EDT
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?
Comment 12 Jens Petersen 2004-10-24 08:20:46 EDT
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.

Comment 13 Ville Skyttä 2004-10-24 08:39:53 EDT
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.
Comment 14 Jens Petersen 2004-10-27 02:53:27 EDT
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. :-(
Comment 15 Jens Petersen 2004-10-27 02:56:14 EDT
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.
Comment 16 Ville Skyttä 2004-10-27 11:05:58 EDT
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
Comment 17 Bryan W Clark 2004-10-27 14:07:48 EDT
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.
Comment 18 Jens Petersen 2004-10-28 21:05:34 EDT
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).
Comment 19 Bryan W Clark 2004-10-29 16:44:45 EDT
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.. ;-)
Comment 20 Ville Skyttä 2004-10-31 14:29:47 EST
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...
Comment 21 Jens Petersen 2004-11-01 06:30:19 EST
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? :)
Comment 22 Jens Petersen 2004-11-01 06:55:38 EST
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? (-:
Comment 23 Ville Skyttä 2004-11-03 16:14:30 EST
In case you're still looking for opinions: I think following hp's
suggestion and removing NoDisplay=true would be OK.
Comment 24 Jens Petersen 2004-11-03 21:40:49 EST
Ok, re-assigning to comps.
Comment 26 Jens Petersen 2004-11-03 21:51:18 EST
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?
Comment 27 Jens Petersen 2004-11-03 22:06:24 EST
Fwiw I turned on emacs in the menu again in emacs-21.3-18 in rawhide.
Comment 28 Rahul Sundaram 2004-11-07 14:00:44 EST

Has it also been moved into development category instead of being in
the default selection as HP suggested?
Comment 29 Jens Petersen 2004-11-07 19:59:38 EST
Rahul, nothing has happened yet, but that is the current suggestion yes.
Comment 30 Mike McLean 2004-11-11 18:26:55 EST
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.
Comment 31 Bryan W Clark 2004-11-11 18:34:48 EST
(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
Comment 32 Jens Petersen 2004-11-11 21:00:16 EST
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?
Comment 33 Mike McLean 2004-11-12 02:21:25 EST
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).
Comment 34 Jens Petersen 2004-11-12 05:42:33 EST
Mike, yep, doing both A and B sounds good. :-)

If you add Emacs to Programming please add XEmacs there too
for consistency.
Comment 35 Bryan W Clark 2004-11-12 15:43:50 EST
Ok, sounds good to me too. :-)
Comment 36 Mike McLean 2004-11-12 16:12:28 EST
A and B implemented. xemacs added to development-tools also, but
listed as optional.

Note You need to log in before you can comment on or make changes to this bug.