--- Begin Message ---
|
Subject: |
26.1; wdired: broken 'wdired-use-interactive-rename' |
|
Date: |
Mon, 16 Jul 2018 15:28:29 +0200 |
Hi,
wdired seems to misbehave when 'wdired-use-interactive-rename' is
active:
1. create scratch directory with a file
mkdir /tmp/test
cd /tmp/test
touch foo.c
2. start emacs
LC_ALL=C emacs -Q -nw
3. set option above
M-: (setq wdired-use-interactive-rename t)
4. go into the folder
C-x C-f /tmp/test
emacs will show
| /tmp/test:
| total used in directory 0 available 4023272
| drwxrwxr-x. 2 ensc ensc 60 Jul 16 15:16 .
| drwxrwxrwt. 18 root root 600 Jul 16 15:17 ..
| -rw-rw-r--. 1 ensc ensc 0 Jul 16 14:58 foo.c
5. enter wdired mode
C-x C-q
6. replace 'foo' with 'test'; e.g.
test M-d
7. commit it
C-c C-c
---> emacs asks
| Move `c' to `test.c'? [Type yn!q or C-h]
or
| Move `.' to `test.c'? [Type yn!q or C-h]
(seems to differ slightly when repeating step 6). Buffer content is
malformed too (first two lines are merged, or whitespace between time
and filename is removed).
Confirming with 'y' will make the operation fail because the requested
source file does not exist.
Without the interactive rename, things seem to be fine.
Enrico
----------------------------
In GNU Emacs 26.1 (build 1, x86_64-redhat-linux-gnu, GTK+ Version 2.24.32)
of 2018-05-31 built on koji-builder4.intern.sigma-chemnitz.de
Windowing system distributor 'Fedora Project', version 11.0.11906000
Configured using:
'configure --build=x86_64-redhat-linux-gnu
--host=x86_64-redhat-linux-gnu --program-prefix=
--disable-dependency-tracking --prefix=/usr --exec-prefix=/usr
--bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
--datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64
--libexecdir=/usr/libexec --localstatedir=/var
--sharedstatedir=/var/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-dbus --with-gif --with-jpeg --with-png
--with-rsvg --with-tiff --with-xft --with-xpm --with-x-toolkit=gtk
--with-gpm=no --with-modules build_alias=x86_64-redhat-linux-gnu
host_alias=x86_64-redhat-linux-gnu 'CFLAGS=-DMAIL_USE_LOCKF -O2 -g
-pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
-grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection'
LDFLAGS=-Wl,-z,relro
PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'
Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND DBUS GSETTINGS NOTIFY ACL
LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK2 X11 MODULES THREADS LCMS2
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#32173: 26.1; wdired: broken 'wdired-use-interactive-rename' |
|
Date: |
Wed, 08 Aug 2018 12:04:26 +0200 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
On Sun, 29 Jul 2018 01:21:25 +0200 Stephen Berman <address@hidden> wrote:
> On Fri, 27 Jul 2018 23:59:19 +0300 Eli Zaretskii <address@hidden> wrote:
>
>>> From: Stephen Berman <address@hidden>
>>> Cc: address@hidden, address@hidden
>>> Date: Fri, 27 Jul 2018 20:15:38 +0200
>>>
>>> > Thanks. I think we should install your original and safer patch on
>>> > the release branch, and this more thorough fix on master. WDYT?
>>>
>>> Sounds reasonable. Should we give the OP a bit longer to react or
>>> should I just go ahead and commit the fixes (in any case, I may not be
>>> able to until tomorrow or Sunday)?
>>
>> I think by then we will have waited long enough.
>>
>>> I also wrote three tests, two for the bug with non-nil
>>> wdired-use-interactive-rename, one where the edit is finished and one
>>> where it's aborted, and one test for unfinished edits (it might be nice
>>> to have a variant of the latter that uses dired-isearch-filenames, but I
>>> don't see any straightforward way to emulate isearch in the test
>>> environment). The first two tests are suitable for both fixes, but the
>>> third test only succeeds with the fix intended for master, so I use the
>>> :expected-result keyword in the test definition. But should I install
>>> the test file on each branch as part of the commit with the respective
>>> fix (which won't be merged from release to master), or should I make a
>>> separate commit of the test file just to the release branch and let it
>>> be merged to master?
>>
>> You can commit the tests to the emacs-26 branch and let it be merged.
>>
>> Thanks.
>
> I committed the fixes and the tests. I'll wait another couple of days
> to see if the OP responds, and then close the bug.
Done (better later than never).
Steve Berman
--- End Message ---