From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark Lillibridge Newsgroups: gmane.emacs.bugs Subject: bug#4887: 23.1; list-load-path-shadows produces broken buffer Date: Fri, 13 Nov 2009 13:57:10 -0800 Message-ID: <200911132157.nADLvAA2016875@mailhub-pa1.hpl.hp.com> References: <200911080534.nA85YsTH029113@mailhub-pa1.hpl.hp.com> <200911111808.nABI8bCo021498@mailhub-pa1.hpl.hp.com> Reply-To: mark.lillibridge@hp.com, 4887@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1258150062 32666 80.91.229.12 (13 Nov 2009 22:07:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 13 Nov 2009 22:07:42 +0000 (UTC) Cc: 4887@emacsbugs.donarmstrong.com To: monnier@iro.umontreal.ca Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Nov 13 23:07:33 2009 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1N94Im-0007vv-08 for geb-bug-gnu-emacs@m.gmane.org; Fri, 13 Nov 2009 23:07:32 +0100 Original-Received: from localhost ([127.0.0.1]:54849 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N94Il-0006EC-LJ for geb-bug-gnu-emacs@m.gmane.org; Fri, 13 Nov 2009 17:07:31 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N94Ig-0006DR-Kf for bug-gnu-emacs@gnu.org; Fri, 13 Nov 2009 17:07:26 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N94Ic-0006Ci-SW for bug-gnu-emacs@gnu.org; Fri, 13 Nov 2009 17:07:26 -0500 Original-Received: from [199.232.76.173] (port=36506 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N94Ic-0006Cf-Mn for bug-gnu-emacs@gnu.org; Fri, 13 Nov 2009 17:07:22 -0500 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:42127) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1N94Ib-0007v3-Td for bug-gnu-emacs@gnu.org; Fri, 13 Nov 2009 17:07:22 -0500 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id nADM7JYS008299; Fri, 13 Nov 2009 14:07:20 -0800 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.14.3/8.14.3/Submit) id nADM550N007708; Fri, 13 Nov 2009 14:05:05 -0800 Resent-Date: Fri, 13 Nov 2009 14:05:05 -0800 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: Mark Lillibridge Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Fri, 13 Nov 2009 22:05:04 +0000 Resent-Message-ID: Resent-Sender: owner@emacsbugs.donarmstrong.com X-Emacs-PR-Message: followup 4887 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by 4887-submit@emacsbugs.donarmstrong.com id=B4887.12581494466693 (code B ref 4887); Fri, 13 Nov 2009 22:05:04 +0000 Original-Received: (at 4887) by emacsbugs.donarmstrong.com; 13 Nov 2009 21:57:26 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-Received: from madara.hpl.hp.com (madara.hpl.hp.com [192.6.19.124]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id nADLvO8U006690 for <4887@emacsbugs.donarmstrong.com>; Fri, 13 Nov 2009 13:57:25 -0800 Original-Received: from mailhub-pa1.hpl.hp.com (mailhub-pa1.hpl.hp.com [15.25.115.25]) by madara.hpl.hp.com (8.14.3/8.14.1/HPL-PA Relay) with ESMTP id nADLvDbS007311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 Nov 2009 13:57:14 -0800 (PST) Original-Received: from ts-rhel4.hpl.hp.com (ts-rhel4.hpl.hp.com [15.25.118.24]) by mailhub-pa1.hpl.hp.com (8.14.3/8.14.3/HPL-PA Hub) with ESMTP id nADLvAA2016875; Fri, 13 Nov 2009 13:57:11 -0800 In-reply-to: (message from Stefan Monnier on Wed, 11 Nov 2009 15:40:48 -0500) X-HPL-MailScanner: Found to be clean X-HPL-MailScanner-From: mark.lillibridge@hp.com X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Resent-Date: Fri, 13 Nov 2009 17:07:26 -0500 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:32600 Archived-At: > > Should linum use a different implementation method than > > define-globalized-minor-mode? (does one exist?) > > You mean global-linum-mode? Yes, it could use a different method, > e.g. setting global hooks instead, but that might prove tricky. > > > Should we instead fix define-globalized-minor-mode to work with all > > buffers? Its documentation via ^h f claims it works in every buffer: > > That would be the best solution, yes. I agree. Any fix that worked for global-linum-mode should presumably be implemented as part of define-globalized-minor-mode so that other global minor modes can benefit as well. > Given the hooks we currently have, it's not very easy because buffers > like *Shadows* get created without running any hook, so basically the > first hook that would get triggered might be something like > window-configuration-change-hook, but that hooks has no easy way to > decide whether that buffer was just created recently or on the contrary > has been around for a long while (in which case enabling linum-mode > might be very wrong since the user may have turned it off there > earlier). I thought about using advice on get-buffer-create, but the manual recommends creating a hook instead. Could we create a new-buffer hook? That would certainly solve the problem and simplify define-globalized-minor-mode. I wonder though, if this would call the minor mode turn on function too early in some cases. Alternatively, it doesn't look very hard to use window-configuration-change-hook; we would have to add some storage to remember which buffers we had already enabled any given minor mode in. > An easier solution is to not change anything to > define-globalized-minor-mode and to require Elisp code to explicitly set > a major mode for any buffer that will be displayed. E.g. for *Shadows* > the Elisp code should explicitly call fundamental-mode in it. This would work as well; who makes the call on these sorts of things? (This is a change of conventions more than a code patch.) - Mark