Re: Fiddling with the menus

[CHENG Gao <chenggao@gmail.com>]

*On Sun, 09 Aug 2009 20:38:54 +0300
* Also sprach Eli Zaretskii <eliz@gnu.org>:

>> From: CHENG Gao <chenggao@gmail.com>
>> Date: Sun, 09 Aug 2009 17:51:27 +0800
>> 
>> I think "Emacs Known Problems" should only show outstanding problems in
>> CURRENT emacs.
>
> Would you like to volunteer to maintain etc/PROBLEMS along these
> lines?  Mind you, the task is not as easy as it maybe sounds, because
> knowing just which problems are solved and which are not is quite
> hard, especially if the problem is about an OS you don't use and don't
> have access to.

Really scared. PROBLEMS is very big, near 3900 lines. 
Yes you are right. It's very hard to clarify which is solved and which
is  not.  Feedbacks from many users are needed.

> Let's take a random entry:
>
>     ** Emacs crashes when you use Bibtex mode.
>
>     This happens if your system puts a small limit on stack size.  You can
>     prevent the problem by using a suitable shell command (often `ulimit')
>     to raise the stack size limit before you run Emacs.
>
> How to know if this still happens? the entry doesn't even say on which
> system it was spotted.
>
>> And some problems are caused by third party packages (for example VM).
>> It could be put into another file.
>
> I don't think this is a good idea.  Someone looking for his/her
> problem shouldn't need to scan numerous files.
>
>> My understand is "Emacs Known Problems" is for problems related to
>> current Emacs and its bundled packages.
>
> Yes, but Emacs could have problems caused by third-party packages as
> well.  We don't want to omit the information about that, if it can
> help.  For example:
>
>     *** Emacs says it has saved a file, but the file does not actually
>     appear on disk.
>
>     This can happen on certain systems when you are using NFS, if the
>     remote disk is full.  It is due to a bug in NFS (or certain NFS
>     implementations), and there is apparently nothing Emacs can do to
>     detect the problem.  Emacs checks the failure codes of all the system
>     calls involved in writing a file, including `close'; but in the case
>     where the problem occurs, none of those system calls fails.
>
> Sounds useful, doesn't it?

Lines 994-1022 talk about MULE-UCS compilation problem, and the very
first problem says:

,----
| * Mule-UCS doesn't work in Emacs 23.
| 
| It's completely redundant now, as far as we know.
`----

So for current release (23.1), the former seems weird.

And I trust some problems occur for platforms removed from current
release.

Maybe we just let it be. Anyway known problems could be solved soon or
put into TODO.

-- 
The truth which makes men free is for the most part the truth which men prefer not to hear.