* bug#35609: 26.2; wdired-finish-edit clears find-dired listing @ 2019-05-03 8:42 Alvaro Ramirez 2019-07-09 3:03 ` Lars Ingebrigtsen 0 siblings, 1 reply; 6+ messages in thread From: Alvaro Ramirez @ 2019-05-03 8:42 UTC (permalink / raw) To: 35609 Editing a find-dired buffer (via wdired) clears the list of files after saving changes. Steps: 1. M-x find-dired RET 2. RET (empty or any find args should do) 3. C-x C-q (dired-toggle-read-only) 4. Rename any file. 5. C-c C-c (wdired-finish-edit) Expected behavior: All files listed by find command should be listed in dired buffer. Actual behavior: No files are listed. More info: `revert-buffer-function' originally set by `find-dired' may be lost by wdired when switching between wdired and dired mode. In GNU Emacs 26.2 (build 1, x86_64-apple-darwin18.5.0, NS appkit-1671.40 Version 10.14.4 (Build 18E227)) of 2019-05-03 built on taiyaki.local Windowing system distributor 'Apple', version 10.3.1671 Recent messages: find-dired *Find* finished. Press C-c C-c when finished or C-c ESC to abort changes Making completion list... [4 times] user-error: Previous command was not a yank [2 times] Quit [3 times] Making completion list... uncompressing wdired.el.gz...done Mark saved where search started [2 times] Mark set Making completion list... Configured using: 'configure --disable-dependency-tracking --disable-silent-rules --enable-locallisppath=some/path/share/emacs/site-lisp --infodir=some/path/Cellar/emacs-plus/26.2/share/info/emacs --prefix=some/path/Cellar/emacs-plus/26.2 --with-xml2 --without-dbus --with-gnutls --with-imagemagick --with-modules --with-rsvg --with-ns --disable-ns-self-contained' Configured features: JPEG RSVG IMAGEMAGICK GLIB NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS MODULES THREADS LCMS2 Important settings: value of $LANG: en_GB.UTF-8 locale-coding-system: utf-8-unix Major mode: Emacs-Lisp Minor modes in effect: shell-dirtrack-mode: t diff-auto-refine-mode: t tooltip-mode: t global-eldoc-mode: t eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr jka-compr thingatpt find-func emacsbug message rmc puny format-spec rfc822 mml mml-sec password-cache epa derived epg epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils dired-aux wdired shell pcomplete comint ansi-color ring find-dired misearch multi-isearch vc-git diff-mode easymenu easy-mmode map seq byte-opt gv bytecomp byte-compile cconv cl-loaddefs cl-lib dired dired-loaddefs elec-pair time-date tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/ns-win ns-win ucs-normalize mule-util term/common-win 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 kqueue cocoa ns lcms2 multi-tty make-network-process emacs) Memory information: ((conses 16 221588 12374) (symbols 48 21417 1) (miscs 40 78 428) (strings 32 33343 1439) (string-bytes 1 907133) (vectors 16 37119) (vector-slots 8 753205 10098) (floats 8 52 262) (intervals 56 1173 16) (buffers 992 17)) ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#35609: 26.2; wdired-finish-edit clears find-dired listing 2019-05-03 8:42 bug#35609: 26.2; wdired-finish-edit clears find-dired listing Alvaro Ramirez @ 2019-07-09 3:03 ` Lars Ingebrigtsen 2019-07-15 10:54 ` Stephen Berman 0 siblings, 1 reply; 6+ messages in thread From: Lars Ingebrigtsen @ 2019-07-09 3:03 UTC (permalink / raw) To: Alvaro Ramirez; +Cc: 35609 Alvaro Ramirez <alvaro@xenodium.com> writes: > Editing a find-dired buffer (via wdired) clears the list of files after > saving changes. > > Steps: > > 1. M-x find-dired RET > 2. RET (empty or any find args should do) > 3. C-x C-q (dired-toggle-read-only) In Emacs 27 (on GNU/Linux), it hangs there in Debugger entered--Lisp error: (quit) looking-at("^. [0-9 \11]*[.,0-9]*[BkKMGTPEZY]?[ \11]*l[^:]") wdired-preprocess-symlinks() So there's been further regressions in this area, I guess... -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#35609: 26.2; wdired-finish-edit clears find-dired listing 2019-07-09 3:03 ` Lars Ingebrigtsen @ 2019-07-15 10:54 ` Stephen Berman 2019-07-15 17:33 ` Lars Ingebrigtsen 0 siblings, 1 reply; 6+ messages in thread From: Stephen Berman @ 2019-07-15 10:54 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: Alvaro Ramirez, 35609, Roland Winkler On Tue, 09 Jul 2019 05:03:20 +0200 Lars Ingebrigtsen <larsi@gnus.org> wrote: > Alvaro Ramirez <alvaro@xenodium.com> writes: > >> Editing a find-dired buffer (via wdired) clears the list of files after >> saving changes. >> >> Steps: >> >> 1. M-x find-dired RET >> 2. RET (empty or any find args should do) >> 3. C-x C-q (dired-toggle-read-only) > > In Emacs 27 (on GNU/Linux), it hangs there in > > Debugger entered--Lisp error: (quit) > looking-at("^. [0-9 \11]*[.,0-9]*[BkKMGTPEZY]?[ \11]*l[^:]") > wdired-preprocess-symlinks() > > So there's been further regressions in this area, I guess... I don't have a fix for the find-dired listing being cleared, but the hang is due to this change: commit 249902d5ad5d3ae3e25323c23a2f442913729ceb Author: Roland Winkler <winkler@gnu.org> Date: Tue Jun 11 16:04:45 2019 -0500 Allow refining the *Find* buffer of find-dired. (Bug#29513) * find-dired.el (find-dired-refine-function): New user variable. (find-dired-sentinel): Use it. Simplify. (find-dired-sort-by-filename): New function. Specifically, the change in find-dired-sentinel from this: - (insert "\n find " state) - (forward-char -1) ;Back up before \n at end of STATE. - (insert " at " (substring (current-time-string) 0 19)) to this: + (insert "\n find " + (substring state 0 -1) ; omit \n at end of STATE. + " at " (substring (current-time-string) 0 19)) Reverting this change (i.e. just these three lines) prevents the hang, but it's not clear to me whether this was just meant to simplify the code, as stated in the ChangeLog, or omitting the final newline is needed for some find-dired use case. Roland, can you elucidate? However, independently of reverting or retaining the above lines, the hang can also be prevented by changing wdired-preprocess-symlinks thus: diff --git a/lisp/wdired.el b/lisp/wdired.el index 0ccaaaca74..44f083bb7f 100644 --- a/lisp/wdired.el +++ b/lisp/wdired.el @@ -677,8 +677,7 @@ wdired-preprocess-symlinks 'rear-nonsticky '(read-only)) (put-text-property (match-beginning 1) (match-end 1) 'read-only nil))) - (forward-line) - (beginning-of-line))))) + (forward-line))))) (defun wdired-get-previous-link (&optional old move) These lines are at the end of a while (not (eobp)) loop and, unless I'm overlooking something, prior to the change to find-dired-sentinel, the use of beginning-of-line here was a noop, since forward-line always puts point at BOL -- except when the buffer doesn't end with a newline, and that's why the change to find-dired-sentinel caused the find-dired hang. Thus, reverting the above three lines of the find-dired-sentinel change makes beginning-of-line in wdired-preprocess-symlinks strictly a noop, while retaining that change makes calling beginning-of-line harmful, so in any case that call should removed. Or does anyone see a problem with that? Steve Berman ^ permalink raw reply related [flat|nested] 6+ messages in thread
* bug#35609: 26.2; wdired-finish-edit clears find-dired listing 2019-07-15 10:54 ` Stephen Berman @ 2019-07-15 17:33 ` Lars Ingebrigtsen 2019-07-15 18:37 ` Roland Winkler 0 siblings, 1 reply; 6+ messages in thread From: Lars Ingebrigtsen @ 2019-07-15 17:33 UTC (permalink / raw) To: Stephen Berman; +Cc: Alvaro Ramirez, 35609, Roland Winkler Stephen Berman <stephen.berman@gmx.net> writes: > - (forward-line) > - (beginning-of-line))))) > + (forward-line))))) > > (defun wdired-get-previous-link (&optional old move) > > These lines are at the end of a while (not (eobp)) loop and, unless I'm > overlooking something, prior to the change to find-dired-sentinel, the > use of beginning-of-line here was a noop, since forward-line always puts > point at BOL -- except when the buffer doesn't end with a newline, and > that's why the change to find-dired-sentinel caused the find-dired hang. > Thus, reverting the above three lines of the find-dired-sentinel change > makes beginning-of-line in wdired-preprocess-symlinks strictly a noop, > while retaining that change makes calling beginning-of-line harmful, so > in any case that call should removed. Or does anyone see a problem with > that? Yes, I think you're right -- removing that beginning-of-line is the correct thing, no matter what. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#35609: 26.2; wdired-finish-edit clears find-dired listing 2019-07-15 17:33 ` Lars Ingebrigtsen @ 2019-07-15 18:37 ` Roland Winkler 2019-07-16 9:09 ` Stephen Berman 0 siblings, 1 reply; 6+ messages in thread From: Roland Winkler @ 2019-07-15 18:37 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: Alvaro Ramirez, Stephen Berman, 35609 On Mon Jul 15 2019 Lars Ingebrigtsen wrote: > Yes, I think you're right -- removing that beginning-of-line is the > correct thing, no matter what. Agreed. (These parts of my recent changes were my attempt to streamline / simplify these parts of the code. If some part of my new code doesn't do what it needs to do, it means that I overlooked something.) ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#35609: 26.2; wdired-finish-edit clears find-dired listing 2019-07-15 18:37 ` Roland Winkler @ 2019-07-16 9:09 ` Stephen Berman 0 siblings, 0 replies; 6+ messages in thread From: Stephen Berman @ 2019-07-16 9:09 UTC (permalink / raw) To: Roland Winkler; +Cc: Lars Ingebrigtsen, 35609, Alvaro Ramirez On Mon, 15 Jul 2019 13:37:17 -0500 "Roland Winkler" <winkler@gnu.org> wrote: > On Mon Jul 15 2019 Lars Ingebrigtsen wrote: >> Yes, I think you're right -- removing that beginning-of-line is the >> correct thing, no matter what. > > Agreed. (These parts of my recent changes were my attempt to > streamline / simplify these parts of the code. If some part of my > new code doesn't do what it needs to do, it means that I overlooked > something.) Ok, I pushed that change to master (288e83ae00). I referenced this bug thread but of course the bug should not be closed yet. Steve Berman ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-07-16 9:09 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2019-05-03 8:42 bug#35609: 26.2; wdired-finish-edit clears find-dired listing Alvaro Ramirez 2019-07-09 3:03 ` Lars Ingebrigtsen 2019-07-15 10:54 ` Stephen Berman 2019-07-15 17:33 ` Lars Ingebrigtsen 2019-07-15 18:37 ` Roland Winkler 2019-07-16 9:09 ` Stephen Berman
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.