bug#44556: 27.1; Ido deletes file without configuration with C-x C-v C-k

bug#44556: 27.1; Ido deletes file without configuration with C-x C-v C-k

[Christopher Sean Morrison via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Ido is not prompting for file delete confirmation during C-k.

Upon installing Graphene (require 'graphene) which enables Ido
everywhere, I found myself accidentally deleting files when attempting
to switch to other files via C-x C-v and being accustomed to running C-k
to cut the current file name from the minibuffer line and type a new
file name.  For example, touch file1 file2; emacs file1; C-x C-v C-k
file2 [enter].

With default bindings, that's an efficient switch to file2 but instead 
is resulting in file1 being silently deleted.

According to a comment in ido.el, C-k is supposed to confirm the
deletion but no confirmation is presented.  I'm running 27.1 installed
from brew on MacOSX.


Configured using:
 'configure --disable-silent-rules
 --enable-locallisppath=/usr/local/share/emacs/site-lisp
 --infodir=/usr/local/Cellar/emacs/27.1/share/info/emacs
 --prefix=/usr/local/Cellar/emacs/27.1 --with-gnutls --without-x
 --with-xml2 --without-dbus --with-modules --without-ns
 --without-imagemagick'

Configured features:
NOTIFY KQUEUE ACL GNUTLS LIBXML2 ZLIB MODULES THREADS JSON PDUMPER GMP

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  show-paren-mode: t
  project-persist-drawer-mode: t
  project-persist-mode: t
  global-auto-revert-mode: t
  ido-ubiquitous-mode: t
  ido-everywhere: t
  delete-selection-mode: t
  global-company-mode: t
  company-mode: t
  smartparens-global-mode: t
  smartparens-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-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
  global-visual-line-mode: t
  visual-line-mode: t
  transient-mark-mode: t

Load-path shadows:
~/.emacs.d/lisp/cmake-mode hides /usr/local/share/emacs/site-lisp/cmake/cmake-mode

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
format-spec rfc822 mml mml-sec epa derived epg epg-config gnus-util
rmail rmail-loaddefs time-date mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils misearch multi-isearch
jka-compr eieio-opt cl-extra help-fns radix-tree ffap bookmark
text-property-search pp term/xterm xterm flycheck ansi-color find-func
rx paren linum graphene graphene-look graphene-osx-defaults
graphene-projects ppd-sr-speedbar project-persist-drawer sr-speedbar
speedbar sb-image ezimage image dframe project-persist graphene-env
autorevert filenotify ido-completing-read+ memoize minibuf-eldef smex
ido graphene-editing delsel smartparens-html web-mode disp-table
company-oddmuse company-keywords company-etags etags fileloop generator
xref project ring company-gtags company-dabbrev-code company-dabbrev
company-files company-clang company-capf company-cmake company-semantic
company-template company-bbdb company edmacro kmacro pcase
graphene-smartparens-config smartparens-config smartparens-text
smartparens advice help-mode dash graphene-helper-functions finder-inf
cc-styles cc-align cc-engine cc-vars cus-edit cus-start cus-load
wid-edit google-c-style cc-defs regexp-opt cmake-mode thingatpt info
tool-bar package easymenu browse-url url-handlers url-parse auth-source
cl-seq eieio eieio-core cl-macs eieio-loaddefs password-cache json
subr-x map url-vars seq byte-opt gv bytecomp byte-compile cconv
cl-loaddefs cl-lib tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type tabulated-list replace newcomment text-mode elisp-mode
lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch
timer select mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame minibuffer 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 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 kqueue multi-tty make-network-process emacs)

Memory information:
((conses 16 306295 12861)
 (symbols 48 22766 2)
 (strings 32 99999 1371)
 (string-bytes 1 2760347)
 (vectors 16 29865)
 (vector-slots 8 346698 12318)
 (floats 8 104 654)
 (intervals 56 263 0)
 (buffers 1000 13))

bug#44556: 27.1; Ido deletes file without configuration with C-x C-v C-k

[Lars Ingebrigtsen]

Christopher Sean Morrison <brlcad@mac.com> writes:

> Ido is not prompting for file delete confirmation during C-k.
>
> Upon installing Graphene (require 'graphene) which enables Ido
> everywhere, I found myself accidentally deleting files when attempting
> to switch to other files via C-x C-v and being accustomed to running C-k
> to cut the current file name from the minibuffer line and type a new
> file name.  For example, touch file1 file2; emacs file1; C-x C-v C-k
> file2 [enter].

Can you give a recipe for reproducing this bug, starting from
"emacs -Q"?  I do not have Graphene installed (which seems to be a package
from Melpa), so a recipe for reproducing the bug without installing that
package would be nice.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#44556: 27.1; Ido deletes file without configuration with C-x C-v C-k

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Can you give a recipe for reproducing this bug, starting from
> "emacs -Q"?  I do not have Graphene installed (which seems to be a package
> from Melpa), so a recipe for reproducing the bug without installing that
> package would be nice.

More information was requested, but no response was given within a 
month, so I'm closing this bug report.  If the problem still exists,
please respond to this email and we'll reopen the bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#44556: 27.1; Ido deletes file without configuration with C-x C-v C-k

[Jean Louis]

* Lars Ingebrigtsen <larsi@gnus.org> [2020-12-09 18:13]:
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> > Can you give a recipe for reproducing this bug, starting from
> > "emacs -Q"?  I do not have Graphene installed (which seems to be a package
> > from Melpa), so a recipe for reproducing the bug without installing that
> > package would be nice.
> 
> More information was requested, but no response was given within a 
> month, so I'm closing this bug report.  If the problem still exists,
> please respond to this email and we'll reopen the bug report.

I have tried C-x C-v and that completes to open file literally and
then C-k is bound to the function below. I cannot see the bug, it is
rather key binding in ido to delete the file.

C-k runs the command ido-delete-file-at-head (found in
ido-completion-map), which is an interactive compiled Lisp function in
‘ido.el’.

It is bound to C-k.

(ido-delete-file-at-head)

Delete the file at the head of ‘ido-matches’.
Trash the file if ‘delete-by-moving-to-trash’ is non-nil.
If cursor is not at the end of the user input, delete to end of input.

bug#44556: 27.1; Ido deletes file without configuration with C-x C-v C-k

[Christopher Sean Morrison via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> Can you give a recipe for reproducing this bug, starting from
>> "emacs -Q"?  I do not have Graphene installed (which seems to be a package
>> from Melpa), so a recipe for reproducing the bug without installing that
>> package would be nice.
> 
> More information was requested, but no response was given within a 
> month, so I'm closing this bug report.  If the problem still exists,
> please respond to this email and we'll reopen the bug report.

Closing the report is unexpected (and comes across as rude, in my humble opinion, if you’re interested in social interaction feedback).  You asked for a reproduction recipe, which I’d already provided in the original bug report (see the "For example" sentence).  That came across to me as lazy disinterest from an unknown, which I was not inclined to engage.  I realize this may have simply been a misunderstanding due to the manner in which the response was worded.

As I said, I provided the recipe that affected me in the original report — see the “For example” line.  I do not know if this issue occurs in any other context, e.g., with/without Graphene and am not any more available to explore those possibilities.  I did report the bug with the Graphene developer, they investigated, and determined it was a bug in Ido.  That’s why I then took the time to report the issue here with the information I made available.

I don’t know the inner workings of Ido to dig deeper on why it is not prompting for confirmation as that's the crux of this report.  If I ctrl-k, file is deleted silently without confirmation.

bug#44556: 27.1; Ido deletes file without configuration with C-x C-v C-k

[Jean Louis]

* Christopher Sean Morrison via "Bug reports for GNU Emacs, the Swiss
army knife of tex
> I don’t know the inner workings of Ido to dig deeper on why it is
> not prompting for confirmation as that's the crux of this report.
> If I ctrl-k, file is deleted silently without confirmation.

It is made as function in that package. I find it badly designed as
C-k means by default to kill-line and user can make mistake
easily. Why should completing package have function to delete file
during completion?! Wow I am surprised.

Better don't use it.

Use ivy from GNU ELPA.

bug#44556: 27.1; Ido deletes file without configuration with C-x C-v C-k

[Lars Ingebrigtsen]

Christopher Sean Morrison <brlcad@mac.com> writes:

> As I said, I provided the recipe that affected me in the original
> report — see the “For example” line.  I do not know if this issue
> occurs in any other context, e.g., with/without Graphene and am not
> any more available to explore those possibilities.

I interpreted your bug report to say that you needed Graphene to
reproduce the problem, but I see now that you didn't really say that.

The recipe is:

touch file1 file2
emacs -Q -f ido-mode file1
C-x C-v C-k

Emacs will now say "Delete /tmp/file1 (yes or no)", and that is indeed
pretty surprising behaviour.

It's due to this:

(defvar ido-file-completion-map
[...]
    (define-key map "\C-k" 'ido-delete-file-at-head)

I had no idea that that existed -- I use ido myself, but not for files.

Anybody who uses ido for files here?  Do you really use this to delete
files?  It seems really odd to mix up file deletion into a file name
completion framework.

(Reopening this bug report.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#44556: 27.1; Ido deletes file without configuration with C-x C-v C-k

[Jean Louis]

* Lars Ingebrigtsen <larsi@gnus.org> [2020-12-09 23:43]:
> Christopher Sean Morrison <brlcad@mac.com> writes:
> 
> > As I said, I provided the recipe that affected me in the original
> > report — see the “For example” line.  I do not know if this issue
> > occurs in any other context, e.g., with/without Graphene and am not
> > any more available to explore those possibilities.
> 
> I interpreted your bug report to say that you needed Graphene to
> reproduce the problem, but I see now that you didn't really say that.
> 
> The recipe is:
> 
> touch file1 file2
> emacs -Q -f ido-mode file1
> C-x C-v C-k
> 
> Emacs will now say "Delete /tmp/file1 (yes or no)", and that is indeed
> pretty surprising behaviour.

When I do it, it asks nothing, as I have delete-by-moving-to-trash.

But there is one general problem with that function and that is that
C-j is close to C-k and people like me work in the dark not looking at
keyboard. C-j means to complete the file but if C-k is pressed by
mistake file will end up in trash without question and possibly get
lost.

It is good to remove the malfunction from key bindings. Better is to
remove it completely.

bug#44556: 27.1; Ido deletes file without configuration with C-x C-v C-k

[Jean Louis]

* Christopher Sean Morrison via "Bug reports for GNU Emacs, the Swiss army knife of text editors <bug-gnu-emacs@gnu.org> [2020-12-09 23:05]:

> I don’t know the inner workings of Ido to dig deeper on why it is
> not prompting for confirmation as that's the crux of this report.
> If I ctrl-k, file is deleted silently without confirmation.

Do you have variable delete-by-moving-to-trash as T ? Then the file
may be still in your trash to be recovered. It looks like C-k in ido
would ask you to delete the file but if the variable is set, the file
would go silently to Trash.

Anyway I hope that function is completely removed by developers as it
is close to C-j to expand the completion.

Use Ivy for completion or helm.

I found that standard Emacs completion is less obtrusive and equally
efficient. I use Ivy or helm when I need relevance search to match
words apart form each other.

Otherwise using joker *artial-file-name in built-in completion is just
quick.

bug#44556: 27.1; Ido deletes file without configuration with C-x C-v C-k

[Christopher Sean Morrison via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 649 bytes --]



> When I do it, it asks nothing, as I have delete-by-moving-to-trash.

I just checked and that appears to be my situation as well.  I don’t know if Graphene set that variable or some other package (as Graphene uses an amalgamation), but delete-by-moving-to-trash is ’t’ for me and it indeeds asks nothing.  I’d still expect it to prompt, but never even considered looking in the Trash…  (running on Mac platform)

> It is good to remove the malfunction from key bindings. Better is to
> remove it completely.

+1 on removing it completely.  That’s a dangerous binding considering it’s typically “cut to end of line”.


[-- Attachment #2: Type: text/html, Size: 2340 bytes --]

bug#44556: 27.1; Ido deletes file without configuration with C-x C-v C-k

[Lars Ingebrigtsen]

Christopher Sean Morrison <brlcad@mac.com> writes:

>  It is good to remove the malfunction from key bindings. Better is to
>  remove it completely.
>
> +1 on removing it completely.  That’s a dangerous binding considering it’s typically
> “cut to end of line”.

I've now done this in Emacs 29.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#44556: 27.1; Ido deletes file without configuration with C-x C-v C-k

[Morgan Willcock]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Christopher Sean Morrison <brlcad@mac.com> writes:
>
>>  It is good to remove the malfunction from key bindings. Better is to
>>  remove it completely.
>>
>> +1 on removing it completely.  That’s a dangerous binding considering it’s typically
>> “cut to end of line”.
>
> I've now done this in Emacs 29.

I happened across this bug report and was surprised by the end
result. To state my case for a different solution:

- The C-k functionality is one of the core features of ido-mode, as
  evidenced by the same feature being re-implemented to create fido-mode

- The C-k functionality is still present in fido-mode (although it can
  never silently delete a file) with the same key binding active by
  default

- ido-mode is not enabled by default and delete-by-moving-to-trash
  defaults to nil, therefore nothing is silently deleted by default

- "Upon installing Graphene (require 'graphene) which enables Ido
  everywhere". Surely this is the cause of the original issue and the
  Graphene package is at last partially responsible for the problem?

In order to keep the functionality would it be possible to revert the
change but introduce a new ido-mode configuration variable? This new
variable could be checked in place of delete-by-moving-to-trash to
indicate that silent deleting is allowed, and the default value can
prevent silent deleting unless the user enables it.

This would re-align with the fido-mode operation and also protect
against accidental deletions.

Thanks,
Morgan

bug#44556: 27.1; Ido deletes file without configuration with C-x C-v C-k

[Lars Ingebrigtsen]

Morgan Willcock <mwillcock@precedence.co.uk> writes:

> - The C-k functionality is one of the core features of ido-mode, as
>   evidenced by the same feature being re-implemented to create fido-mode

Of course it's not a core feature -- I've used ido mode for years and
never came across it.

> In order to keep the functionality would it be possible to revert the
> change but introduce a new ido-mode configuration variable?

NEWS has instructions for how to re-enable the feature for users that
like it.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no