From: Drew Adams <drew.adams@oracle.com>
To: 17251@debbugs.gnu.org
Subject: bug#17251: 24.4.50; `dired-guess-default': wrong logic
Date: Sat, 12 Apr 2014 09:05:42 -0700 (PDT) [thread overview]
Message-ID: <97d70b54-93f6-4247-9a29-68145f9d8965@default> (raw)
The logic in the implementation of `dired-guess-default' is wrong, or
at least not optimal. And it is not what users are entitled to expect,
based on the doc of `dired-guess-shell-alist-user'.
If this logic is kept as is (which would be unfortunate), then at least
there is a doc bug here, because the doc of user option
`dired-guess-shell-alist-user' does not reflect this logic. Users will
thus get behavior that does not correspond to what they expect based on
the doc.
The doc gives the impression that if you have multiple entries in the
option value that use different regexps with the same command, these
will be used together, IOW, any and all of them will be associated
with the same command.
That is the whole point of this user option (and also of variable
`dired-guess-shell-alist-default'): to associate file names with one
or more commands. The regexps are only a handy means to that end.
For example, from the doc, one can reasonably expect that if the
option value is this:
(("\\.png\\'" "foo.exe") ("\\.jpg\\'" "foo.exe"))
then command "foo.exe" can be used for a list of files such as:
("toto.png" "tata.jpg")
But this is not in fact what the behavior is. To get that expected
behavior, the user would have to combine those entries into a single
entry such as this:
(("\\.\\(png\\|jpg\\)\\'" "foo.exe"))
This is not at all clear from the doc. And it means extra work and
better knowledge of regexps on the part of users.
The culprit code is this part of `dired-guess-default':
;; If more than one file, see if all of FILES match regular expression.
(while (and flist (string-match-p regexp (car flist)))
(setq flist (cdr flist)))
IOW, the code expects each of the files in the list of candidates to
match the given regexp.
In the case above, this means that the regexp "\\.png\\'" would be
tested against each of the files ("toto.png" "tata.jpg"), it would fail,
and so the command "foo.exe", which the user has explicitly configured
as appropriate for both PNG files and JPG files, would not be available.
IOW, instead of working off of the regexp only, the code should work off
of the associated COMMANDS. What is important here is the COMMAND,
"foo.exe", and it is clearly (according to the user) appropriate for
all files whose names match either regexp (i.e., all PNG and JPG files).
IOW, the implementation is overly restrictive. The true requirement is
that each of the file names in the list of candidates must be mapped to
the SAME COMMAND via *some* regexp. The requirement is not (should not
be) that each of the file names must match the SAME REGEXP.
It is the COMMAND that is important. The regexps are just a means of
associating file names with commands.
If you do not fix the implementation logic of `dired-guess-default'
(which would be unfortunate), then please at least fix the doc string of
option `dired-guess-shell-alist-user' so that it tells users that they
MUST COMBINE regexps that are mapped to the same command, i.e., they
must come up with a single regexp for the given command. A list of
files whose names are associated with the same command via different
regexps will not be handled by that command.
In GNU Emacs 24.4.50.1 (i686-pc-mingw32)
of 2014-04-08 on ODIEONE
Bzr revision: 116956 dancol@dancol.org-20140408123940-knoyutxt4l8ws7qm
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
`configure --prefix=/c/Devel/emacs/snapshot/trunk
--enable-checking=yes,glyphs 'CFLAGS=-O0 -g3'
LDFLAGS=-Lc:/Devel/emacs/lib 'CPPFLAGS=-DGC_MCHECK=1
-Ic:/Devel/emacs/include''
next reply other threads:[~2014-04-12 16:05 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-12 16:05 Drew Adams [this message]
2014-04-12 16:28 ` bug#17251: 24.4.50; `dired-guess-default': wrong logic Drew Adams
2021-05-29 5:49 ` Lars Ingebrigtsen
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=97d70b54-93f6-4247-9a29-68145f9d8965@default \
--to=drew.adams@oracle.com \
--cc=17251@debbugs.gnu.org \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).