GNU bug report logs - #42136
26.1.90; rgrep uses a directory that was not actually given

Previous Next

Package: emacs;

Reported by: Benjamin Riefenstahl <Riefenstahl <at> mecom.de>

Date: Tue, 30 Jun 2020 11:08:02 UTC

Severity: normal

Found in version 26.1.90

To reply to this bug, email your comments to 42136 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#42136; Package emacs. (Tue, 30 Jun 2020 11:08:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Benjamin Riefenstahl <Riefenstahl <at> mecom.de>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Tue, 30 Jun 2020 11:08:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Benjamin Riefenstahl <Riefenstahl <at> mecom.de>
To: <bug-gnu-emacs <at> gnu.org>
Subject: 26.1.90; rgrep uses a directory that was not actually given
Date: Tue, 30 Jun 2020 12:45:42 +0200
Receipe:

* M-x make-directory RET "/tmp/cds_config" RET
* rgrep RET abc RET * RET /tmp/cds_c RET

Observed: rgrep searches in "/tmp/cds_config".

Expected: Error message that the directory "/tmp/cds_c" does not exist.
Alternatively a comfirmation question about the completion.

----

Long form of the use case:

I have two projects with similar names "cds_c" and "cds_config".  On
some of my machines both are checked out side-by-side, on some only one
of them is.  Today I called rgrep and gave ".../cds_c" as input for the
directory.  rgrep actually searched in ".../cds_config".  I only later
discovered that that was what happened, initially I thought my pattern
was just not found in my project "cds_c".  I would have expected that
rgrep would complain that the directory does not exist, either during
input or later, instead of silently completing the directory name.

The directory name that was searched is of course in the grep buffer,
but the grep buffer looks like this:

---------
-*- mode: grep; default-directory: "/tmp/cds_config/" -*-
Grep started at Tue Jun 30 12:25:32

find . -type d \( -path \*/CVS -o -path \*/.svn -o -path \*/\{arch\} -o
-path \*/.hg -o -path \*/_darcs -o -path \*/.git -o -path \*/.bzr -o
-path \*/.metadata -o -path \*/.metadata.old -o -path \*/maven-targets
-o -path \*/build -o -path \*/target -o -path \*/projekktor -o -path
\*/node_modules \) -prune -o \! -type d \( -name .\#\* -o -name \*.cmti
-o -name \*.cmt -o -name \*.annot -o -name \*.cmi -o -name \*.cmxa -o
-name \*.cma -o -name \*.cmx -o -name \*.cmo -o -name \*.o -o -name \*\~
-o -name \*.bin -o -name \*.lbin -o -name \*.so -o -name \*.a -o -name
\*.ln -o -name \*.blg -o -name \*.bbl -o -name \*.elc -o -name \*.lof -o
-name \*.glo -o -name \*.idx -o -name \*.lot -o -name \*.fmt -o -name
\*.tfm -o -name \*.class -o -name \*.fas -o -name \*.lib -o -name \*.mem
-o -name \*.x86f -o -name \*.sparcf -o -name \*.dfsl -o -name \*.pfsl -o
-name \*.d64fsl -o -name \*.p64fsl -o -name \*.lx64fsl -o -name
\*.lx32fsl -o -name \*.dx64fsl -o -name \*.dx32fsl -o -name \*.fx64fsl
-o -name \*.fx32fsl -o -name \*.sx64fsl -o -name \*.sx32fsl -o -name
\*.wx64fsl -o -name \*.wx32fsl -o -name \*.fasl -o -name \*.ufsl -o
-name \*.fsl -o -name \*.dxl -o -name \*.lo -o -name \*.la -o -name
\*.gmo -o -name \*.mo -o -name \*.toc -o -name \*.aux -o -name \*.cp -o
-name \*.fn -o -name \*.ky -o -name \*.pg -o -name \*.tp -o -name \*.vr
-o -name \*.cps -o -name \*.fns -o -name \*.kys -o -name \*.pgs -o -name
\*.tps -o -name \*.vrs -o -name \*.pyc -o -name \*.pyo \) -prune -o
-type f ! -name '*[~#]*' ! -name TAGS ! -name '*.patch' ! -name '*.jpg'
! -name '*.log' ! -name '*.log.*' \( -name \* \) -print0 | xargs -0 -e
grep --color -i -nH -e abc

Grep finished with no matches found at Tue Jun 30 12:25:32
---------

And of course I was concentrating on the bottom where it says "no
matches", not at all on the top of the buffer to confirm that rgrep
actually did what I just told it to do.

