From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: autorevert.el Date: 04 Mar 2004 15:43:40 -0500 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <200403022319.i22NJbG01259@raven.dms.auburn.edu> <200403040508.i2458W811551@raven.dms.auburn.edu> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1078722030 21931 80.91.224.253 (8 Mar 2004 05:00:30 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 8 Mar 2004 05:00:30 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Mon Mar 08 06:00:24 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1B0CsK-00053T-00 for ; Mon, 08 Mar 2004 06:00:24 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1B0CsK-0003CS-00 for ; Mon, 08 Mar 2004 06:00:24 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1B0Cr6-0006uo-RB for emacs-devel@quimby.gnus.org; Sun, 07 Mar 2004 23:59:08 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1Ayzhc-0008B1-LR for emacs-devel@gnu.org; Thu, 04 Mar 2004 15:44:20 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1Ayzh6-00080d-NN for emacs-devel@gnu.org; Thu, 04 Mar 2004 15:44:19 -0500 Original-Received: from [132.204.24.67] (helo=mercure.iro.umontreal.ca) by monty-python.gnu.org with esmtp (Exim 4.30) id 1Ayzh6-00080Y-B9 for emacs-devel@gnu.org; Thu, 04 Mar 2004 15:43:48 -0500 Original-Received: from asado.iro.umontreal.ca (asado.iro.umontreal.ca [132.204.24.84]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 674B720D09; Thu, 4 Mar 2004 15:43:40 -0500 (EST) Original-Received: by asado.iro.umontreal.ca (Postfix, from userid 20848) id 55A398C8E4; Thu, 4 Mar 2004 15:43:40 -0500 (EST) Original-To: Luc Teirlinck In-Reply-To: <200403040508.i2458W811551@raven.dms.auburn.edu> Original-Lines: 44 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-0.904, requis 5, BAYES_30 -0.90) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:20264 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:20264 > Not all parts of the function check the modtime and the two parts > where the modtime gets checked do it in different ways (dired can not > use `verify-visited-file-modtime', because it is not visiting a file). > It seems that the only thing that is done unconditionally in all cases > is check (buffer-modified-p), so I changed the function to first check > this before splitting into cases. Too bad we can't do better, but thanks for double checking for me. > Also, I'd use file-remote-p rather than (string-match "@"), > especially since remote files might not include any @. > You are right. I kept this from the original code. I did not check > this carefully enough. Note that I neither checked the code > of the vc-part of the original patch, not tested it. Well, you've already done more than most of us. > As for the auto-revert-flag thingy, I find it truly ugly because > I don't like dired knowing about auto-revert just for the sake of > verbosity control. There's got to be a better way. > Like what? Dunno! > I need some way to tell not only dired, but other non-file > buffers as well, not to display the revert messages they usually do. Like which others? And why does dired display a message anyway? It seems just wrong to me, since the user knows he reverted the buffer if he did M-x revert-buffer (and indeed M-x revert-buffer in a file buffer does not output any message). It seems these messages should be output (when needed) by the code that calls revert-buffer-function. As does auto-revert, for example. I.e. I suggest to just throw out the dired messages. > I do not know whether you question the usefulness of the verbosity > control itself. No, your example of `make recompile' was pretty compelling already ;-) Stefan