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

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

[Drew Adams]

`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''

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

[Juri Linkov]

> `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)

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

[Dmitry Gutov]

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.

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

[Lars Ingebrigtsen]

Drew Adams <drew.adams@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

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

[Dmitry Gutov]

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 ?

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

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@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

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

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Dmitry Gutov <dgutov@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

bug#35352: [External] : Re: bug#35352: 26.2; Xref: (1) no activity indication, (2) no other-window opening

[Drew Adams]

> >>> 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".