* 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 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).