I tried to find if the behaviour was somehow customizable, but it seems
not.

----

In GNU Emacs 26.1.90 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.18.9)
 of 2018-11-22 built on riefenstahl-thinkpad
Repository revision: 93242b14769ed40ae58e89d0ea45df8872f59869
Windowing system distributor 'The X.Org Foundation', version 11.0.11906000
System Description:	Ubuntu 16.04.6 LTS

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS GLIB
NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM THREADS LCMS2

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Emacs-Lisp

Minor modes in effect:
  global-magit-file-mode: t
  global-git-commit-mode: t
  async-bytecomp-package-mode: t
  desktop-save-mode: t
  display-time-mode: t
  diff-auto-refine-mode: t
  delete-selection-mode: t
  shell-dirtrack-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug sendmail pulse xref project cl-print
debug eieio-opt speedbar sb-image ezimage dframe find-func help-fns
markdown-mode color noutline outline sql view conf-mode yaml-mode
magit-find-file find-dired calculator dirtrack log-view vc vc-dispatcher
json-mode json-reformat json-snatcher js sgml-mode dom json map
thingatpt misearch multi-isearch sh-script smie executable dired-aux
bug-reference edmacro kmacro magit-extras magit-submodule magit-obsolete
magit-popup magit-blame magit-stash magit-reflog magit-bisect magit-push
magit-pull magit-fetch magit-clone magit-remote magit-commit
magit-sequence magit-notes magit-worktree magit-tag magit-merge
magit-branch magit-reset magit-files magit-refs magit-status magit
magit-repos magit-apply magit-wip magit-log magit-diff smerge-mode
magit-core magit-autorevert autorevert filenotify magit-margin
magit-transient magit-process magit-mode transient git-commit magit-git
magit-section magit-utils crm log-edit message-x message rmc puny rfc822
mml mml-sec epa epg gnus-util rmail rmail-loaddefs mm-decode mm-bodies
mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums mailabbrev
mail-utils gmm-utils mailheader pcvs-util add-log with-editor cl-extra
help-mode async-bytecomp async subr-x dash files-x elec-pair desktop
frameset highline ange-ftp generic-x cl autoinsert ps-print
ps-print-loaddefs ps-def lpr dired dired-loaddefs benny-x-clipboard
disp-table mm-util mail-prsvr time server protbuf solar cal-dst
cal-islam cal-hebrew holidays hol-loaddefs vc-git diff-mode easy-mmode
benny-mtff-mode diary-lib diary-loaddefs cal-menu calendar cal-loaddefs
which-func imenu jka-compr grep compile delsel cus-start cus-load
tty-format generic benny-calendar-cfg derived browse-url cc-mode
cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars
cc-defs benny-file-cache filecache tramp-sh docker-tramp tramp-cache
tramp tramp-compat tramp-loaddefs trampver ucs-normalize shell pcomplete
comint ansi-color ring parse-time format-spec advice benny-unicode
.loaddefs benny-tools autoload radix-tree lisp-mnt finder-inf gh-common
marshal eieio-compat rx info package easymenu epg-config url-handlers
url-parse auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache url-vars seq byte-opt gv bytecomp byte-compile cconv
cl-loaddefs cl-lib time-date mule-util tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads dbusbind inotify lcms2 dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty make-network-process emacs)

Memory information:
((conses 16 702186 71703)
 (symbols 48 40155 2)
 (miscs 40 7447 2586)
 (strings 32 108374 9705)
 (string-bytes 1 3586419)
 (vectors 16 71858)
 (vector-slots 8 1930070 196080)
 (floats 8 913 803)
 (intervals 56 43045 2395)
 (buffers 992 98)
 (heap 1024 68850 3631))




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#42136; Package emacs. (Tue, 30 Jun 2020 12:28:01 GMT) Full text and rfc822 format available.

Message #8 received at 42136 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Benjamin Riefenstahl <Riefenstahl <at> mecom.de>, 42136 <at> debbugs.gnu.org
Cc: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Subject: Re: bug#42136: 26.1.90; rgrep uses a directory that was not actually
 given
Date: Tue, 30 Jun 2020 15:26:58 +0300
Hi!

On 30.06.2020 13:45, Benjamin Riefenstahl wrote:
> Receipe:
> 
> * M-x make-directory RET "/tmp/cds_config" RET
> * rgrep RET abc RET * RET /tmp/cds_c RET
> 
> Observed: rgrep searches in "/tmp/cds_config".
> 
> Expected: Error message that the directory "/tmp/cds_c" does not exist.
> Alternatively a comfirmation question about the completion.

