GNU bug report logs - #35352
26.2; Xref: (1) no activity indication, (2) no other-window opening

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 35352 in the body.
You can then email your comments to 35352 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.2; Xref: (1) no activity indication, (2) no other-window opening
Date: Sat, 20 Apr 2019 20:05:21 -0700 (PDT)

`dired-do-find-regexp':

1. After entering the regexp there is no feedback telling you that Emacs
   has started searching.  Nada.  If you happen to have a search that
   takes more than a few seconds you can really begin to wonder what, if
   anything, is going on.  Emacs convention is to say SOMETHING -
   typically something like "Searching..." - and then to follow that up
   with an indication when the activity is done -
   e.g. "Searching...done".

2. There doesn't seem to be any key binding that opens a search hit in a
   new window or frame.  I don't want Emacs to replace the source Dired
   buffer in its window.

   In my case buffer `*xref*' is in its own dedicated window, in its own
   frame (the buffer is a special-display buffer, based on its name.
   Perhaps such a use case wasn't tested?  Typically Emacs provides
   _some_ key to open things in another window or frame.  Sure, users
   can fiddle to create their own bindings, but I'm surprised the
   default behavior, let alone the only provided behavior, would replace
   the Dired buffer in its window.  Hard to believe anyone would want
   that behavior, but I suppose someone must.

In GNU Emacs 26.2 (build 1, x86_64-w64-mingw32)
 of 2019-04-13
Repository revision: fd1b34bfba8f3f6298df47c8e10b61530426f749
Windowing system distributor `Microsoft Corp.', version 10.0.17134
Configured using:
 `configure --without-dbus --host=x86_64-w64-mingw32
 --without-compress-install 'CFLAGS=-O2 -static -g3''

Message #8 received at 35352 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 35352 <at> debbugs.gnu.org
Subject: Re: bug#35352: 26.2;
 Xref: (1) no activity indication, (2) no other-window opening
Date: Tue, 28 May 2019 23:43:29 +0300

> `dired-do-find-regexp':
>
> 1. After entering the regexp there is no feedback telling you that Emacs
>    has started searching.  Nada.  If you happen to have a search that
>    takes more than a few seconds you can really begin to wonder what, if
>    anything, is going on.  Emacs convention is to say SOMETHING -
>    typically something like "Searching..." - and then to follow that up
>    with an indication when the activity is done -
>    e.g. "Searching...done".
>
> 2. There doesn't seem to be any key binding that opens a search hit in a
>    new window or frame.  I don't want Emacs to replace the source Dired
>    buffer in its window.

I tried to reproduce these problems, but after running in `emacs -Q'
`dired-do-find-regexp' failed with this error:

Debugger entered--Lisp error: (void-function xref--show-xrefs)
  xref--show-xrefs(#f(compiled-function () #<bytecode 0x15789105a071>) nil)
  dired-do-find-regexp("dired-do-find-regexp")
  funcall-interactively(dired-do-find-regexp "dired-do-find-regexp")
  call-interactively(dired-do-find-regexp record nil)
  command-execute(dired-do-find-regexp record)
  execute-extended-command(nil "dired-do-find-regexp" nil)
  funcall-interactively(execute-extended-command nil "dired-do-find-regexp" nil)
  call-interactively(execute-extended-command nil nil)
  command-execute(execute-extended-command)

Message #11 received at 35352 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Juri Linkov <juri <at> linkov.net>, Drew Adams <drew.adams <at> oracle.com>
Cc: 35352 <at> debbugs.gnu.org
Subject: Re: bug#35352: 26.2; Xref: (1) no activity indication, (2) no
 other-window opening
Date: Thu, 30 May 2019 20:29:41 +0300

On 28.05.2019 23:43, Juri Linkov wrote:

> I tried to reproduce these problems, but after running in `emacs -Q'
> `dired-do-find-regexp' failed with this error:
> 
> Debugger entered--Lisp error: (void-function xref--show-xrefs)
>    xref--show-xrefs(#f(compiled-function () #<bytecode 0x15789105a071>) nil)

Ouch. Should be fixed now, thank you.

Message #14 received at 35352 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 35352 <at> debbugs.gnu.org
Subject: Re: bug#35352: 26.2; Xref: (1) no activity indication, (2) no
 other-window opening
Date: Tue, 22 Jun 2021 17:15:57 +0200

Drew Adams <drew.adams <at> oracle.com> writes:

> `dired-do-find-regexp':
>
> 1. After entering the regexp there is no feedback telling you that Emacs
>    has started searching.  Nada.  If you happen to have a search that
>    takes more than a few seconds you can really begin to wonder what, if
>    anything, is going on.  Emacs convention is to say SOMETHING -
>    typically something like "Searching..." - and then to follow that up
>    with an indication when the activity is done -
>    e.g. "Searching...done".

Makes sense.  I've now made this change in Emacs 28.

> 2. There doesn't seem to be any key binding that opens a search hit in a
>    new window or frame.  I don't want Emacs to replace the source Dired
>    buffer in its window.
>
>    In my case buffer `*xref*' is in its own dedicated window, in its own
>    frame (the buffer is a special-display buffer, based on its name.
>    Perhaps such a use case wasn't tested?  Typically Emacs provides
>    _some_ key to open things in another window or frame.

Well, it depends on the mode.  For instance, I don't think `M-x grep'
has any command to open in a new window/frame, and I don't think we want
to add all those commands to all these modes because users want so many
different combinations here that it's best left to the general
buffer/window selection machinery.

But...  on the other hand, perhaps a standard set of commands (and
keystrokes) for these "follow this 'link'" modes would be nice?  Anybody
got an opinion here?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #19 received at 35352 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Drew Adams <drew.adams <at> oracle.com>
Cc: 35352 <at> debbugs.gnu.org
Subject: Re: bug#35352: 26.2; Xref: (1) no activity indication, (2) no
 other-window opening
Date: Tue, 22 Jun 2021 18:53:39 +0300

On 22.06.2021 18:15, Lars Ingebrigtsen wrote:
> But...  on the other hand, perhaps a standard set of commands (and
> keystrokes) for these "follow this 'link'" modes would be nice?  Anybody
> got an opinion here?

https://elpa.gnu.org/packages/other-frame-window.html ?

Message #22 received at 35352 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 35352 <at> debbugs.gnu.org, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#35352: 26.2; Xref: (1) no activity indication, (2) no
 other-window opening
Date: Wed, 23 Jun 2021 14:57:39 +0200

Dmitry Gutov <dgutov <at> yandex.ru> writes:

> On 22.06.2021 18:15, Lars Ingebrigtsen wrote:
>> But...  on the other hand, perhaps a standard set of commands (and
>> keystrokes) for these "follow this 'link'" modes would be nice?  Anybody
>> got an opinion here?
>
> https://elpa.gnu.org/packages/other-frame-window.html ?

Ah, nice.  There's still the question of whether Emacs should have
(something like) this built-in, but I'm leaning towards "no"...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #25 received at 35352 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 35352 <at> debbugs.gnu.org, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#35352: 26.2; Xref: (1) no activity indication, (2) no
 other-window opening
Date: Thu, 22 Jul 2021 16:21:32 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Dmitry Gutov <dgutov <at> yandex.ru> writes:
>
>> On 22.06.2021 18:15, Lars Ingebrigtsen wrote:
>>> But...  on the other hand, perhaps a standard set of commands (and
>>> keystrokes) for these "follow this 'link'" modes would be nice?  Anybody
>>> got an opinion here?
>>
>> https://elpa.gnu.org/packages/other-frame-window.html ?
>
> Ah, nice.  There's still the question of whether Emacs should have
> (something like) this built-in, but I'm leaning towards "no"...

And nobody had an opinion here in a month, so I'm closing this bug
report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #30 received at 35352 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Dmitry Gutov <dgutov <at> yandex.ru>
Cc: "35352 <at> debbugs.gnu.org" <35352 <at> debbugs.gnu.org>
Subject: RE: [External] : Re: bug#35352: 26.2; Xref: (1) no activity
 indication, (2) no other-window opening
Date: Thu, 22 Jul 2021 15:13:39 +0000

> >>> But...  on the other hand, perhaps a standard set of commands (and
> >>> keystrokes) for these "follow this 'link'" modes would be nice?  Anybody
> >>> got an opinion here?
> >>
> >> https://urldefense.com/v3/__https://elpa.gnu.org/packages/other-frame-
> window.html__;!!ACWV5N9M2RV99hQ!ZlCeUkIklYNOveRY6ugZ4ggHQ5GxNlrOzfhQlkK0u4FNb
> Goamg7I5Np4twlAb__9$  ?
> >
> > Ah, nice.  There's still the question of whether Emacs should have
> > (something like) this built-in, but I'm leaning towards "no"...

Whether nice or not, that's irrelevant to this bug
report, IMO.  Sure, it talks about using another
window - that's all.

> And nobody had an opinion here in a month, so 
> I'm closing this bug report.

Opinion about `other-frame-window'?  Not related.

Was the case of a dedicated window for the *xref*
buffer tested?  That's a case I reported about.

> Well, it depends on the mode.  For instance, I don't
> think `M-x grep' has any command to open in a new
> window/frame, and I don't think we want to add all
> those commands to all these modes because users want
> so many different combinations here that it's best
> left to the general buffer/window selection machinery.

You mentioned *grep* as being the _same_ as *xref*.
I wish *xref* _did_ behave like *grep.  The problem
is that it doesn't.

As I said in my report, I use dedicated windows for
buffers whose names start and end with `*'.  E.g.,

 (setq special-display-regexps '("[ ]?[*][^*]+[*]"))

*xref* should be the same case as *grep*, but it's
not.  The bug was reported for *xref*.

With grep, `RET' or `mouse-2' on a search hit invokes
`compile-goto-error', which does `next-error-internal',
which DTRT - it opens the search-hit buffer in a
window other than that of the Dired buffer.

That's the point of the bug report - a request to make
*xref* behave properly, like *grep* does, when choosing
a search hit.

If this was fixed, great; thanks.  If not, then I guess
this is just another "won't fix".

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.