Re: Dired delete(d) the wrong file!

[Michael Heerdegen via "Emacs development discussions." <emacs-devel@gnu.org>]

Po Lu <luangruo@yahoo.com> writes:

> Yes, that was my point.  Something on Dave's system is otherwise than it
> is on the system where Dired was reported to identify the correct file.

Edebugging `insert-directory-clean' reveals that here:

#+begin_src emacs-lisp
	  (while (< (point) end)
	    (let ((start (insert-directory-adj-pos
			  (+ beg (read (current-buffer)))
			  error-lines))
		  (end (insert-directory-adj-pos
			(+ beg (read (current-buffer)))
			error-lines)))
	      (if (memq (char-after end) '(?\n ?\s))
		  ;; End is followed by \n or by " -> ".
		  (put-text-property start end 'dired-filename t)
		;; It seems that we can't trust ls's output as to
		;; byte positions of filenames.
		(put-text-property beg (point) 'dired-filename nil)
		(end-of-line))))
#+end_src

the loop gets aborted because the (memq (char-after end) '(?\n ?\s)) call,
when using Dave's ls options, returns the slash character that comes after
".":

| bash-5.2:micha:tmp$ ls -alF --dired
|   total 72
|   drwxr-xr-x   3 micha micha  4096 Jul  5 07:26  ./
|   drwxr-xr-x 213 micha micha 61440 Jul  5 07:07  ../
|   -rw-rw-r--   1 micha micha     0 Jul  5 07:25 '07 nov 2395 zz.kk'
|   drwxr-xr-x   3 micha micha  4096 Jun 23  2014  src/
| //DIRED// 60 61 112 114 164 183 233 236
| //DIRED-OPTIONS// --quoting-style=shell-escape

and so we throw away that information.  60 and 61 are the positions
before and after the "." directory.


Michael.