GNU bug report logs -
#48659
Escapes are deleted after executing "dired-toggle-read-only" in *Find* buffer
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 48659 in the body.
You can then email your comments to 48659 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48659
; Package
emacs
.
(Tue, 25 May 2021 20:54:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Rodrigo Morales <moralesrodrigo1100 <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Tue, 25 May 2021 20:54:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
* The context
By default, when executing =find-dired=, spaces are escaped (see below)
#+BEGIN_EXAMPLE
/home/thisisme/e/:
find . \( -type f \) -ls
29754046 0 -rw-r--r-- 1 thisisme thisisme 0 May 25 15:25 a/bar\ bar.txt
29753703 0 -rw-r--r-- 1 thisisme thisisme 0 May 25 15:25 a/foo\ foo.txt
29754079 0 -rw-r--r-- 1 thisisme thisisme 0 May 25 15:25 b/bar\ bar.txt
29754078 0 -rw-r--r-- 1 thisisme thisisme 0 May 25 15:25 b/foo\ foo.txt
find finished at Tue May 25 15:25:42
#+END_EXAMPLE
This happens because that's the default behavior of =find= when we
execute it in the command-line.
#+begin_src bash
find . \( -type f \) -ls
#+end_src
#+RESULTS:
#+begin_example
29754078 0 -rw-r--r-- 1 thisisme thisisme 0 May 25 15:25 ./b/foo\ foo.txt
29754079 0 -rw-r--r-- 1 thisisme thisisme 0 May 25 15:25 ./b/bar\ bar.txt
29753703 0 -rw-r--r-- 1 thisisme thisisme 0 May 25 15:25 ./a/foo\ foo.txt
29754046 0 -rw-r--r-- 1 thisisme thisisme 0 May 25 15:25 ./a/bar\ bar.txt
#+end_example
* The issue
This is causing =dired-toggle-read-only= to remove spaces after
finishing editing the buffer. I would consider this a bug, but let me
explain this further so that we all can determine whether this is a bug
or not.
* Minimal reproducible example
Let's suppose we have this directory
#+begin_src bash
mkdir {a,b} && touch {a,b}/{foo\ foo,bar\ bar}.txt
#+end_src
#+begin_src bash
tree -a --noreport
#+end_src
#+RESULTS:
#+begin_example
.
├── a
│ ├── bar bar.txt
│ └── foo foo.txt
└── b
├── bar bar.txt
└── foo foo.txt
#+end_example
Let's execute =find-dired= and let's list the files (i.e. =-type
f=). The buffer =*Find*= would show the following
#+begin_example
/home/thisisme/e/:
find . \( -type f \) -ls
29754046 0 -rw-r--r-- 1 thisisme thisisme 0 May 25 15:30 a/bar\ bar.txt
29753703 0 -rw-r--r-- 1 thisisme thisisme 0 May 25 15:30 a/foo\ foo.txt
29754079 0 -rw-r--r-- 1 thisisme thisisme 0 May 25 15:30 b/bar\ bar.txt
29754078 0 -rw-r--r-- 1 thisisme thisisme 0 May 25 15:30 b/foo\ foo.txt
find finished at Tue May 25 15:30:49
#+end_example
Now, let's toggle a =dired-toggle-read-only= and edit any name (I
appended =test= after the =a/barbar.txt= file).
Now, see what =tree= reports.
#+begin_src bash
tree -a --noreport
#+end_src
#+RESULTS:
#+begin_example
.
├── a
│ ├── barbar.txt-test
│ └── foofoo.txt
└── b
├── barbar.txt
└── foofoo.txt
#+end_example
As you could see, spaces were removed from filenames and I think that
this happens because =find-file= show spaces as escaped characters.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48659
; Package
emacs
.
(Wed, 26 May 2021 12:16:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 48659 <at> debbugs.gnu.org (full text, mbox):
> From: Rodrigo Morales <moralesrodrigo1100 <at> gmail.com>
> Date: Tue, 25 May 2021 15:40:21 -0500
>
> Now, let's toggle a =dired-toggle-read-only= and edit any name (I
> appended =test= after the =a/barbar.txt= file).
>
> Now, see what =tree= reports.
>
> #+begin_src bash
> tree -a --noreport
> #+end_src
>
> #+RESULTS:
> #+begin_example
> .
> ├── a
> │ ├── barbar.txt-test
> │ └── foofoo.txt
> └── b
> ├── barbar.txt
> └── foofoo.txt
> #+end_example
>
> As you could see, spaces were removed from filenames and I think that
> this happens because =find-file= show spaces as escaped characters.
I cannot reproduce this. Which version of Emacs is this, and on what
platform/OS? Also, does the problem happen for you in "emacs -Q"?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48659
; Package
emacs
.
(Wed, 26 May 2021 15:32:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 48659 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> I cannot reproduce this. Which version of Emacs is this, and on what
> platform/OS? Also, does the problem happen for you in "emacs -Q"?
When I reported the bug, I had only tried it in a running Emacs instance
(i.e. my configurations had been loaded).
However, I've just tried reproducing the issue in "emacs -Q" and I
can reproduce it.
I'm using GNU Emacs 27.2 in Arch Linux.
If you can't reproduce it, I can provide a WEBM, just let me know.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48659
; Package
emacs
.
(Wed, 26 May 2021 17:19:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 48659 <at> debbugs.gnu.org (full text, mbox):
> From: Rodrigo Morales <moralesrodrigo1100 <at> gmail.com>
> Cc: 48659 <at> debbugs.gnu.org
> Date: Wed, 26 May 2021 10:16:55 -0500
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > I cannot reproduce this. Which version of Emacs is this, and on what
> > platform/OS? Also, does the problem happen for you in "emacs -Q"?
>
> When I reported the bug, I had only tried it in a running Emacs instance
> (i.e. my configurations had been loaded).
>
> However, I've just tried reproducing the issue in "emacs -Q" and I
> can reproduce it.
>
> I'm using GNU Emacs 27.2 in Arch Linux.
I tried also Emacs 27.2 on Trisquel.
Can anyone else reproduce this strange problem? I don't see how we
could debug this without being able to reproduce.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48659
; Package
emacs
.
(Thu, 27 May 2021 01:48:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 48659 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
> I tried also Emacs 27.2 on Trisquel.
>
> Can anyone else reproduce this strange problem? I don't see how we
> could debug this without being able to reproduce.
Here you have two recordings that might make things clearer. Perhaps, I
wasn't clear enough in the first messaage I sent and that's why you are
not able to reproduce it, so I hope these recordings will present more
context regarding this "possible bug".
In the following GIF, you can see that spaces are removed after having
finished editing the dired buffer through "dired-toggle-read-only". This
can be seen in the output of the "watch" command that is shown in the
running shell at the right side.
[spaces-are-not-removed.gif (image/gif, inline)]
[Message part 3 (text/plain, inline)]
In the following GIF, you can see that this problem can be avoided by
removing each "\" character which are present before each space character
in filenames.
[spaces-are-removed.gif (image/gif, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48659
; Package
emacs
.
(Thu, 27 May 2021 07:05:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 48659 <at> debbugs.gnu.org (full text, mbox):
> From: Rodrigo Morales <moralesrodrigo1100 <at> gmail.com>
> Cc: 48659 <at> debbugs.gnu.org
> Date: Wed, 26 May 2021 18:55:14 -0500
>
> > Can anyone else reproduce this strange problem? I don't see how we
> > could debug this without being able to reproduce.
>
> Here you have two recordings that might make things clearer. Perhaps, I
> wasn't clear enough in the first messaage I sent and that's why you are
> not able to reproduce it, so I hope these recordings will present more
> context regarding this "possible bug".
>
> In the following GIF, you can see that spaces are removed after having
> finished editing the dired buffer through "dired-toggle-read-only". This
> can be seen in the output of the "watch" command that is shown in the
> running shell at the right side.
I believe you. I just don't see this in the GNU/Linux system where I
tried this (and also on MS-Windows, FWIW). In my testing the file
names remain intact after "C-x C-q", including the space characters.
So either the recipe is not complete, or I somehow didn't follow it
100%, or something else is at work on your system that doesn't happen
on mine. Thus my question whether someone else sees that who could
then debug the problem.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48659
; Package
emacs
.
(Thu, 27 May 2021 09:15:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 48659 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Wed, 26 May 2021 20:18:15 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
>> From: Rodrigo Morales <moralesrodrigo1100 <at> gmail.com>
>> Cc: 48659 <at> debbugs.gnu.org
>> Date: Wed, 26 May 2021 10:16:55 -0500
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> > I cannot reproduce this. Which version of Emacs is this, and on what
>> > platform/OS? Also, does the problem happen for you in "emacs -Q"?
>>
>> When I reported the bug, I had only tried it in a running Emacs instance
>> (i.e. my configurations had been loaded).
>>
>> However, I've just tried reproducing the issue in "emacs -Q" and I
>> can reproduce it.
>>
>> I'm using GNU Emacs 27.2 in Arch Linux.
Eli> I tried also Emacs 27.2 on Trisquel.
Eli> Can anyone else reproduce this strange problem? I don't see how we
Eli> could debug this without being able to reproduce.
I can reproduce this on Debian 10, with:
find --version
find (GNU findutils) 4.8.0
Something is definitely going wrong, because after exiting read-write
mode with wdired-finish-edit I end up with *Find* buffer containing
only the header lines:
/tmp/48659:
789065 4 drwxr-xr-x 4 rpluim rpluim 4096 May 27 10:57 /tmp/48659/
(but this happens even when the file names involved donʼt have spaces,
so perhaps itʼs a more generic issue).
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48659
; Package
emacs
.
(Thu, 27 May 2021 09:36:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 48659 <at> debbugs.gnu.org (full text, mbox):
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: Rodrigo Morales <moralesrodrigo1100 <at> gmail.com>, 48659 <at> debbugs.gnu.org
> Date: Thu, 27 May 2021 11:14:50 +0200
>
> Eli> Can anyone else reproduce this strange problem? I don't see how we
> Eli> could debug this without being able to reproduce.
>
> I can reproduce this on Debian 10, with:
>
> find --version
> find (GNU findutils) 4.8.0
>
> Something is definitely going wrong, because after exiting read-write
> mode with wdired-finish-edit I end up with *Find* buffer containing
> only the header lines:
>
> /tmp/48659:
> 789065 4 drwxr-xr-x 4 rpluim rpluim 4096 May 27 10:57 /tmp/48659/
>
> (but this happens even when the file names involved donʼt have spaces,
> so perhaps itʼs a more generic issue).
Can you tell which code renames the files?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48659
; Package
emacs
.
(Thu, 27 May 2021 13:52:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 48659 <at> debbugs.gnu.org (full text, mbox):
Robert Pluim <rpluim <at> gmail.com> writes:
> I can reproduce this on Debian 10, with:
>
> find --version
> find (GNU findutils) 4.8.0
>
> Something is definitely going wrong, because after exiting read-write
> mode with wdired-finish-edit I end up with *Find* buffer containing
> only the header lines:
>
> /tmp/48659:
> 789065 4 drwxr-xr-x 4 rpluim rpluim 4096 May 27 10:57 /tmp/48659/
>
> (but this happens even when the file names involved donʼt have spaces,
> so perhaps itʼs a more generic issue).
I think it's a different issue. AFAIR reverting a find-dired buffer
after making changes with wdired never worked correctly, the buffer
contents never reflected the changes correctly, at least in the last
years.
But nevertheless I use this feature combination myself regularly, and I
never saw wdired performing unintended operations.
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48659
; Package
emacs
.
(Thu, 27 May 2021 14:02:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 48659 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> I cannot reproduce this. Which version of Emacs is this, and on what
> platform/OS? Also, does the problem happen for you in "emacs -Q"?
I can reproduce the issue with my Emacs master built as described by the
OP using emacs -Q.
For me only file names that were actually edited get the space char
removed (master may behave differently here because wdired had been
changed recently to avoid the initial delay in large dired buffers when
entering wdired, that may have an effect, but I don't expect it's
related otherwise).
If I have a file line
a\ b
and change it to
aa\ b
and confirm, the resulting name will be
aab
with the space removed. It's not only the buffer where the name is
printed incorrectly - the file name has indeed been changed incorrectly.
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48659
; Package
emacs
.
(Thu, 27 May 2021 14:05:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 48659 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Heerdegen <michael_heerdegen <at> web.de>
> Cc: Rodrigo Morales <moralesrodrigo1100 <at> gmail.com>, 48659 <at> debbugs.gnu.org
> Date: Thu, 27 May 2021 16:01:49 +0200
>
> For me only file names that were actually edited get the space char
> removed (master may behave differently here because wdired had been
> changed recently to avoid the initial delay in large dired buffers when
> entering wdired, that may have an effect, but I don't expect it's
> related otherwise).
So the problem is somewhere in wdired. Analysis and patches are welcome.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48659
; Package
emacs
.
(Thu, 27 May 2021 14:17:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 48659 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> So the problem is somewhere in wdired. Analysis and patches are
> welcome.
It's `wdired-get-filename' that returns the file-name with the space
chars removed, and that seems to be due to this commit:
02bf7cc463, Properly handle unquoting in wdired (bug 22938)
CC'ing the author Andreas Schwab.
Regards,
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48659
; Package
emacs
.
(Thu, 27 May 2021 14:49:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 48659 <at> debbugs.gnu.org (full text, mbox):
On Mai 27 2021, Michael Heerdegen wrote:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>> So the problem is somewhere in wdired. Analysis and patches are
>> welcome.
>
> It's `wdired-get-filename' that returns the file-name with the space
> chars removed, and that seems to be due to this commit:
>
> 02bf7cc463, Properly handle unquoting in wdired (bug 22938)
>
> CC'ing the author Andreas Schwab.
Looks like a bug in dired-get-filename.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48659
; Package
emacs
.
(Thu, 27 May 2021 15:05:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 48659 <at> debbugs.gnu.org (full text, mbox):
On Mai 27 2021, Michael Heerdegen wrote:
> 02bf7cc463, Properly handle unquoting in wdired (bug 22938)
Why do you think this commit has any influence?
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48659
; Package
emacs
.
(Thu, 27 May 2021 15:33:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 48659 <at> debbugs.gnu.org (full text, mbox):
Andreas Schwab <schwab <at> linux-m68k.org> writes:
> On Mai 27 2021, Michael Heerdegen wrote:
>
> > 02bf7cc463, Properly handle unquoting in wdired (bug 22938)
>
> Why do you think this commit has any influence?
It was a guess, and I thought I had verified that guess, but it seems my
testing was too much in a hurry and I was wrong.
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48659
; Package
emacs
.
(Thu, 27 May 2021 15:39:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 48659 <at> debbugs.gnu.org (full text, mbox):
wdired-normalize-filename doesn't handle "\\ ".
(read "\"\\ \"") => ""
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48659
; Package
emacs
.
(Thu, 27 May 2021 15:48:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 48659 <at> debbugs.gnu.org (full text, mbox):
Andreas Schwab <schwab <at> linux-m68k.org> writes:
> wdired-normalize-filename doesn't handle "\\ ".
>
> (read "\"\\ \"") => ""
Indeed:
(wdired-normalize-filename "a\\ b" 'unquotep) ==> "ab"
- that's the culprit.
But now I don't understand why `read' behaves that way.
Regards,
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48659
; Package
emacs
.
(Thu, 27 May 2021 15:57:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 48659 <at> debbugs.gnu.org (full text, mbox):
This is really the same as bug#10469.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48659
; Package
emacs
.
(Thu, 27 May 2021 15:58:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 48659 <at> debbugs.gnu.org (full text, mbox):
On Mai 27 2021, Michael Heerdegen wrote:
> But now I don't understand why `read' behaves that way.
It follows Lisp rules.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48659
; Package
emacs
.
(Thu, 27 May 2021 18:50:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 48659 <at> debbugs.gnu.org (full text, mbox):
Andreas Schwab <schwab <at> linux-m68k.org> writes:
> wdired-normalize-filename doesn't handle "\\ ".
I have two questions:
(1) Although a comment before `wdired-normalize-filename' tells that
"This code is a copy of some dired-get-filename lines.", the unquoting
stuff seems to be implemented differently than in `dired-get-filename'.
Could we reuse the code from that function? `dired-get-filename'
doesn't seem to delete the spaces from the file names.
(2) AFAICT your commit (that I had cited above) addressed the comment
from Stefan he had added to the definition of
`wdired-normalize-filename':
;; FIXME: shouldn't we check for a `b' argument or somesuch
;; before doing such unquoting? --Stef
Can we delete that comment? That check is performed now and the
function receives the result as an argument UNQUOTEP now.
Thanks,
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48659
; Package
emacs
.
(Thu, 27 May 2021 19:12:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 48659 <at> debbugs.gnu.org (full text, mbox):
See bug#10469.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48659
; Package
emacs
.
(Thu, 27 May 2021 20:39:01 GMT)
Full text and
rfc822 format available.
Message #68 received at 48659 <at> debbugs.gnu.org (full text, mbox):
Andreas Schwab <schwab <at> linux-m68k.org> writes:
> See bug#10469.
Thanks. I'm sure that report includes the answer to my question, but
I'm not so sure where.
I mean - that had been fixed, at least the reported issue - it's now
possible to visit files whose names include spaces in find-dired
buffers.
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48659
; Package
emacs
.
(Sat, 29 May 2021 06:30:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 48659 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Rodrigo Morales <moralesrodrigo1100 <at> gmail.com>
>> Cc: 48659 <at> debbugs.gnu.org
>> Date: Wed, 26 May 2021 18:55:14 -0500
>>
>> > Can anyone else reproduce this strange problem? I don't see how we
>> > could debug this without being able to reproduce.
>>
>> Here you have two recordings that might make things clearer. Perhaps, I
>> wasn't clear enough in the first messaage I sent and that's why you are
>> not able to reproduce it, so I hope these recordings will present more
>> context regarding this "possible bug".
>>
>> In the following GIF, you can see that spaces are removed after having
>> finished editing the dired buffer through "dired-toggle-read-only". This
>> can be seen in the output of the "watch" command that is shown in the
>> running shell at the right side.
>
> I believe you. I just don't see this in the GNU/Linux system where I
> tried this (and also on MS-Windows, FWIW). In my testing the file
> names remain intact after "C-x C-q", including the space characters.
>
> So either the recipe is not complete, or I somehow didn't follow it
> 100%, or something else is at work on your system that doesn't happen
> on mine. Thus my question whether someone else sees that who could
> then debug the problem.
If it is of any worth, I am using 27.1 on Win 10 and 28.0.50 compiled on
27th march on Arch Linux and I can't reproduce either. Spaces in names
seems correctly preserved on my machine.
Reply sent
to
Andreas Schwab <schwab <at> linux-m68k.org>
:
You have taken responsibility.
(Sat, 29 May 2021 13:40:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Rodrigo Morales <moralesrodrigo1100 <at> gmail.com>
:
bug acknowledged by developer.
(Sat, 29 May 2021 13:40:01 GMT)
Full text and
rfc822 format available.
Message #76 received at 48659-done <at> debbugs.gnu.org (full text, mbox):
Should be fixed now.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48659
; Package
emacs
.
(Sat, 29 May 2021 23:10:02 GMT)
Full text and
rfc822 format available.
Message #79 received at 48659 <at> debbugs.gnu.org (full text, mbox):
Andreas Schwab <schwab <at> linux-m68k.org> writes:
> Should be fixed now.
I can confirm that it's fixed on master. Thanks Andreas!
Michael.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sun, 27 Jun 2021 11:24:08 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 275 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.