RET is bound to minibuffer-complete-and-exit. So the result seems expected.

Did this scenario behave differently in some recent version of Emacs?

To be fair, the docstring of this command says it behaves differently 
with different values of minibuffer-completion-confirm. But that 
variable doesn't seem to be customizable by the user.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#42136; Package emacs. (Tue, 30 Jun 2020 12:53:02 GMT) Full text and rfc822 format available.

Message #11 received at 42136 <at> debbugs.gnu.org (full text, mbox):

From: Benjamin Riefenstahl <Riefenstahl <at> mecom.de>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: Stefan Monnier <monnier <at> IRO.UMontreal.CA>, 42136 <at> debbugs.gnu.org
Subject: Re: bug#42136: 26.1.90;
 rgrep uses a directory that was not actually given
Date: Tue, 30 Jun 2020 14:51:58 +0200
Hi Dimitry,

Thanks for taking a look.

Dmitry Gutov writes:
> RET is bound to minibuffer-complete-and-exit. So the result seems
> expected.

The result seems as designed.  I expected something different.

> Did this scenario behave differently in some recent version of Emacs?

Probably not.

> To be fair, the docstring of this command says it behaves differently
> with different values of minibuffer-completion-confirm.

The variations here seem be the same as the MUSTMATCH parameter to
read-file-name.  I had tested those and none of those seem to do what I
want.

It's not like I do not like completion in general, but for me and in
this situation I want it only on-demand (with TAB), not automatic and
with almost no feedback about the choice that was actually made.

I may just learn my lesson here for now, but I'm not sure this is good.
Also I wanted to hear if anybody has a tip about some customization that
I was missing.

benny




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#42136; Package emacs. (Wed, 01 Jul 2020 22:11:02 GMT) Full text and rfc822 format available.

Message #14 received at 42136 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Benjamin Riefenstahl <Riefenstahl <at> mecom.de>
Cc: 42136 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> IRO.UMontreal.CA>,
 Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#42136: 26.1.90; rgrep uses a directory that was not
 actually given
Date: Thu, 02 Jul 2020 00:46:06 +0300
> Also I wanted to hear if anybody has a tip about some customization that
> I was missing.

Maybe some advice might help you:

(advice-add 'read-directory-name :around
            (lambda (orig-fun prompt &optional dir default-dirname
			      mustmatch initial)
              (cond
	       ((equal prompt "Base directory: ")
		(funcall orig-fun prompt dir default-dirname
			 nil initial))
               (t
		(funcall orig-fun prompt dir default-dirname
			 mustmatch initial))))
            '((name . read-directory-name-no-mustmatch)))

It overrides the MUSTMATCH argument of read-directory-name in rgrep.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#42136; Package emacs. (Fri, 03 Jul 2020 14:12:01 GMT) Full text and rfc822 format available.

Message #17 received at 42136 <at> debbugs.gnu.org (full text, mbox):

From: Benjamin Riefenstahl <b.riefenstahl <at> turtle-trading.net>
To: Juri Linkov <juri <at> linkov.net>
Cc: 42136 <at> debbugs.gnu.org, Benjamin Riefenstahl <Riefenstahl <at> mecom.de>,
 Stefan Monnier <monnier <at> IRO.UMontreal.CA>, Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#42136: 26.1.90; rgrep uses a directory that was not
 actually given
Date: Fri, 03 Jul 2020 16:10:54 +0200
Hi Juri,

Juri Linkov writes:
> (advice-add 'read-directory-name :around
>             (lambda (orig-fun prompt &optional dir default-dirname
> 			      mustmatch initial)
>               (cond
> 	       ((equal prompt "Base directory: ")
> 		(funcall orig-fun prompt dir default-dirname
> 			 nil initial))
>                (t
> 		(funcall orig-fun prompt dir default-dirname
> 			 mustmatch initial))))
>             '((name . read-directory-name-no-mustmatch)))
>
> It overrides the MUSTMATCH argument of read-directory-name in rgrep.

Thanks for the suggestion.  Sadly this seems to make things worse:

* emacs -Q (in ~)
* Eval your advice. 
* M-x make-directory RET /tmp/test RET
* M-x rgrep RET [...] /tmp/te RET
* Result: No confirmation, the search runs in "~" (!)

I tried read-directory-name with all variations of MUSTMATCH, and I
believe none of them helps me here.  I guess I want an additional mode,
like 'confirm-automatic-completion, which handles TAB as before, but
with RET it would require confirmation before changing the result.

benny




This bug report was last modified 3 years and 290 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.