emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fiddling with the menus


From: CHENG Gao
Subject: Re: Fiddling with the menus
Date: Sun, 09 Aug 2009 17:51:27 +0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (darwin)

*On Sun, 09 Aug 2009 01:05:35 -0400
* Also sprach Stefan Monnier <address@hidden>:


>> The content of “Emacs FAQ”, “Emacs News”, “Emacs Known Problems”, are
>> about 5 or 10 years out of date.
>
> If Emacs News is out of date, it's a bug.
>
> The "known problems" indeed tend to be very out of date, tho not all of
> them are.  We should probably split this file into sections for problems
> which have been reported for specific releases (with a note that
> problems in older releases may still be relevant).
>
> The FAQ's maintenance has always been a bit problematic, indeed.  I'd be
> happy to drop it.

I think "Emacs Known Problems" should only show outstanding problems in
CURRENT emacs. I am not sure, but I guess some problems have already
been solved (in my Emacs built from Emacs git source). Problems for old
releases should be archived in seperate files (like PROBLEMS-20, PROBLEMS-21).

And some problems are caused by third party packages (for example VM).
It could be put into another file.

My understand is "Emacs Known Problems" is for problems related to
current Emacs and its bundled packages.


>> Similarly, the “External Packages” is hopelessly outdated.  For this,
>> the emacswiki (emacswiki.org) provides far more useful resource.
>
> We could link to some web page on www.gnu.org.  But we need someone to
> keep it up-to-date.  Maybe along with ELPA.

I think a page on www.gnu.org or emacswiki.org  can not solve this
problem. It could be even worse. Updating a webpage or wiki page does
not mean less work than a patch to MORE.STUFF. On the contrary it could
mean more work.

>
>> The “Getting New Versions”, “Copying Condition”, “(Non)Warranty” are
>> all redundant.
>
> I don't see how they're redundant.  But yes, “Getting New Versions”
> sounds old.  It should probably link to www.gnu.org/software/emacs.
>
>> In today's web info world, it's silly that a Emacs
>> users would pull a menu to know where to get new versions.  A modern
>> replacement should be “Check Update” that tells user if his Emacs is
>> up to date, or better, automatically upgrade Emacs as a option.
>> Such a feature is common in all modern apps.
>
> Under GNU/Linux this doesn't belong in the application but in the
> distribution, and indeed it works just fine for Emacs just like it works
> for all other applications.
> For other platforms, we could imagine better support for installers and
> semi-automatic update, but not until someone writes them.

A link to distribution page is enough. This feature is too platform
specific. GNU/Linux systems have package manageement system to do this.
Even MacOS has package management system like Macports, Fink or Rudix
to do this. Maybe it's useful for Windows, since there is official
distribution for Windows.

Emacs website can supply some kind of API to let Emacs to grab the
latest version. It need not be real API.

>From Emacs site you can read 
,----
| Releases
| The current stable release is 23.1. To obtain it, visit the obtaining section.
`----

Someone could write an interactive function to parse
http://www.gnu.org/software/emacs/ to get it. Emacs page could be
revised to be a little parser friendly to use a special tag or comment.

Say from Emacs website page source:

,----
| <h3 id="Releases">Releases</h3>
| 
| <p><b>The current stable release is 23.1</b>.  To obtain it, visit
| the <a href="#Obtaining">obtaining</a> section.</p>
`----

It could be changed to:

,----
| <h3 id="Releases">Releases</h3>
| 
| <p><b>The current stable release is 23.1</b><!--Latest:23.1-->.  To
| obtain it, visit the <a href="#Obtaining">obtaining</a> section.</p>
`----

Parsing function can grab <!--Latest:23.1--> to get the version number.
It can then do comparison and ask users to go to distribution page to
download or shout to some maintainers (for their platforms) to update
the package.



>> The items in “More Manuals” sub-menu, can all be gone except the “All
>> Other Manuals (Info)” and the the “Lookup Subject in all manuals...”
>> (info-apropos).  The “All Other Manuals (Info)” should be moved to the
>> top, and serve as the one entry point for all manuals, and the
>> info-apropos menu item can move to the “Search Documentation”
>> sub menu.
>
> That sounds OK.

How about change "All other Manuals" to "All Manuals (C-h i)"? I think
many users (if not most) will start here. It even deserves as the first
item under Help menu.

And info-apropos could be put some place here: 
,----
|   The Info Directory is the top-level menu of major Info topics.
|   Type "d" in Info to return to the Info Directory.  Type "q" to exit Info.
|   Type "?" for a list of Info commands, or "h" to visit an Info tutorial.
|   Type "m" to choose a menu item--for instance,
|     "mEmacs<Return>" visits the Emacs manual.
|   In Emacs Info, you can click mouse button 2 on a menu item
|   or cross reference to follow it to its target.
|   Each menu line that starts with a * is a topic you can select with "m".
|   Every third topic has a red * to help pick the right number to type.
`----

Personally I suggest to put Emacs coding standards to a seperate file
and a first level item under Help menu. It's a good propoganda.
And I think elispinto and elispref deserve the first level item under
Help menu.


-- 
Numquam minus solus quam cum solus





reply via email to

[Prev in Thread] Current Thread [Next in Thread]