From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#22694: 25.0.91; dired-mark-files-containing-regexp read file disk Date: Wed, 20 Apr 2016 17:55:07 +0300 Message-ID: <83twiw72k4.fsf@gnu.org> References: Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1461164401 12146 80.91.229.3 (20 Apr 2016 15:00:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 20 Apr 2016 15:00:01 +0000 (UTC) Cc: 22694@debbugs.gnu.org To: Tino Calancha Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Apr 20 16:59:50 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1astbZ-0007Hw-M8 for geb-bug-gnu-emacs@m.gmane.org; Wed, 20 Apr 2016 16:59:49 +0200 Original-Received: from localhost ([::1]:50822 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1astbY-0007M2-U5 for geb-bug-gnu-emacs@m.gmane.org; Wed, 20 Apr 2016 10:59:48 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40186) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1astXz-0007Ay-4i for bug-gnu-emacs@gnu.org; Wed, 20 Apr 2016 10:56:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1astXu-00078L-3X for bug-gnu-emacs@gnu.org; Wed, 20 Apr 2016 10:56:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:57423) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1astXt-00078H-Vh for bug-gnu-emacs@gnu.org; Wed, 20 Apr 2016 10:56:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1astXt-0006Tz-QJ for bug-gnu-emacs@gnu.org; Wed, 20 Apr 2016 10:56:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 20 Apr 2016 14:56:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22694 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 22694-submit@debbugs.gnu.org id=B22694.146116413024880 (code B ref 22694); Wed, 20 Apr 2016 14:56:01 +0000 Original-Received: (at 22694) by debbugs.gnu.org; 20 Apr 2016 14:55:30 +0000 Original-Received: from localhost ([127.0.0.1]:41527 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1astXO-0006TD-4n for submit@debbugs.gnu.org; Wed, 20 Apr 2016 10:55:30 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:48935) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1astXL-0006T1-Pj for 22694@debbugs.gnu.org; Wed, 20 Apr 2016 10:55:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1astXA-0006xX-Ff for 22694@debbugs.gnu.org; Wed, 20 Apr 2016 10:55:22 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:45699) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1astXA-0006xP-CP; Wed, 20 Apr 2016 10:55:16 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3377 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1astX9-00044X-9M; Wed, 20 Apr 2016 10:55:15 -0400 In-reply-to: (message from Tino Calancha on Sun, 10 Apr 2016 16:02:59 +0900 (JST)) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:116630 Archived-At: > Date: Sun, 10 Apr 2016 16:02:59 +0900 (JST) > From: Tino Calancha > > 1) An user submit several hundred of jobs to a batch server. > > 2) The output consist of just log files (1 per job) which are written > under the submission directory until the jobs succeded of fail. > When the job fails, the logfile contains the word 'aborting'. > > 3) To resubmit the failed jobs, the user may put all logfiles together in a > dired buffer using `find-name-dired'. From time to time, he/she call > `dired-mark-files-containing-regexp' using 'aborting' as regexp: from this, > he/she obtain directly the list of failed jobs... > > 4) ...But if the user has opened some of the logfiles from failed jobs, the word > 'aborting' may not be in the buffer (the user need to revert it first), so the > list of failed jobs at 3) will not be exhaustive. This behaviour is not > consistent with the doc. string of the function: Making the doc string more explicit about this aspect is indeed a good idea. I've just did it on the emacs-25 branch. As for your scenario: when you work with logfiles, or any other kind of files that get updated regularly behind Emacs's back, you should turn on auto-revert-mode or auto-revert-tail-mode in the buffers of those files. Then the buffer's contents will be synchronized with the relevant files on disk, and the problem you describe would not exist. Bottom line, I don't think I agree with permanently changing the implementation along the lines you suggest, as that would be against the general principles (AFAIK them) of Dired's design, and actually also against the general principles of Emacs design vis-a-vis files and buffers that visit them: we don't automatically sync a buffer with the file it visits, and we don't automatically look on disk when the file's buffer differs from what's on disk. I guess we could have an option to switch to the behavior you would like to see, but such an option, if we introduce it, IMO should not be specific to this command, it should affect all the Dired commands which might produce different results when buffers are not auto-reverted. Another alternative is to have an optional feature that would ask whether to revert a buffer if Emacs finds that it was changed on disk since last visited. Thanks.