GNU bug report logs -
#43569
28.0.50; Menu "Continue Tags Search" signals an error
Previous Next
Reported by: Juri Linkov <juri <at> linkov.net>
Date: Tue, 22 Sep 2020 19:33:02 UTC
Severity: normal
Found in version 28.0.50
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 43569 in the body.
You can then email your comments to 43569 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#43569; Package
emacs.
(Tue, 22 Sep 2020 19:33:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Juri Linkov <juri <at> linkov.net>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Tue, 22 Sep 2020 19:33:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
This is a new bug report spun off from bug#43308.
>> Another problem is that selecting "Continue Tags Search"
>> signals the error:
>>
>> emacs -Q
>> Select "Edit" -> "Search" -> "Continue Tags Search"
>>
>> Lisp error: (wrong-type-argument commandp fileloop-continue)
>
> I don't see that with emacs -Q, loading menu-bar+.el,
> and using that item in the Search menu (which is not
> under Edit). Dunno why. I see just this error message:
> "No operation in progress", which makes sense.
The error occurs only when fileloop.el is not yet loaded.
>> I think "Continue Tags Search" should be disabled when it has no effect.
>
> I've done that now, in menu-bar+.el. I use this, but
> perhaps someone can let me know if it's not the right,
> or best, condition to use. (I use condition-case, not
> ignore-errors, for compatibility with older Emacs.)
>
> :enable (not (condition-case nil
> (tags-loop-eval tags-loop-scan)
> (error t)))
I tried this, but it doesn't enable "Continue Tags Search"
after starting "Search Tagged Files...". And I don't know
what else could be checked.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43569; Package
emacs.
(Tue, 22 Sep 2020 20:45:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 43569 <at> debbugs.gnu.org (full text, mbox):
> >> I think "Continue Tags Search" should be disabled when it has no effect.
> >
> > I've done that now, in menu-bar+.el. I use this, but
> > perhaps someone can let me know if it's not the right,
> > or best, condition to use. (I use condition-case, not
> > ignore-errors, for compatibility with older Emacs.)
> >
> > :enable (not (condition-case nil
> > (tags-loop-eval tags-loop-scan)
> > (error t)))
>
> I tried this, but it doesn't enable "Continue Tags Search"
> after starting "Search Tagged Files...". And I don't know
> what else could be checked.
I think the xref changes broke the use of the tags code.
You can use `M-x tags-loop-continue'. I think that
:enable code should work - and it does work for Emacs < 27.
But you're right that it no longer works. Looks like the
code for the tags-search feature was changed partially,
and stuff was declared obsolete (which shouldn't have been
done, IMO).
* Xref as an alternative is one thing - OK.
* Xref as the new default is another thing - OK, but not my
preference.
* Xref stealing the same keys is yet another thing - Not OK, IMO.
* But declaring the tags functionality and code to be
obsolete is KO, IMO. Overzealous NIH'ism, I expect.
Users should have both tags and xref available, as equals.
Guess I'll have to :enable that menu item unconditionally
for Emacs 27 and later (and leave it conditional for
Emacs before the breakage):
(define-key menu-bar-search-tags-menu [tags-continue]
'(menu-item "Continue Tags Search/Replace" tags-loop-continue
:help "Continue last tags search or replace operation"
:enable (or (> emacs-major-version 26)
(not (condition-case nil
(tags-loop-eval tags-loop-scan)
(error t))))))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43569; Package
emacs.
(Sat, 26 Sep 2020 08:53:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 43569 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 22 Sep 2020 13:44:36 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
>
> > >> I think "Continue Tags Search" should be disabled when it has no effect.
> > >
> > > I've done that now, in menu-bar+.el. I use this, but
> > > perhaps someone can let me know if it's not the right,
> > > or best, condition to use. (I use condition-case, not
> > > ignore-errors, for compatibility with older Emacs.)
> > >
> > > :enable (not (condition-case nil
> > > (tags-loop-eval tags-loop-scan)
> > > (error t)))
> >
> > I tried this, but it doesn't enable "Continue Tags Search"
> > after starting "Search Tagged Files...". And I don't know
> > what else could be checked.
>
> I think the xref changes broke the use of the tags code.
> You can use `M-x tags-loop-continue'. I think that
> :enable code should work - and it does work for Emacs < 27.
I tried to fix this on the emacs-27 branch, please take a look.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43569; Package
emacs.
(Sat, 26 Sep 2020 14:54:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 43569 <at> debbugs.gnu.org (full text, mbox):
> > > > :enable (not (condition-case nil
> > > > (tags-loop-eval tags-loop-scan)
> > > > (error t)))
> > >
> > > I tried this, but it doesn't enable "Continue Tags Search"
> > > after starting "Search Tagged Files...". And I don't know
> > > what else could be checked.
> >
> > I think the xref changes broke the use of the tags code.
> > You can use `M-x tags-loop-continue'. I think that
> > :enable code should work - and it does work for Emacs < 27.
>
> I tried to fix this on the emacs-27 branch, please take a look.
Someone else will need to do that, I'm afraid.
Or if you post something here that I can use
to replace the :enable code I showed, I'll be
glad to try that and let you know what I see.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43569; Package
emacs.
(Sat, 26 Sep 2020 15:16:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 43569 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 26 Sep 2020 07:53:23 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: juri <at> linkov.net, 43569 <at> debbugs.gnu.org
>
> > I tried to fix this on the emacs-27 branch, please take a look.
>
> Someone else will need to do that, I'm afraid.
>
> Or if you post something here that I can use
> to replace the :enable code I showed, I'll be
> glad to try that and let you know what I see.
You can see the code via the Git Web interface offered by Savannah's
Emacs page. I provided a link several times in the past.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43569; Package
emacs.
(Sat, 26 Sep 2020 15:32:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 43569 <at> debbugs.gnu.org (full text, mbox):
> > > I tried to fix this on the emacs-27 branch, please take a look.
> >
> > Someone else will need to do that, I'm afraid.
> >
> > Or if you post something here that I can use
> > to replace the :enable code I showed, I'll be
> > glad to try that and let you know what I see.
>
> You can see the code via the Git Web interface offered by Savannah's
> Emacs page. I provided a link several times in the past.
If you post something here that I can use to
replace the :enable code I showed, I'll be
glad to try that and let you know what I see.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43569; Package
emacs.
(Sat, 26 Sep 2020 15:40:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 43569 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 26 Sep 2020 08:31:19 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: juri <at> linkov.net, 43569 <at> debbugs.gnu.org
>
> > You can see the code via the Git Web interface offered by Savannah's
> > Emacs page. I provided a link several times in the past.
>
> If you post something here that I can use to
> replace the :enable code I showed, I'll be
> glad to try that and let you know what I see.
Sigh... As mentioned several times before, please go to
https://git.savannah.gnu.org/cgit/emacs.git
Click on "emacs-27", find my change from a few hours ago, click on its
line, and you will see the diffs.
(Can I convince you to bookmark that page, and use it henceforth when
you want to see some change installed in the repository?)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43569; Package
emacs.
(Sat, 26 Sep 2020 15:46:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 43569 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Sigh... As mentioned several times before, please go to
>
> https://git.savannah.gnu.org/cgit/emacs.git
>
> Click on "emacs-27", find my change from a few hours ago, click on its
> line, and you will see the diffs.
Good advice, but this reminds me of something that occurred to me some
time ago: Perhaps it would be nice if the script that sends out diff
emails also looked for text in the commit message that says "bug#4242"
and then Cc's 4242 <at> debbugs.gnu.org?
It would be especially useful when doing bug triage on reopened bug
reports, where you could see what the patch applied was without going on
an archaeological expedition into git log, but also generally more
friendly towards bug reporters, who could then see the patch immediately
themselves.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43569; Package
emacs.
(Sat, 26 Sep 2020 15:56:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 43569 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Drew Adams <drew.adams <at> oracle.com>, 43569 <at> debbugs.gnu.org,
> juri <at> linkov.net
> Date: Sat, 26 Sep 2020 17:45:21 +0200
>
> Good advice, but this reminds me of something that occurred to me some
> time ago: Perhaps it would be nice if the script that sends out diff
> emails also looked for text in the commit message that says "bug#4242"
> and then Cc's 4242 <at> debbugs.gnu.org?
I don't think I want to get patches in my mailbox twice. There's
emacs-diffs for that purpose.
> It would be especially useful when doing bug triage on reopened bug
> reports, where you could see what the patch applied was without going on
> an archaeological expedition into git log
But that's just one Git command away...
> but also generally more friendly towards bug reporters, who could
> then see the patch immediately themselves.
Only if they are subscribed to the bug list, no?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43569; Package
emacs.
(Sat, 26 Sep 2020 16:15:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 43569 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> but also generally more friendly towards bug reporters, who could
>> then see the patch immediately themselves.
>
> Only if they are subscribed to the bug list, no?
I thought the bug reporter got a copy of all mail to the
@debbugs.gnu.org address? Hm. But... come to think of it, they don't
do, they?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43569; Package
emacs.
(Sat, 26 Sep 2020 16:28:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 43569 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: drew.adams <at> oracle.com, 43569 <at> debbugs.gnu.org, juri <at> linkov.net
> Date: Sat, 26 Sep 2020 18:13:52 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> but also generally more friendly towards bug reporters, who could
> >> then see the patch immediately themselves.
> >
> > Only if they are subscribed to the bug list, no?
>
> I thought the bug reporter got a copy of all mail to the
> @debbugs.gnu.org address? Hm. But... come to think of it, they don't
> do, they?
Not unless there's some magic on debbugs. They get the message which
closes a bug, but I don't think they automatically get other messages,
unless they are CC'ed.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43569; Package
emacs.
(Sat, 26 Sep 2020 16:32:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 43569 <at> debbugs.gnu.org (full text, mbox):
> > > You can see the code via the Git Web interface offered by Savannah's
> > > Emacs page. I provided a link several times in the past.
> >
> > If you post something here that I can use to
> > replace the :enable code I showed, I'll be
> > glad to try that and let you know what I see.
>
> Sigh... As mentioned several times before, please go to...
> Click on "emacs-27", find my change from a few hours ago, click on its
> line, and you will see the diffs.
> (Can I convince you to bookmark that page, and use it henceforth when
> you want to see some change installed in the repository?)
I think we're miscommunicating. I didn't ask
to see your patch (diff).
I said that if you post here code I can use
to replace the :enable code I showed then I'll
be glad to help out by trying it and letting
you know what I see. If you don't want to do
that, fine.
And thanks for patching, assuming the result
takes care of the problem discussed. In that
case, when Emacs releases again (27.2?), with
the patch applied, Emacs will no longer present
the reported regression - the same :enable
will work for all Emacs releases (except 27.1).
In that case, the :enable condition will become:
(or (version= "27.1" emacs-version) ; bug #43569
(not (condition-case nil
(tags-loop-eval tags-loop-scan)
(error t))))
so that the menu item is still enabled
unconditionally for the (presumably still)
broken 27.1.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43569; Package
emacs.
(Sat, 26 Sep 2020 16:40:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 43569 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 26 Sep 2020 09:31:43 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: juri <at> linkov.net, 43569 <at> debbugs.gnu.org
>
> > Sigh... As mentioned several times before, please go to...
> > Click on "emacs-27", find my change from a few hours ago, click on its
> > line, and you will see the diffs.
> > (Can I convince you to bookmark that page, and use it henceforth when
> > you want to see some change installed in the repository?)
>
> I think we're miscommunicating. I didn't ask
> to see your patch (diff).
>
> I said that if you post here code I can use
> to replace the :enable code I showed then I'll
> be glad to help out by trying it and letting
> you know what I see. If you don't want to do
> that, fine.
The patch shows the code, doesn't it? So why do you insist on seeing
the code and not the change?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43569; Package
emacs.
(Sat, 26 Sep 2020 18:59:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 43569 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Lars Ingebrigtsen <larsi <at> gnus.org>
>> Cc: Drew Adams <drew.adams <at> oracle.com>, 43569 <at> debbugs.gnu.org,
>> juri <at> linkov.net
>> Date: Sat, 26 Sep 2020 17:45:21 +0200
>>
>> Good advice, but this reminds me of something that occurred to me some
>> time ago: Perhaps it would be nice if the script that sends out diff
>> emails also looked for text in the commit message that says "bug#4242"
>> and then Cc's 4242 <at> debbugs.gnu.org?
>
> I don't think I want to get patches in my mailbox twice. There's
> emacs-diffs for that purpose.
Maybe 4242-quiet <at> debbugs.gnu.org?
Quoth <https://debbugs.gnu.org/Developer.html>:
> If you wish to send a followup message which is not appropriate for
> any mailing list you can do so by sending it to
> nnn-quiet <at> debbugs.gnu.org or nnn-maintonly <at> debbugs.gnu.org. Mail to
> nnn-quiet <at> debbugs.gnu.org is filed in the bug Tracking System but is
> not delivered to any individuals or mailing lists. Mail to
> nnn-maintonly <at> debbugs.gnu.org is filed in the bug Tracking System and
> is delivered only to the maintainer of the package in question.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43569; Package
emacs.
(Sat, 26 Sep 2020 19:11:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 43569 <at> debbugs.gnu.org (full text, mbox):
> From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 43569 <at> debbugs.gnu.org,
> juri <at> linkov.net
> Date: Sat, 26 Sep 2020 20:58:38 +0200
>
> > I don't think I want to get patches in my mailbox twice. There's
> > emacs-diffs for that purpose.
>
> Maybe 4242-quiet <at> debbugs.gnu.org?
>
> Quoth <https://debbugs.gnu.org/Developer.html>:
>
> > If you wish to send a followup message which is not appropriate for
> > any mailing list you can do so by sending it to
> > nnn-quiet <at> debbugs.gnu.org or nnn-maintonly <at> debbugs.gnu.org. Mail to
> > nnn-quiet <at> debbugs.gnu.org is filed in the bug Tracking System but is
> > not delivered to any individuals or mailing lists. Mail to
> > nnn-maintonly <at> debbugs.gnu.org is filed in the bug Tracking System and
> > is delivered only to the maintainer of the package in question.
That sounds like the direct opposite of what is being saiught here,
doesn't it?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43569; Package
emacs.
(Sat, 26 Sep 2020 19:33:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 43569 <at> debbugs.gnu.org (full text, mbox):
> > I said that if you post here code I can use
> > to replace the :enable code I showed then I'll
> > be glad to help out by trying it and letting
> > you know what I see. If you don't want to do
> > that, fine.
>
> The patch shows the code, doesn't it? So why do you insist on seeing
> the code and not the change?
I didn't insist on anything. If you want me to help
by trying some alternative :enable code I'm willing
to do that, if you show that :enable code.
If not, that's OK by me. I'll go with this as a guess:
(or (version= "27.1" emacs-version) ; bug #43569
(not (condition-case nil
(tags-loop-eval tags-loop-scan)
(error t))))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43569; Package
emacs.
(Sat, 26 Sep 2020 19:36:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 43569 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 26 Sep 2020 12:32:42 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: juri <at> linkov.net, 43569 <at> debbugs.gnu.org
>
> If not, that's OK by me. I'll go with this as a guess:
>
> (or (version= "27.1" emacs-version) ; bug #43569
> (not (condition-case nil
> (tags-loop-eval tags-loop-scan)
> (error t))))
That's not what I've done.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43569; Package
emacs.
(Sat, 26 Sep 2020 21:41:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 43569 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> > If you wish to send a followup message which is not appropriate for
>> > any mailing list you can do so by sending it to
>> > nnn-quiet <at> debbugs.gnu.org or nnn-maintonly <at> debbugs.gnu.org. Mail to
>> > nnn-quiet <at> debbugs.gnu.org is filed in the bug Tracking System but is
>> > not delivered to any individuals or mailing lists. Mail to
>> > nnn-maintonly <at> debbugs.gnu.org is filed in the bug Tracking System and
>> > is delivered only to the maintainer of the package in question.
>
> That sounds like the direct opposite of what is being saiught here,
> doesn't it?
It doesn't help with sending the patch to the bug reporter, but it does
fix the problem of stashing a copy of the patch in the bug tracker (and
not annoying anybody when doing so), though.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43569; Package
emacs.
(Sun, 27 Sep 2020 01:20:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 43569 <at> debbugs.gnu.org (full text, mbox):
> That's not what I've done.
OK, I've looked at your patch; thx. And I've updated
my code. For Emacs < 27, I've found that there's no
good condition for :enable. I was mistaken thinking
that (tags-loop-eval tags-loop-scan) could be used.
___
FWIW:
I call the menu item for [tags-repl-continue]
"Continue Search/Replace", with :help "Continue last
tags search or replace operation".
It's incorrect to say that it continues the last tags
replace operation. It continues the last tags search
or replace operation. If the last tags operation was
`tags-search' and not `tags-query-replace', then it
continues the last search, not the last replace.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43569; Package
emacs.
(Sun, 27 Sep 2020 06:24:01 GMT)
Full text and
rfc822 format available.
Message #62 received at 43569 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 26 Sep 2020 18:17:26 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: juri <at> linkov.net, 43569 <at> debbugs.gnu.org
>
> I call the menu item for [tags-repl-continue]
> "Continue Search/Replace", with :help "Continue last
> tags search or replace operation".
>
> It's incorrect to say that it continues the last tags
> replace operation. It continues the last tags search
> or replace operation. If the last tags operation was
> `tags-search' and not `tags-query-replace', then it
> continues the last search, not the last replace.
That is factually correct, but I think the current menus are less
confusing to newbies than your proposal.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43569; Package
emacs.
(Sun, 27 Sep 2020 10:23:01 GMT)
Full text and
rfc822 format available.
Message #65 received at 43569 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> > If you wish to send a followup message which is not appropriate for
>>> > any mailing list you can do so by sending it to
>>> > nnn-quiet <at> debbugs.gnu.org or nnn-maintonly <at> debbugs.gnu.org. Mail to
>>> > nnn-quiet <at> debbugs.gnu.org is filed in the bug Tracking System but is
>>> > not delivered to any individuals or mailing lists. Mail to
>>> > nnn-maintonly <at> debbugs.gnu.org is filed in the bug Tracking System and
>>> > is delivered only to the maintainer of the package in question.
>>
>> That sounds like the direct opposite of what is being saiught here,
>> doesn't it?
>
> It doesn't help with sending the patch to the bug reporter, but it does
> fix the problem of stashing a copy of the patch in the bug tracker (and
> not annoying anybody when doing so), though.
Yes, that's the issue I was thinking about (sorry for not being explicit
enough, I counted on my selective quoting to do the work for me).
FWIW this feature (having the BTS record what patches were applied in
the context of a specific report) is a thing other forges do.
I can't speak for the maintainers of projects hosted on these forges,
but I can imagine it being handy: sure, finding all commits referencing
a bug ID is "just one Git command away", but that can mean a couple of
seconds twiddling one's thumbs while the disk spins; having that
information readily displayed in the thread sounds like a timesaver.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43569; Package
emacs.
(Sun, 27 Sep 2020 12:18:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 43569 <at> debbugs.gnu.org (full text, mbox):
Kévin Le Gouguec <kevin.legouguec <at> gmail.com> writes:
> I can't speak for the maintainers of projects hosted on these forges,
> but I can imagine it being handy: sure, finding all commits referencing
> a bug ID is "just one Git command away", but that can mean a couple of
> seconds twiddling one's thumbs while the disk spins; having that
> information readily displayed in the thread sounds like a timesaver.
It also helps the people who are looking at the web interface -- the
patch that resolves the bug report would be there, which I often find
helpful when looking at problems in other systems.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43569; Package
emacs.
(Sun, 27 Sep 2020 13:01:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 43569 <at> debbugs.gnu.org (full text, mbox):
On 27.09.2020 15:17, Lars Ingebrigtsen wrote:
> It also helps the people who are looking at the web interface -- the
> patch that resolves the bug report would be there, which I often find
> helpful when looking at problems in other systems.
It could also be an HTTP URL instead of the patch itself, if we wanted
to avoid duplication.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43569; Package
emacs.
(Sun, 27 Sep 2020 13:04:01 GMT)
Full text and
rfc822 format available.
Message #74 received at 43569 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov <dgutov <at> yandex.ru> writes:
> On 27.09.2020 15:17, Lars Ingebrigtsen wrote:
>> It also helps the people who are looking at the web interface -- the
>> patch that resolves the bug report would be there, which I often find
>> helpful when looking at problems in other systems.
>
> It could also be an HTTP URL instead of the patch itself, if we wanted
> to avoid duplication.
I'd prefer the patch itself -- systems come and go, and URLs don't last.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43569; Package
emacs.
(Sun, 27 Sep 2020 19:14:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 43569 <at> debbugs.gnu.org (full text, mbox):
> > I call the menu item for [tags-repl-continue]
> > "Continue Search/Replace", with :help "Continue last
> > tags search or replace operation".
> >
> > It's incorrect to say that it continues the last tags
> > replace operation. It continues the last tags search
> > or replace operation. If the last tags operation was
> > `tags-search' and not `tags-query-replace', then it
> > continues the last search, not the last replace.
>
> That is factually correct, but I think the current menus
> confusing to newbies than your proposal are less.
I won't argue about it, but I think that as soon as a
user tries tags-searching and then tries to go back to
continue a tags query-replace, s?he will be mightily
surprised. Likewise, trying to go back to continue a
tags search after having last done a tags query-replace.
That's exactly how I discovered this.
If we had separate "continue" commands, at least from
the menus, then this wouldn't be a gotcha.
I do agree that simply having a menu item or help echo
that refers to continuing the last search or replace is
hardly the best remedy. It would be good, I think, for
some remedy to be applied.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43569; Package
emacs.
(Mon, 28 Sep 2020 06:01:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 43569 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 27 Sep 2020 12:10:50 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: juri <at> linkov.net, 43569 <at> debbugs.gnu.org
>
> > > I call the menu item for [tags-repl-continue]
> > > "Continue Search/Replace", with :help "Continue last
> > > tags search or replace operation".
> > >
> > > It's incorrect to say that it continues the last tags
> > > replace operation. It continues the last tags search
> > > or replace operation. If the last tags operation was
> > > `tags-search' and not `tags-query-replace', then it
> > > continues the last search, not the last replace.
> >
> > That is factually correct, but I think the current menus
> > confusing to newbies than your proposal are less.
>
> I won't argue about it, but I think that as soon as a
> user tries tags-searching and then tries to go back to
> continue a tags query-replace, s?he will be mightily
> surprised.
Like I said: factually correct, but there's no reason for the user to
do something like that, except by accident.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43569; Package
emacs.
(Mon, 28 Sep 2020 15:52:01 GMT)
Full text and
rfc822 format available.
Message #83 received at 43569 <at> debbugs.gnu.org (full text, mbox):
> > > > I call the menu item for [tags-repl-continue]
> > > > "Continue Search/Replace", with :help "Continue last
> > > > tags search or replace operation".
> > > >
> > > > It's incorrect to say that it continues the last tags
> > > > replace operation. It continues the last tags search
> > > > or replace operation. If the last tags operation was
> > > > `tags-search' and not `tags-query-replace', then it
> > > > continues the last search, not the last replace.
> > >
> > > That is factually correct, but I think the current menus
> > > confusing to newbies than your proposal are less.
> >
> > I won't argue about it, but I think that as soon as a
> > user tries tags-searching and then tries to go back to
> > continue a tags query-replace, s?he will be mightily
> > surprised.
>
> Like I said: factually correct, but there's no reason
> for the user to do something like that, except by accident.
FWIW (so please don't claim I'm "insisting" or arguing) -
Like I said:
That's exactly how I discovered this.
I didn't do it by accident. Someone can easily do
both tags searching and tags query-replacing, moving
from one to the other.
Clearest (at least for menu purposes) would for there
to be two separate continue commands - continue last
search and continue last query-replace.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43569; Package
emacs.
(Mon, 25 Apr 2022 15:10:03 GMT)
Full text and
rfc822 format available.
Message #86 received at 43569 <at> debbugs.gnu.org (full text, mbox):
Skimming this thread, there doesn't seem to be anything further to do
here, and I'm closing this bug report.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug closed, send any further explanations to
43569 <at> debbugs.gnu.org and Juri Linkov <juri <at> linkov.net>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Mon, 25 Apr 2022 15:10:03 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Tue, 24 May 2022 11:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 336 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.