all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Tino Calancha <f92capac@gmail.com>
Cc: 22694@debbugs.gnu.org
Subject: bug#22694: 25.0.91; dired-mark-files-containing-regexp read file disk
Date: Wed, 20 Apr 2016 17:55:07 +0300	[thread overview]
Message-ID: <83twiw72k4.fsf@gnu.org> (raw)
In-Reply-To: <alpine.LRH.2.20.1604101553280.27325@calancha-ilc.kek.jp> (message from Tino Calancha on Sun, 10 Apr 2016 16:02:59 +0900 (JST))

> Date: Sun, 10 Apr 2016 16:02:59 +0900 (JST)
> From: Tino Calancha <f92capac@gmail.com>
> 
> 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.





  reply	other threads:[~2016-04-20 14:55 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-16 12:47 bug#22694: 25.0.91; dired-mark-files-containing-regexp read file disk Tino Calancha
2016-02-16 16:05 ` Eli Zaretskii
2016-02-17 14:07   ` Tino Calancha
2016-02-24  9:31 ` Tino Calancha
2016-04-10  7:02 ` Tino Calancha
2016-04-20 14:55   ` Eli Zaretskii [this message]
2016-04-20 15:31     ` Tino Calancha
2016-04-20 15:48       ` Eli Zaretskii
2016-06-26 15:32         ` Tino Calancha
2016-07-09 11:07           ` Eli Zaretskii
2016-07-11  5:48             ` Tino Calancha
2016-07-11  5:49 ` bug#22694: (no subject) Tino Calancha

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83twiw72k4.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=22694@debbugs.gnu.org \
    --cc=f92capac@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.