From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Fiddling with the menus Date: Sun, 09 Aug 2009 20:38:54 +0300 Message-ID: <83ocqolwep.fsf@gnu.org> References: Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1249839549 7274 80.91.229.12 (9 Aug 2009 17:39:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 9 Aug 2009 17:39:09 +0000 (UTC) Cc: emacs-devel@gnu.org To: CHENG Gao Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 09 19:39:02 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MaCMH-0005UQ-V3 for ged-emacs-devel@m.gmane.org; Sun, 09 Aug 2009 19:39:02 +0200 Original-Received: from localhost ([127.0.0.1]:36004 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MaCMH-0000Ck-EN for ged-emacs-devel@m.gmane.org; Sun, 09 Aug 2009 13:39:01 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MaCMD-0000CO-2Y for emacs-devel@gnu.org; Sun, 09 Aug 2009 13:38:57 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MaCMC-0000C2-Fs for emacs-devel@gnu.org; Sun, 09 Aug 2009 13:38:56 -0400 Original-Received: from [199.232.76.173] (port=53948 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MaCMC-0000Bv-Ap for emacs-devel@gnu.org; Sun, 09 Aug 2009 13:38:56 -0400 Original-Received: from mtaout4.012.net.il ([84.95.2.10]:9253 helo=mtaout3.012.net.il) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MaCMB-000869-Io for emacs-devel@gnu.org; Sun, 09 Aug 2009 13:38:56 -0400 Original-Received: from conversion-daemon.i_mtaout3.012.net.il by i_mtaout3.012.net.il (HyperSendmail v2004.12) id <0KO400800E681A00@i_mtaout3.012.net.il> for emacs-devel@gnu.org; Sun, 09 Aug 2009 20:38:54 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.228.224.142]) by i_mtaout3.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0KO400BUVECTSYC0@i_mtaout3.012.net.il>; Sun, 09 Aug 2009 20:38:54 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by monty-python.gnu.org: Solaris 9.1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:113859 Archived-At: > From: CHENG Gao > 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. 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?