tags-loop-continue

tags-loop-continue

[Eli Zaretskii]

It looks like we cannot obsolete this command, because tags-search and
tags-query-replace, which need it, don't have any xref equivalents and
are not obsolete.

Re: tags-loop-continue

[Ingo Lohmar]

On Sat, Jan 09 2016 21:36 (+0200), Eli Zaretskii wrote:

> It looks like we cannot obsolete this command, because tags-search and
> tags-query-replace, which need it, don't have any xref equivalents and
> are not obsolete.

Yes, and they are definitely not obsolete as long as they are very
useful in dired, via dired-do-query-replace-regexp and dired-do-search.

Re: tags-loop-continue

[Dmitry Gutov]

On 01/09/2016 10:36 PM, Eli Zaretskii wrote:
> It looks like we cannot obsolete this command, because tags-search and
> tags-query-replace, which need it, don't have any xref equivalents and
> are not obsolete.

I suppose so.

Re: tags-loop-continue

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 9 Jan 2016 23:22:40 +0300
> 
> On 01/09/2016 10:36 PM, Eli Zaretskii wrote:
> > It looks like we cannot obsolete this command, because tags-search and
> > tags-query-replace, which need it, don't have any xref equivalents and
> > are not obsolete.
> 
> I suppose so.

Of course, the real bummer would be that it no longer has a key
binding, and its previous one is taken.  Maybe we should rebind
xref-pop-marker-stack back to 'M-*' and leave tags-loop-continue on
'M-,', WDYT?

Re: tags-loop-continue

[Dmitry Gutov]

On 01/09/2016 11:42 PM, Eli Zaretskii wrote:

> Of course, the real bummer would be that it no longer has a key
> binding, and its previous one is taken.

If it's only supposed to be used in tags-query-replace and 
tags-query-replace now, why does it need a binding? It only seems to be 
used in a non-interactive way.

> Maybe we should rebind
> xref-pop-marker-stack back to 'M-*' and leave tags-loop-continue on
> 'M-,', WDYT?

I disagree. As per above, its interactive form is basically obsolete, 
isn't it?

Re: tags-loop-continue

[Dmitry Gutov]

On 01/09/2016 11:49 PM, Dmitry Gutov wrote:

> If it's only supposed to be used in tags-query-replace and
> tags-query-replace now, why does it need a binding? It only seems to be
> used in a non-interactive way.

Sorry, "and tags-search".

>> Maybe we should rebind
>> xref-pop-marker-stack back to 'M-*' and leave tags-loop-continue on
>> 'M-,', WDYT?
>
> I disagree. As per above, its interactive form is basically obsolete,
> isn't it?

We can avoid this conundrum by defining a new, private function (say, 
tags--loop-continue), which will be non-interactive, and to which the 
now-obsolete tags-loop-continue will delegate to. And use it in 
tags-query-replace and tags-search.

WDYT?

Re: tags-loop-continue

[Dmitry Gutov]

On 01/09/2016 11:49 PM, Dmitry Gutov wrote:

> If it's only supposed to be used in tags-query-replace and
> tags-query-replace now, why does it need a binding? It only seems to be
> used in a non-interactive way.

Or if we *are* supposed to invoke tags-loop-continue interactively when 
using these commands, can't we make sure that it's only bound *then*?

Like, set that binding in certain major modes' key maps? Or, if that's 
not an option, temporarily enter a minor mode that would set that binding?

IIUC, tags-query-replace *does* use certain keymaps for its whole duration.

And regarding tags-search, it shouldn't be too hard to implement an 
alternative that would use an xref buffer for output. If you like that 
idea, what shall we call it?

Re: tags-loop-continue

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 10 Jan 2016 00:19:26 +0300
> 
> On 01/09/2016 11:49 PM, Dmitry Gutov wrote:
> 
> > If it's only supposed to be used in tags-query-replace and
> > tags-query-replace now, why does it need a binding? It only seems to be
> > used in a non-interactive way.
> 
> Or if we *are* supposed to invoke tags-loop-continue interactively when 
> using these commands, can't we make sure that it's only bound *then*?
> 
> Like, set that binding in certain major modes' key maps? Or, if that's 
> not an option, temporarily enter a minor mode that would set that binding?
> 
> IIUC, tags-query-replace *does* use certain keymaps for its whole duration.
> 
> And regarding tags-search, it shouldn't be too hard to implement an 
> alternative that would use an xref buffer for output. If you like that 
> idea, what shall we call it?

tags-loop-continue is also used by Dired, see 'A' and 'Q' in
"Operating on Files".

Look at this from the user's POV: these two commands, as well as
tags-search and tags-query-replace, are still available, so users will
expect to be able to continue them as they did before.  How can we
explain to them that the keybinding for that command changed?

Other than that, what technical solution is used to keep the command
and its keybinding available is unimportant, I think.

Re: tags-loop-continue

[Dmitry Gutov]

On 01/10/2016 06:45 AM, Eli Zaretskii wrote:

> tags-loop-continue is also used by Dired, see 'A' and 'Q' in
> "Operating on Files".

I'm fairly sure these commands are more obscure, and used considerably 
less frequently than find-tag, or xref-find-definitions that's poised to 
replace it. C-, is too nice a key binding to spend on them.

If we want to retain some global binding for tags-loop-continue, let's 
move it to C-*.

> Look at this from the user's POV: these two commands, as well as
> tags-search and tags-query-replace, are still available, so users will
> expect to be able to continue them as they did before.  How can we
> explain to them that the keybinding for that command changed?

In the NEWS file, and in the manual?

> Other than that, what technical solution is used to keep the command
> and its keybinding available is unimportant, I think.

It doesn't seem like tags-search uses any special keymap during its 
execution.

RE: tags-loop-continue

[Drew Adams]

(Caveat: I have not followed this thread at all.)

> > tags-loop-continue is also used by Dired, see 'A' and 'Q' in
> > "Operating on Files".
> 
> I'm fairly sure these commands are more obscure, and used considerably
> less frequently than find-tag, or xref-find-definitions that's poised to
> replace it. C-, is too nice a key binding to spend on them.

What makes you "fairly sure" of that?  FWIW, my own guess
is that `A' and `Q' in Dired are heavily used.  (As they
should be.)

I would even question a judgment that `find-tag' is used
more often, let alone "considerably" so, but I don't have
anything to back up my guess about that.

And keep in mind that to use `find-tag' someone needs to
have created a TAGS file.  You need nothing to be able to
use `A' and `Q' in Dired.

Re: tags-loop-continue

[Dmitry Gutov]

On 01/10/2016 09:29 AM, Drew Adams wrote:

> What makes you "fairly sure" of that?  FWIW, my own guess
> is that `A' and `Q' in Dired are heavily used.  (As they
> should be.)

They could be used, but apparently not in conjunction with 
tags-loop-continue.

Just how much time has passed since we've given the tags-loop-continue's 
binding to xref-pop-marker-stack before this question has come up?

And we're not talking about it because a user complained. We're 
discussing it because we've been reminded of it while updating the 
documentation.

Re: tags-loop-continue

[Ingo Lohmar]

On Sun, Jan 10 2016 17:35 (+0300), Dmitry Gutov wrote:
> They could be used, but apparently not in conjunction with 
> tags-loop-continue.
>
> Just how much time has passed since we've given the tags-loop-continue's 
> binding to xref-pop-marker-stack before this question has come up?
>
> And we're not talking about it because a user complained. We're 
> discussing it because we've been reminded of it while updating the 
> documentation.

Speaking for my case, I've not noticed the change simply because I have
rebound all tags/xref keys (the default bindings never made much sense
to me).

There might be a strong overlap between a) the people who use this (very
useful but also) kind of advanced and not quite obvious feature, and the
people who rebind keys explicitly (and therefore would not notice a
default binding change).

Re: tags-loop-continue

[Eli Zaretskii]

> From: Ingo Lohmar <i.lohmar@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Sun, 10 Jan 2016 16:26:30 +0100
> 
> Speaking for my case, I've not noticed the change simply because I have
> rebound all tags/xref keys (the default bindings never made much sense
> to me).

Don't you get an "obsolete command" warning each time you use
tags-loop-continue?

Re: tags-loop-continue

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 10 Jan 2016 17:35:15 +0300
> 
> On 01/10/2016 09:29 AM, Drew Adams wrote:
> 
> > What makes you "fairly sure" of that?  FWIW, my own guess
> > is that `A' and `Q' in Dired are heavily used.  (As they
> > should be.)
> 
> They could be used, but apparently not in conjunction with 
> tags-loop-continue.

Those commands are very deficient without tags-loop-continue.  The
idea is that you iterate through many files, doing whatever you do in
each one of them.  If you cannot continue the loop, these commands are
so much less convenient as to be almost useless.

> Just how much time has passed since we've given the tags-loop-continue's 
> binding to xref-pop-marker-stack before this question has come up?

We cannot decide that commands are unimportant just because no one
yells the moment we make such changes.  These are powerful commands,
and it's quite expected that they are not used every day.  It doesn't
mean they are not used at all, or that they can be removed or ignored.

> And we're not talking about it because a user complained. We're 
> discussing it because we've been reminded of it while updating the 
> documentation.

Ahem... if the documentation update was done back when the code
changes were made, we would be having this discussion in time, instead
of doing this now.

Re: tags-loop-continue

[Dmitry Gutov]

On 01/10/2016 07:08 PM, Eli Zaretskii wrote:

> Those commands are very deficient without tags-loop-continue.  The
> idea is that you iterate through many files, doing whatever you do in
> each one of them.  If you cannot continue the loop, these commands are
> so much less convenient as to be almost useless.

Ok, I agree we should provide some access to it.

 > We cannot decide that commands are unimportant just because no one
 > yells the moment we make such changes.

Not the moment we made that change, nor in the months that have passed 
since.

> These are powerful commands,
> and it's quite expected that they are not used every day.  It doesn't
> mean they are not used at all, or that they can be removed or ignored.

A command that isn't used every day can afford to have a less convenient 
binding, or have its binding changed sometimes.

> Ahem... if the documentation update was done back when the code
> changes were made, we would be having this discussion in time, instead
> of doing this now.

That's beside the point.

The lack of user complaints so far is a strong data point.

RE: tags-loop-continue

[Drew Adams]

> > What makes you "fairly sure" of that?  FWIW, my own guess
> > is that `A' and `Q' in Dired are heavily used.  (As they
> > should be.)
> 
> They could be used, but apparently not in conjunction with
> tags-loop-continue.
> 
> Just how much time has passed since we've given the tags-loop-continue's
> binding to xref-pop-marker-stack before this question has come up?
> 
> And we're not talking about it because a user complained. We're
> discussing it because we've been reminded of it while updating the
> documentation.

That's poor reasoning, IMO.  How many users have used
`xref-pop-marker-stack'?

The absence of user complaints during a period when the
thing about which you are counting complaints is not
even present in a release is hardly something to go by.

_Zero_ time has passed since Emacs has been released
with your new feature.  _You_, as its developer, might
be zealously impatient and feel that a long time has
passed, but in fact no time has passed at all.  Your
feature has not even been released to users.

Re: tags-loop-continue

[Dmitry Gutov]

On 01/10/2016 08:53 PM, Drew Adams wrote:

> That's poor reasoning, IMO.  How many users have used
> `xref-pop-marker-stack'?

More. And in any case, xref-pop-marker-stack goes together with 
xref-find-definitions, so it only makes sense for them to use close key 
bindings.

> The absence of user complaints during a period when the
> thing about which you are counting complaints is not
> even present in a release is hardly something to go by.

Indeed, we're missing the data from the risk-averse part of the 
population, which only install the released versions.

Still, a lot of people use pre-release snapshots, and that crowd must be 
pretty diverse as well.

Re: tags-loop-continue

[Eric Abrahamsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 01/10/2016 08:53 PM, Drew Adams wrote:
>
>> That's poor reasoning, IMO.  How many users have used
>> `xref-pop-marker-stack'?
>
> More. And in any case, xref-pop-marker-stack goes together with
> xref-find-definitions, so it only makes sense for them to use close
> key bindings.
>
>> The absence of user complaints during a period when the
>> thing about which you are counting complaints is not
>> even present in a release is hardly something to go by.
>
> Indeed, we're missing the data from the risk-averse part of the
> population, which only install the released versions.
>
> Still, a lot of people use pre-release snapshots, and that crowd must
> be pretty diverse as well.

I run the development version, and have been annoyed by the breakage.
I've also been too lazy to report, in part because I'm trying to use
Helm to do more Dired things anyway.

/datapoint

Re: tags-loop-continue

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 10 Jan 2016 07:00:40 +0300
> 
>     tags-loop-continue is also used by Dired, see 'A' and 'Q' in
>     "Operating on Files".
> 
> I'm fairly sure these commands are more obscure, and used considerably less frequently than find-tag, or xref-find-definitions that's poised to replace it.

I think you've just heard from someone who evidently does use them:

  http://lists.gnu.org/archive/html/emacs-devel/2016-01/msg00627.html

> C-, is too nice a key binding to spend on them.

You mean 'M-,', I presume.

> If we want to retain some global binding for tags-loop-continue, let's move it to C-*.

I'm afraid it won't go down well with the users of those commands.
Besides, 'C-*' is not available on TTYs.

>     Look at this from the user's POV: these two commands, as well as
>     tags-search and tags-query-replace, are still available, so users will
>     expect to be able to continue them as they did before.  How can we
>     explain to them that the keybinding for that command changed?
> 
> In the NEWS file, and in the manual?

I asked "how", not "where".  This command (tags-loop-continue) existed
before and had a keybinding; it will also exist in Emacs 25.1 -- how
do we explain that it now has a different keybinding, or no keybinding
at all?  What good reasons do we give for such a backward-incompatible
change in a veteran command?

>     Other than that, what technical solution is used to keep the command
>     and its keybinding available is unimportant, I think.
> 
> It doesn't seem like tags-search uses any special keymap during its execution.

I didn't talk about tags-search, I'm talking only about
tags-loop-continue.  I think it should remain an interactive command
(so it could be easily rebound and invoked by name), and it should be
bound to 'M-,' as it was before.  We will need to find a new binding
for xref-query-replace, which is unfortunate, but I don't see a better
way forward.

Re: tags-loop-continue

[Dmitry Gutov]

On 01/10/2016 06:54 PM, Eli Zaretskii wrote:

> I think you've just heard from someone who evidently does use them:
>
>    http://lists.gnu.org/archive/html/emacs-devel/2016-01/msg00627.html

But not with default key bindings. I'd classify Ingo's message as an 
evidence that we're allowed not to care too much about the default binding.

>> C-, is too nice a key binding to spend on them.
>
> You mean 'M-,', I presume.

Yes, sorry.

>> If we want to retain some global binding for tags-loop-continue, let's move it to C-*.
>
> I'm afraid it won't go down well with the users of those commands.

None of the early adopters complained thus far.

In any case, we're changing a lot of things already. The most 
curmudgeonly users will have a lot to complain about anyway.

> Besides, 'C-*' is not available on TTYs.

And here, I meant 'M-*'. The binding formerly used by pop-tag-mark.

> I asked "how", not "where".  This command (tags-loop-continue) existed
> before and had a keybinding; it will also exist in Emacs 25.1 -- how
> do we explain that it now has a different keybinding, or no keybinding
> at all?  What good reasons do we give for such a backward-incompatible
> change in a veteran command?

The command won't change--only its bindings. Because we expect it to be 
used considerably less often from now on.

>>      Other than that, what technical solution is used to keep the command
>>      and its keybinding available is unimportant, I think.
>>
>> It doesn't seem like tags-search uses any special keymap during its execution.
>
> I didn't talk about tags-search, I'm talking only about
> tags-loop-continue.

Because tags-query-replace uses a special keymap, we can bind 
tags-loop-continue to M-, in it. _Maybe_ we can similarly use a new 
keymap during tags-search's execution.

If you think it's a good idea, I can look into it.

On the flip side, the users may get confused that M-, is bound to 
different commands in different contexts.

> I think it should remain an interactive command
> (so it could be easily rebound and invoked by name), and it should be
> bound to 'M-,' as it was before.

I will stick out like a sore thumb, being entirely useless with the xref 
interface, and only serving the more obscure use cases.

Let's not take up the handy key combination just for that.

> We will need to find a new binding
> for xref-query-replace, which is unfortunate, but I don't see a better
> way forward.

Apparently you mean xref-pop-marker-stack. See the two proposed ways 
forward described above (use M-*, or only set up the M-, binding during 
tags-search and tags-query-replace).

Re: tags-loop-continue

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 10 Jan 2016 19:14:14 +0300
> Cc: emacs-devel@gnu.org
> 
> > I didn't talk about tags-search, I'm talking only about
> > tags-loop-continue.
> 
> Because tags-query-replace uses a special keymap, we can bind 
> tags-loop-continue to M-, in it. _Maybe_ we can similarly use a new 
> keymap during tags-search's execution.
> 
> If you think it's a good idea, I can look into it.

I think it should be okay, thanks.  As long as the command is
interactive, it can always be rebound, if users so want.

> On the flip side, the users may get confused that M-, is bound to 
> different commands in different contexts.

But the current binding of M-, makes no sense while tags-search is
on-going, I think.  So it sounds like a good compromise to me.

Re: tags-loop-continue

[Dmitry Gutov]

On 01/10/2016 08:08 PM, Eli Zaretskii wrote:

>> Because tags-query-replace uses a special keymap, we can bind
>> tags-loop-continue to M-, in it. _Maybe_ we can similarly use a new
>> keymap during tags-search's execution.
>>
>> If you think it's a good idea, I can look into it.
>
> I think it should be okay, thanks.

All right, looking into it.

> As long as the command is
> interactive, it can always be rebound, if users so want.

That applies to both proposed solutions, though. And even the case where 
we end up without default binding for this command, as long as its 
un-obsoleted.

>> On the flip side, the users may get confused that M-, is bound to
>> different commands in different contexts.
>
> But the current binding of M-, makes no sense while tags-search is
> on-going, I think.  So it sounds like a good compromise to me.

I suppose. My main concern is that someone can get used to M-, being 
bound to tags-loop-continue, and then use this key combination outside 
of tags-search, to an entirely different result.

Re: tags-loop-continue

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 10 Jan 2016 21:19:27 +0300
> 
> >> On the flip side, the users may get confused that M-, is bound to
> >> different commands in different contexts.
> >
> > But the current binding of M-, makes no sense while tags-search is
> > on-going, I think.  So it sounds like a good compromise to me.
> 
> I suppose. My main concern is that someone can get used to M-, being 
> bound to tags-loop-continue, and then use this key combination outside 
> of tags-search, to an entirely different result.

Could be, but I think it's a lower probability than someone using it
as part of tags-search.  So doing this is progress, I think.

Thanks.

Re: tags-loop-continue

[Dmitry Gutov]

On 01/10/2016 08:08 PM, Eli Zaretskii wrote:

>> Because tags-query-replace uses a special keymap, we can bind
>> tags-loop-continue to M-, in it. _Maybe_ we can similarly use a new
>> keymap during tags-search's execution.
>>
>> If you think it's a good idea, I can look into it.
>
> I think it should be okay, thanks.  As long as the command is
> interactive, it can always be rebound, if users so want.

Sorry, this is a bust. The way tags-loop-continue is used, to continue 
execution after a user pressed C-g to quit tags-query-replace, makes it 
not suitable for a binding inside query-replace-map.

A lot of etags.el is written using global state of some kind, which is 
another reason I think it will be good to have a replacement for it.

So, I propose two options:

- Un-obsolete the command, but keep it without binding (now done in 
emacs-25). Since it's not used too often, no binding makes some sense, 
and users can choose their own bindings.

- Also bind it to M-*. Pro: users will have something to press right 
away. Cons: the change in binding is still confusing, and hopefully 
we'll reimplement all these workflows in a different ways soon, thus 
making tags-loop-continue binding even less necessary.

Re: tags-loop-continue

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 14 Jan 2016 03:41:01 +0300
> 
> On 01/10/2016 08:08 PM, Eli Zaretskii wrote:
> 
> >> Because tags-query-replace uses a special keymap, we can bind
> >> tags-loop-continue to M-, in it. _Maybe_ we can similarly use a new
> >> keymap during tags-search's execution.
> >>
> >> If you think it's a good idea, I can look into it.
> >
> > I think it should be okay, thanks.  As long as the command is
> > interactive, it can always be rebound, if users so want.
> 
> Sorry, this is a bust. The way tags-loop-continue is used, to continue 
> execution after a user pressed C-g to quit tags-query-replace, makes it 
> not suitable for a binding inside query-replace-map.

Too bad.  Thanks for trying.

> So, I propose two options:
> 
> - Un-obsolete the command, but keep it without binding (now done in 
> emacs-25). Since it's not used too often, no binding makes some sense, 
> and users can choose their own bindings.
> 
> - Also bind it to M-*. Pro: users will have something to press right 
> away. Cons: the change in binding is still confusing, and hopefully 
> we'll reimplement all these workflows in a different ways soon, thus 
> making tags-loop-continue binding even less necessary.

Unfortunately, I think it makes much more sense to bind
tags-loop-continue back to 'M-,', and bind xref-pop-marker-stack to
'M-*', the old binding of pop-tag-mark, which xref-pop-marker-stack
replaces.  When tags-loop-continue is no longer needed, we could use
its binding for xref-pop-marker-stack, but until then we cannot use
its key for an entirely different command, I think.

Re: tags-loop-continue

[Dmitry Gutov]

On 01/14/2016 07:00 PM, Eli Zaretskii wrote:
> When tags-loop-continue is no longer needed

How's our progress on that front? Like I said, it would be trivial to 
implement a dired-do-search alternative based on the current xref 
presentation.

Anything else we need for completeness?

Re: tags-loop-continue

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 14 Jan 2016 19:07:04 +0300
> 
> On 01/14/2016 07:00 PM, Eli Zaretskii wrote:
> > When tags-loop-continue is no longer needed
> 
> How's our progress on that front?

Not sure what you mean by "our progress".

> Like I said, it would be trivial to implement a dired-do-search
> alternative based on the current xref presentation.
> 
> Anything else we need for completeness?

I guess dired-do-query-replace-regexp is the other one (bound to 'Q'
in Dired).

Re: tags-loop-continue

[Dmitry Gutov]

On 01/14/2016 08:17 PM, Eli Zaretskii wrote:

> Not sure what you mean by "our progress".

I've asked for the list of commands without equivalents in the previous 
emails.

>> Anything else we need for completeness?
>
> I guess dired-do-query-replace-regexp is the other one (bound to 'Q'
> in Dired).

Why not let the user call dired-do-search, and then press `r'?

Re: tags-loop-continue

[Dmitry Gutov]

On 01/14/2016 08:26 PM, Dmitry Gutov wrote:

 > Why not let the user call dired-do-search

Or dired-find-regexp, or whatever the new command will be called.

Re: tags-loop-continue

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 14 Jan 2016 20:39:34 +0300
> Cc: emacs-devel@gnu.org
> 
> On 01/14/2016 08:26 PM, Dmitry Gutov wrote:
> 
>  > Why not let the user call dired-do-search
> 
> Or dired-find-regexp, or whatever the new command will be called.

I'm much less worried by the name of the command than by the UI it
presents.  If what you suggest allows to do the equivalent of
dired-do-query-replace-regexp with a similar UI, then I guess we can
bind that equivalent to 'Q' in Dired and be done.

Re: tags-loop-continue

[Dmitry Gutov]

On 01/14/2016 09:36 PM, Eli Zaretskii wrote:

> I'm much less worried by the name of the command than by the UI it
> presents.

People keep leaving the naming decisions up to me. I'm not happy about that.

> If what you suggest allows to do the equivalent of
> dired-do-query-replace-regexp with a similar UI, then I guess we can
> bind that equivalent to 'Q' in Dired and be done.

It wouldn't. The alternative version of dired-find-regexp that I 
proposed wouldn't use the "traditional" UI either.

If it would, it would need tags-loop-continue. How will we obsolete this 
command, then?

Re: tags-loop-continue

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 14 Jan 2016 20:26:19 +0300
> 
> On 01/14/2016 08:17 PM, Eli Zaretskii wrote:
> 
> > Not sure what you mean by "our progress".
> 
> I've asked for the list of commands without equivalents in the previous 
> emails.

Did I now answer that?

> >> Anything else we need for completeness?
> >
> > I guess dired-do-query-replace-regexp is the other one (bound to 'Q'
> > in Dired).
> 
> Why not let the user call dired-do-search, and then press `r'?

Because people who used to have 'Q' will want to press it and get what
they are used to, I guess.

IOW, I think we should avoid gratuitously breaking backward
compatibility.  Can we have faithful emulations of these commands' UI,
bound to the same keys, just working differently under the hood?

Re: tags-loop-continue

[Dmitry Gutov]

On 01/14/2016 09:31 PM, Eli Zaretskii wrote:

>> Why not let the user call dired-do-search, and then press `r'?
>
> Because people who used to have 'Q' will want to press it and get what
> they are used to, I guess.

Ok. If you insist, I can make a version of the same logic that would 
skip generating the output buffer.

> IOW, I think we should avoid gratuitously breaking backward
> compatibility.  Can we have faithful emulations of these commands' UI,
> bound to the same keys, just working differently under the hood?

We could, I suppose.

But that wouldn't remove the need for tags-loop-continue, would it? Or a 
command just like it.

And I really want to use the M-, binding for xref-pop-marker-stack.

 >> I've asked for the list of commands without equivalents in the 
previous emails.
 >
 > Did I now answer that?

...I think? It can be a long discussion:

- Do we create versions of all new commands that use the traditional 
interface? I wouldn't mind having that, but it's not high on my list of 
priorities, and it would require some additional design, and some more 
volunteer(s). Logically, the commands will have customizable 
presentation, which in itself is a good thing, of course.

- If not, do we have similar commands that use different presentations? 
Do we reflect the distinction in their names? How? For now, we're 
calling the new UI also xref, but it conflates it with the core xref 
infrastructure (backends and "smart" IDE-ish commands).

Either way, it seems prudent to extract the current UI part of xref to a 
package with an appropriate name.

Re: tags-loop-continue

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 14 Jan 2016 21:44:03 +0300
> 
> On 01/14/2016 09:31 PM, Eli Zaretskii wrote:
> 
> >> Why not let the user call dired-do-search, and then press `r'?
> >
> > Because people who used to have 'Q' will want to press it and get what
> > they are used to, I guess.
> 
> Ok. If you insist, I can make a version of the same logic that would 
> skip generating the output buffer.

I just want the people who are used to 'Q' to have something similar
to what they knew before.  It might be okay to show *xref*-style
buffer with the hits, though.  Is that what you meant by "press 'r'"?

> > IOW, I think we should avoid gratuitously breaking backward
> > compatibility.  Can we have faithful emulations of these commands' UI,
> > bound to the same keys, just working differently under the hood?
> 
> We could, I suppose.
> 
> But that wouldn't remove the need for tags-loop-continue, would it? Or a 
> command just like it.
> 
> And I really want to use the M-, binding for xref-pop-marker-stack.

Why is it so important to use that particular binding for
xref-pop-marker-stack?  What's wrong with 'M-*'?

> - Do we create versions of all new commands that use the traditional 
> interface?

No, not necessarily.  They should be functionally equivalent and
similar enough in principle.  They don't have to have the same
interface.

> - If not, do we have similar commands that use different presentations? 
> Do we reflect the distinction in their names? How? For now, we're 
> calling the new UI also xref, but it conflates it with the core xref 
> infrastructure (backends and "smart" IDE-ish commands).

For lack of a better name, I guess.  The old one was called "etags"
for the same reason, and had the same problems.

> Either way, it seems prudent to extract the current UI part of xref to a 
> package with an appropriate name.

You will still have the problem of coming up with a suitable name ;-)

Re: tags-loop-continue

[Dmitry Gutov]

On 01/14/2016 10:02 PM, Eli Zaretskii wrote:

> I just want the people who are used to 'Q' to have something similar
> to what they knew before.  It might be okay to show *xref*-style
> buffer with the hits, though.

Then they can call `next-error' instead. Unfortunately, this facility is 
unreliable in the presence of different next-error-function's in target 
buffers. But that was before xref came along.

> Is that what you meant by "press 'r'"?

I just mean that we don't have to have a separate command outside of 
search results buffer. Yes, it's unfamiliar, but the functionality is 
covered, and the manual will tell the user needs to do.

`r', pressed in an project-find-regexp output buffer, will call 
xref-query-replace. Which, yes, is currently implemented using 
`perform-replace', but that should change.

> Why is it so important to use that particular binding for
> xref-pop-marker-stack?  What's wrong with 'M-*'?

SLIME has shown that it's better. M-* is much farther from M-., and you 
can't as quickly navigate back by keeping M pressed, releasing `.' and 
pressing `,'.

And really, the xref UI doesn't need it. We should commit to one default 
paradigm of behavior. (If we had customizable switching between the old 
and the new UIs, we'd introduce a minor mode that would also change the 
global bindings).

>> - Do we create versions of all new commands that use the traditional
>> interface?
>
> No, not necessarily.  They should be functionally equivalent and
> similar enough in principle.  They don't have to have the same
> interface.

What are the requirements, then?

> For lack of a better name, I guess.  The old one was called "etags"
> for the same reason, and had the same problems.

Yes, ugh. But now we have two different UIs, so the issue is more 
pressing, unless we're content on altogether migrating off the old UI.

> You will still have the problem of coming up with a suitable name ;-)

Also yes.

Re: tags-loop-continue

[Dmitry Gutov]

On 01/14/2016 10:15 PM, Dmitry Gutov wrote:

> Then they can call `next-error' instead. Unfortunately, this facility is
> unreliable in the presence of different next-error-function's in target
> buffers. But that was   before xref came along.
                         ^ even

Re: tags-loop-continue

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 14 Jan 2016 22:15:21 +0300
> 
> On 01/14/2016 10:02 PM, Eli Zaretskii wrote:
> 
> > I just want the people who are used to 'Q' to have something similar
> > to what they knew before.  It might be okay to show *xref*-style
> > buffer with the hits, though.
> 
> Then they can call `next-error' instead. Unfortunately, this facility is 
> unreliable in the presence of different next-error-function's in target 
> buffers. But that was before xref came along.
> 
> > Is that what you meant by "press 'r'"?
> 
> I just mean that we don't have to have a separate command outside of 
> search results buffer. Yes, it's unfamiliar, but the functionality is 
> covered, and the manual will tell the user needs to do.

Could be fine, I think.  We did change this in find-definition, so
maybe making a similar change in Dired is okay as well.

> > Why is it so important to use that particular binding for
> > xref-pop-marker-stack?  What's wrong with 'M-*'?
> 
> SLIME has shown that it's better. M-* is much farther from M-., and you 
> can't as quickly navigate back by keeping M pressed, releasing `.' and 
> pressing `,'.

When I use these commands, I don't really go back and forth that way.
In fact, I need to use M-* only rarely.

> And really, the xref UI doesn't need it.

As long as the *xref* buffer is displayed, it doesn't.  But once it is
buried, there's no easy way to go to the next hit, right?

> We should commit to one default paradigm of behavior.

I think I agree.

> >> - Do we create versions of all new commands that use the traditional
> >> interface?
> >
> > No, not necessarily.  They should be functionally equivalent and
> > similar enough in principle.  They don't have to have the same
> > interface.
> 
> What are the requirements, then?

I don't know, to present a reasonable UI for an equivalent
functionality?

Re: tags-loop-continue

[Dmitry Gutov]

On 01/14/2016 10:41 PM, Eli Zaretskii wrote:

> Could be fine, I think.  We did change this in find-definition, so
> maybe making a similar change in Dired is okay as well.

Nice. What do we do? Change dired-do-search to use the new UI, or add a 
new command? Do we call the new command simply dired-find-regexp?

> When I use these commands, I don't really go back and forth that way.
> In fact, I need to use M-* only rarely.

I do. In fact, I even use a third-party package called "history", which 
allows to quickly just back and forward the navigation history.

IIRC, Daniel also commented on how easy and handy it is.

> As long as the *xref* buffer is displayed, it doesn't.  But once it is
> buried, there's no easy way to go to the next hit, right?

Also `next-error' (next-error-function is set globally, after all). The 
fact that it doesn't always work is one of the problems I mentioned.

And if we had a separate command for that, why integrate with next-error 
at all? And people asked for that so confidently.

>> What are the requirements, then?
>
> I don't know, to present a reasonable UI for an equivalent
> functionality?

That just comes down to adding dired-find-regexp that uses the xref UI, 
AFAICS. Do we also change the `A' binding in Dired? And unbind `Q'?

Re: tags-loop-continue

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 14 Jan 2016 23:09:23 +0300
> 
> On 01/14/2016 10:41 PM, Eli Zaretskii wrote:
> 
> > Could be fine, I think.  We did change this in find-definition, so
> > maybe making a similar change in Dired is okay as well.
> 
> Nice. What do we do? Change dired-do-search to use the new UI, or add a 
> new command?

A new command, I think.  One step at a time.

> Do we call the new command simply dired-find-regexp?

It should be dired-do-SOMETHING, for consistency with others.
Otherwise, yes, something like that.

> >> What are the requirements, then?
> >
> > I don't know, to present a reasonable UI for an equivalent
> > functionality?
> 
> That just comes down to adding dired-find-regexp that uses the xref UI, 
> AFAICS. Do we also change the `A' binding in Dired? And unbind `Q'?

Or maybe have a minor variant bound to 'Q' that would also ask for a
replacement, like query-replace?

Re: tags-loop-continue

[Dmitry Gutov]

On 01/14/2016 11:21 PM, Eli Zaretskii wrote:
> A new command, I think.  One step at a time.

> It should be dired-do-SOMETHING, for consistency with others.

> Or maybe have a minor variant bound to 'Q' that would also ask for a
> replacement, like query-replace?

Added both commands. Please check them out.

If they're considered good enough, I think we can re-obsolete 
tags-loop-continue, and obsolete dired-do-search and 
dired-do-query-replace-regexp as well.

Re: tags-loop-continue

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 18 Jan 2016 22:19:56 +0300
> 
> On 01/14/2016 11:21 PM, Eli Zaretskii wrote:
> > A new command, I think.  One step at a time.
> 
> > It should be dired-do-SOMETHING, for consistency with others.
> 
> > Or maybe have a minor variant bound to 'Q' that would also ask for a
> > replacement, like query-replace?
> 
> Added both commands. Please check them out.

Thanks, I took a look at the two commands.  They look good overall,
IMO, but I have a few comments.

First, they both take a long time to display the first match.  I
understand that's because you run Grep to collect all the matches, but
can't you let Grep run asynchronously, display the first match as soon
as it comes in, and then update the list as the rest arrive?  You
don't need to present the matches in any particular order, so it
sounds like waiting for all of them is not required.

I think this initial delay will be quite long in large directories (I
tried with Emacs's 'src' directory, which is not very large, and my
disk is SSD, but it still took annoyingly long).  I'm guessing we will
get a lot of complains from users of these two commands who were
accustomed to a much faster startup.

My other problem is with the "disappearing *xref* buffer" phenomenon:
it is too easy to lose it, and not so easy to get it back.  With 'A'
(dired-do-find-regexp) it's enough to type RET on a line in the *xref*
buffer in order to have its window deleted; the only way to get it
back AFAICT is to manually switch to that buffer, which means the user
must remember its name.  You cannot continue the search without
switching back to *xref* first.  So I think RET should not delete the
window in this case.  Maybe it should never delete the window, in
other users of xref, I'm not sure.  At least in this case, unlike with
xref-find-definition, it is much more probable that the user _will_
want to go to the next match, so it makes less sense IMO to delete the
window.

With 'Q' (dired-find-regexp-and-replace) losing *xref* is a lot
easier: as you walk through the matches, the window which displayed
*xref* suddenly switches to display one of the files with matches
instead of showing *xref*.  I think that window should not be reused
for showing matches (perhaps through some display-buffer magic).

Even worse, there seems to be no way of continuing with the
query-replace operation once it is interrupted for some reason.  It
happened to me when I tried to resize the window (because I wanted to
see less of the *xref* buffer) -- Emacs exited the query-replace
command, and I couldn't find a way to continue it where I left off,
even after switching to the *xref* buffer.  I think there should be a
way, perhaps with '.' and/or RET, to continue the query-replace from
the match on the current line in *xref*, otherwise people will
complain.

> If they're considered good enough, I think we can re-obsolete 
> tags-loop-continue, and obsolete dired-do-search and 
> dired-do-query-replace-regexp as well.

I wouldn't obsolete them just yet.  We may wish letting users who will
be unhappy with the new UI to have a way to get the old behavior back,
until the new UI is improved enough to satisfy users.  But we can
certainly document the new commands instead of the old ones in the
manual.

Thanks.

Re: tags-loop-continue

[Dmitry Gutov]

On 01/20/2016 02:19 PM, Eli Zaretskii wrote:

> My other problem is with the "disappearing *xref* buffer" phenomenon:
> it is too easy to lose it, and not so easy to get it back.  With 'A'
> (dired-do-find-regexp) it's enough to type RET on a line in the *xref*
> buffer in order to have its window deleted; the only way to get it
> back AFAICT is to manually switch to that buffer, which means the user
> must remember its name.

Or repeat the search. After the repeating it enough times, the user 
might start to remember the name of the buffer.

> You cannot continue the search without
> switching back to *xref* first.

You mean with `next-error'? When so, it's simply a bug in next-error.

> So I think RET should not delete the
> window in this case.  Maybe it should never delete the window, in
> other users of xref, I'm not sure.  At least in this case, unlike with
> xref-find-definition, it is much more probable that the user _will_
> want to go to the next match, so it makes less sense IMO to delete the
> window.

Let's say I agree. What shall we do with xref-find-definitions? Should 
the user understand somehow that in this case RET won't bury the buffer, 
and in xref-find-definitions' case, it wont?

I suppose we could provide a separate key (`a'?) that would do what RET 
does now.

Re: tags-loop-continue

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 21 Jan 2016 07:59:11 +0300
> 
> On 01/20/2016 02:19 PM, Eli Zaretskii wrote:
> 
> > My other problem is with the "disappearing *xref* buffer" phenomenon:
> > it is too easy to lose it, and not so easy to get it back.  With 'A'
> > (dired-do-find-regexp) it's enough to type RET on a line in the *xref*
> > buffer in order to have its window deleted; the only way to get it
> > back AFAICT is to manually switch to that buffer, which means the user
> > must remember its name.
> 
> Or repeat the search. After the repeating it enough times, the user 
> might start to remember the name of the buffer.

Repeating the search was precisely what I did.  But that's not exactly
user-friendly, I think.

> > You cannot continue the search without
> > switching back to *xref* first.
> 
> You mean with `next-error'? When so, it's simply a bug in next-error.

Using next-error never occurred to me (there's nothing about that in
NEWS or in the manual).  Yes, that works.  But it has the problem you
mentioned in a past discussion: if you have (say) a Grep buffer from a
recent search, it's not easy to tell next-error which of them to use.
I guess the feature you suggested back then for making this easier
never materialized?  Maybe we should introduce it now.

> > So I think RET should not delete the
> > window in this case.  Maybe it should never delete the window, in
> > other users of xref, I'm not sure.  At least in this case, unlike with
> > xref-find-definition, it is much more probable that the user _will_
> > want to go to the next match, so it makes less sense IMO to delete the
> > window.
> 
> Let's say I agree. What shall we do with xref-find-definitions? Should 
> the user understand somehow that in this case RET won't bury the buffer, 
> and in xref-find-definitions' case, it wont?
> 
> I suppose we could provide a separate key (`a'?) that would do what RET 
> does now.

Maybe we should make RET do the same as '.' in all cases, and provide
a separate key to delete the window showing *xref*.

WDYT?

Re: tags-loop-continue

[Dmitry Gutov]

On 01/21/2016 08:02 PM, Eli Zaretskii wrote:

> Repeating the search was precisely what I did.  But that's not exactly
> user-friendly, I think.

Sure.

> Using next-error never occurred to me (there's nothing about that in
> NEWS or in the manual).  Yes, that works.  But it has the problem you
> mentioned in a past discussion: if you have (say) a Grep buffer from a
> recent search, it's not easy to tell next-error which of them to use.
> I guess the feature you suggested back then for making this easier
> never materialized?  Maybe we should introduce it now.

Its details are still unclear, as far as I'm concerned: both the UI and 
the changes in the API, which may be required.

It's probably too late for 25.1.

>> I suppose we could provide a separate key (`a'?) that would do what RET
>> does now.
>
> Maybe we should make RET do the same as '.' in all cases, and provide
> a separate key to delete the window showing *xref*.

'.' moves point to the next line, shows the corresponding location in 
the other window, but does not switch to it.

You probably mean the same as me: 'RET' shows the location in the other 
window, and switches to it. 'a' quits the *xref* buffer, then does the same.

Re: tags-loop-continue

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 21 Jan 2016 20:12:00 +0300
> 
> > Using next-error never occurred to me (there's nothing about that in
> > NEWS or in the manual).  Yes, that works.  But it has the problem you
> > mentioned in a past discussion: if you have (say) a Grep buffer from a
> > recent search, it's not easy to tell next-error which of them to use.
> > I guess the feature you suggested back then for making this easier
> > never materialized?  Maybe we should introduce it now.
> 
> Its details are still unclear, as far as I'm concerned: both the UI and 
> the changes in the API, which may be required.
> 
> It's probably too late for 25.1.

I'm not sure.  I am talking about a new command, which will allow the
user to select one of the buffers which have next-error-function set.
AFAIU, introducing such a command doesn't require any serious changes
anywhere, right?

> You probably mean the same as me: 'RET' shows the location in the other 
> window, and switches to it. 'a' quits the *xref* buffer, then does the same.

Yes, sorry for my confusing wording.

Re: tags-loop-continue

[Dmitry Gutov]

On 01/21/2016 08:47 PM, Eli Zaretskii wrote:

> I'm not sure.  I am talking about a new command, which will allow the
> user to select one of the buffers which have next-error-function set.
> AFAIU, introducing such a command doesn't require any serious changes
> anywhere, right?

I don't think it would help enough: you might end up having to call that 
newly introduced command before every `next-error' invocation: 
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20489#11

Re: tags-loop-continue

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 21 Jan 2016 21:58:19 +0300
> 
> On 01/21/2016 08:47 PM, Eli Zaretskii wrote:
> 
> > I'm not sure.  I am talking about a new command, which will allow the
> > user to select one of the buffers which have next-error-function set.
> > AFAIU, introducing such a command doesn't require any serious changes
> > anywhere, right?
> 
> I don't think it would help enough: you might end up having to call that 
> newly introduced command before every `next-error' invocation: 
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20489#11

Yes, I know.  But in this case a partial solution is better than no
solution at all, IMO.  We don't need to solve every corner case now.

Re: tags-loop-continue

[Dmitry Gutov]

On 01/21/2016 10:02 PM, Eli Zaretskii wrote:

> Yes, I know.  But in this case a partial solution is better than no
> solution at all, IMO.

Not sure about that: I _don't_ want to call 
`change-next-error-last-buffer' every time, and type the buffer's name. 
I simply won't use that.

> We don't need to solve every corner case now.

For all we know, a proper solution won't include the kind of command 
you're suggesting at all. I don't want to leave another historical accident.

Re: tags-loop-continue

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 21 Jan 2016 22:11:41 +0300
> 
> On 01/21/2016 10:02 PM, Eli Zaretskii wrote:
> 
> > Yes, I know.  But in this case a partial solution is better than no
> > solution at all, IMO.
> 
> Not sure about that: I _don't_ want to call 
> `change-next-error-last-buffer' every time, and type the buffer's name. 
> I simply won't use that.

You don't have to if you don't want to.  But someone else might.

> > We don't need to solve every corner case now.
> 
> For all we know, a proper solution won't include the kind of command 
> you're suggesting at all. I don't want to leave another historical accident.

Fine, then let's have the proper solution.  Having none in v25.1 is
not an option.

Re: tags-loop-continue

[Dmitry Gutov]

On 01/21/2016 10:56 PM, Eli Zaretskii wrote:

> Fine, then let's have the proper solution.  Having none in v25.1 is
> not an option.

You're welcome to continue this discussion in 
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20489.

The problem looks bad, but it doesn't seem like it bothers a lot of 
people, and the pyramid of hacks in next-error-find-buffer does indicate 
that the current behavior is at least intentional.

Since the bug is old, I wouldn't call it a blocker for 25.1.

As far as xref goes, we'll just have to make extra sure not to hide its 
buffer.

Re: tags-loop-continue

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 21 Jan 2016 23:15:49 +0300
> 
> On 01/21/2016 10:56 PM, Eli Zaretskii wrote:
> 
> > Fine, then let's have the proper solution.  Having none in v25.1 is
> > not an option.
> 
> You're welcome to continue this discussion in 
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20489.
> 
> The problem looks bad, but it doesn't seem like it bothers a lot of 
> people

That's because not a lot of people got exposed to the problem yet.
They will once v25.1 hits the street.

> and the pyramid of hacks in next-error-find-buffer does indicate
> that the current behavior is at least intentional.

I don't see how this is relevant.  I'm not saying the code doesn't
work as designed, I'm saying there's a deficiency in the collection of
commands that use next-error, which inconveniences users.

> Since the bug is old, I wouldn't call it a blocker for 25.1.

I disagree.  I think the problem is bad enough to have it solved now.

> As far as xref goes, we'll just have to make extra sure not to hide its 
> buffer.

We should do that, indeed.  But we won't be able to prevent that in
100% of cases.

Re: tags-loop-continue

[Dmitry Gutov]

On 01/21/2016 11:36 PM, Eli Zaretskii wrote:

> That's because not a lot of people got exposed to the problem yet.
> They will once v25.1 hits the street.

I can reproduce it without xref, e.g. just by using next-error-function 
provided by change-log-mode and Flycheck (which sets next-error-function 
in buffers locally). Probably Flymake too.

>> Since the bug is old, I wouldn't call it a blocker for 25.1.
>
> I disagree.  I think the problem is bad enough to have it solved now.

Please look for other volunteers than myself, then.

Re: tags-loop-continue

[Dmitry Gutov]

On 01/22/2016 12:17 AM, Dmitry Gutov wrote:

> Please look for other volunteers than myself, then.

Here's an idea: we remove xref's integration with next-error-function. 
Probably notify the people who asked for it.

And if someone asks for it back, ask them to go fix bug#20489 first.

Re: tags-loop-continue

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 22 Jan 2016 00:26:29 +0300
> 
> Here's an idea: we remove xref's integration with next-error-function. 
> Probably notify the people who asked for it.
> 
> And if someone asks for it back, ask them to go fix bug#20489 first.

I was about to suggest this myself.  So yes, let's do that.  If we
indeed try harder to leave the *xref* buffer visible, the need for
this integration would be lower.

Thanks.

Re: tags-loop-continue

[Dmitry Gutov]

On 01/22/2016 09:59 AM, Eli Zaretskii wrote:

>> And if someone asks for it back, ask them to go fix bug#20489 first.
>
> I was about to suggest this myself.  So yes, let's do that.  If we
> indeed try harder to leave the *xref* buffer visible, the need for
> this integration would be lower.

On the other hand, while *xref* is visible, `next-error' will keep 
working for its results (it's item 1 in next-error-find-buffer).

That's how `next-error' stayed useful for e.g. *compilation* all these 
years. And it's fairly handy to call `next-error' to go to the next 
result, without having to switch back to *compilation*.

So, do we really remove the integration? Up to you.

diff --git a/lisp/progmodes/xref.el b/lisp/progmodes/xref.el
index 2bccd85..1d71d24 100644
--- a/lisp/progmodes/xref.el
+++ b/lisp/progmodes/xref.el
@@ -600,22 +600,8 @@ xref--xref-buffer-mode-map
  (define-derived-mode xref--xref-buffer-mode special-mode "XREF"
    "Mode for displaying cross-references."
    (setq buffer-read-only t)
-  (setq next-error-function #'xref--next-error-function)
    (setq next-error-last-buffer (current-buffer)))

-(defun xref--next-error-function (n reset?)
-  (when reset?
-    (goto-char (point-min)))
-  (let ((backward (< n 0))
-        (n (abs n))
-        (xref nil))
-    (dotimes (_ n)
-      (setq xref (xref--search-property 'xref-item backward)))
-    (cond (xref
-           (xref--pop-to-location xref))
-          (t
-           (error "No %s xref" (if backward "previous" "next"))))))
-
  (defun xref-quit (&optional kill)
    "Bury temporarily displayed buffers, then quit the current window.

Re: tags-loop-continue

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 22 Jan 2016 13:13:20 +0300
> 
> On 01/22/2016 09:59 AM, Eli Zaretskii wrote:
> 
> >> And if someone asks for it back, ask them to go fix bug#20489 first.
> >
> > I was about to suggest this myself.  So yes, let's do that.  If we
> > indeed try harder to leave the *xref* buffer visible, the need for
> > this integration would be lower.
> 
> On the other hand, while *xref* is visible, `next-error' will keep 
> working for its results (it's item 1 in next-error-find-buffer).
> 
> That's how `next-error' stayed useful for e.g. *compilation* all these 
> years. And it's fairly handy to call `next-error' to go to the next 
> result, without having to switch back to *compilation*.

The problem is not with *compilation* alone or with *xref* alone, the
problem happens when you have both of them.

> So, do we really remove the integration? Up to you.

I think removing it will leave us with a lesser evil.  Maybe leaving
that code commented out with a reference to bug#20489 would increase
the discoverability of the problem, and we could have a solution
sooner, I don't know.

We could also have a defcustom (to enable this in *xref*), but that
sounds too much, no?

Thanks.

Re: tags-loop-continue

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

> We could also have a defcustom (to enable this in *xref*), but that sounds
> too much, no?

I don't know, a customization gives people an easy way to test enabling that
feature, since xref is currently experimental.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: tags-loop-continue

[Dmitry Gutov]

On 01/22/2016 08:51 PM, John Wiegley wrote:

> I don't know, a customization gives people an easy way to test enabling that
> feature, since xref is currently experimental.

Wouldn't that go against the incentive for someone to fix the bug?

next-error-function integration in xref removed

[Dmitry Gutov]

On 01/22/2016 05:08 PM, Eli Zaretskii wrote:

> The problem is not with *compilation* alone or with *xref* alone, the
> problem happens when you have both of them.

Ok, done.

Let this email be the notification for people who asked for next-error 
integration in xref: it's currently removed, again.

For the motivation behind it, please refer to 
http://lists.gnu.org/archive/html/emacs-devel/2016-01/msg01242.html and 
http://lists.gnu.org/archive/html/emacs-devel/2016-01/msg01260.html.

Re: next-error-function integration in xref removed

[John Wiegley]

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

> Let this email be the notification for people who asked for next-error
> integration in xref: it's currently removed, again.

> For the motivation behind it, please refer to
> http://lists.gnu.org/archive/html/emacs-devel/2016-01/msg01242.html and
> http://lists.gnu.org/archive/html/emacs-devel/2016-01/msg01260.html.

Thanks, Dmitry, and especially for giving those links for the record.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: tags-loop-continue

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

>> The problem looks bad, but it doesn't seem like it bothers a lot of people

> That's because not a lot of people got exposed to the problem yet. They will
> once v25.1 hits the street.

Hi Dmitry,

Eli has made points similar to this several times now. Please consider that
any feeling you have about "what people think" about this feature is invalid
right now, because there is close to zero experience with xref and project.
Silence from the people on this list should not be taken to mean anything, at
least as far as judgments about the user interface are concerned.

I just wanted to emphasize this, because I feel the point is not hitting home
yet. Eli is, in a sense, one of your first real users, and so the experiences
he's having right now are the ones to pay attention to.

Thanks,
-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: tags-loop-continue

[Dmitry Gutov]

John,

On 01/22/2016 04:54 AM, John Wiegley wrote:

> Eli has made points similar to this several times now. Please consider that
> any feeling you have about "what people think" about this feature is invalid
> right now, because there is close to zero experience with xref and project.
> Silence from the people on this list should not be taken to mean anything, at
> least as far as judgments about the user interface are concerned.

The message you're quoting is about a years-old problem which has 
nothing to do with me (or xref), except I've brought it up in 
discussions and filed a bug.

> I just wanted to emphasize this, because I feel the point is not hitting home
> yet. Eli is, in a sense, one of your first real users, and so the experiences
> he's having right now are the ones to pay attention to.

Why don't you work on it? It's over there: http://debbugs.gnu.org/20489

Re: tags-loop-continue

[John Wiegley]

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

>> Eli has made points similar to this several times now. Please consider that
>> any feeling you have about "what people think" about this feature is
>> invalid right now, because there is close to zero experience with xref and
>> project. Silence from the people on this list should not be taken to mean
>> anything, at least as far as judgments about the user interface are
>> concerned.

> The message you're quoting is about a years-old problem which has nothing to
> do with me (or xref), except I've brought it up in discussions and filed a
> bug.

Ah, I see, my apologies. I thought this was somehow related to xref.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: tags-loop-continue

[Dmitry Gutov]

On 01/20/2016 02:19 PM, Eli Zaretskii wrote:

(I'll get to the performance issues later.)

> With 'Q' (dired-find-regexp-and-replace) losing *xref* is a lot
> easier: as you walk through the matches, the window which displayed
> *xref* suddenly switches to display one of the files with matches
> instead of showing *xref*.  I think that window should not be reused
> for showing matches (perhaps through some display-buffer magic).

I never thought that the *xref* buffer is important for 
dired-find-regexp-and-replace, and even considered creating a modified 
version of xref-query-replace that wouldn't require that buffer. But 
indeed, it seems important for continuing the replace operation.

> Even worse, there seems to be no way of continuing with the
> query-replace operation once it is interrupted for some reason.  It
> happened to me when I tried to resize the window (because I wanted to
> see less of the *xref* buffer) -- Emacs exited the query-replace
> command, and I couldn't find a way to continue it where I left off,
> even after switching to the *xref* buffer.  I think there should be a
> way, perhaps with '.' and/or RET, to continue the query-replace from
> the match on the current line in *xref*, otherwise people will
> complain.

I think we can do something like this: as the user agrees to 
replacements, we disable/mark/hide corresponding entries in the xref buffer.

So if the user aborts the replace process, the *xref* buffer only 
contains the entries they haven't gotten around to. (Or the skipped ones 
too? That might be harder to implement).

Then, pressing `r' again will continue where they left off.

> I wouldn't obsolete them just yet.  We may wish letting users who will
> be unhappy with the new UI to have a way to get the old behavior back,
> until the new UI is improved enough to satisfy users.  But we can
> certainly document the new commands instead of the old ones in the
> manual.

We've obsoleted find-tag and friends, though. Is that really a problem?

Re: tags-loop-continue

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 21 Jan 2016 08:15:17 +0300
> 
> > With 'Q' (dired-find-regexp-and-replace) losing *xref* is a lot
> > easier: as you walk through the matches, the window which displayed
> > *xref* suddenly switches to display one of the files with matches
> > instead of showing *xref*.  I think that window should not be reused
> > for showing matches (perhaps through some display-buffer magic).
> 
> I never thought that the *xref* buffer is important for 
> dired-find-regexp-and-replace, and even considered creating a modified 
> version of xref-query-replace that wouldn't require that buffer. But 
> indeed, it seems important for continuing the replace operation.

I think having the *xref* buffer visible is _the_ reason we could get
rid of tags-loop-continue.

> > Even worse, there seems to be no way of continuing with the
> > query-replace operation once it is interrupted for some reason.  It
> > happened to me when I tried to resize the window (because I wanted to
> > see less of the *xref* buffer) -- Emacs exited the query-replace
> > command, and I couldn't find a way to continue it where I left off,
> > even after switching to the *xref* buffer.  I think there should be a
> > way, perhaps with '.' and/or RET, to continue the query-replace from
> > the match on the current line in *xref*, otherwise people will
> > complain.
> 
> I think we can do something like this: as the user agrees to 
> replacements, we disable/mark/hide corresponding entries in the xref buffer.
> 
> So if the user aborts the replace process, the *xref* buffer only 
> contains the entries they haven't gotten around to. (Or the skipped ones 
> too? That might be harder to implement).

No, I think all the matches that the user saw already, whether she
accepted the replacement or not, should be marked in some way, so that
continuing the replacement goes to the first unseen one.

> > I wouldn't obsolete them just yet.  We may wish letting users who will
> > be unhappy with the new UI to have a way to get the old behavior back,
> > until the new UI is improved enough to satisfy users.  But we can
> > certainly document the new commands instead of the old ones in the
> > manual.
> 
> We've obsoleted find-tag and friends, though.

Yes, but that was long ago, while these two commands are going to be
replaced just now.  Besides, they are Dired commands, not etags
commands.  So I think it does make a difference.  In any case, this is
not a terribly important point, it's easy to obsolete and it's also
easy to unobsolete later if we change our minds.  We can defer the
decision for later.

Thanks.

xref and displaying locations in appropriate window or frame

[Dmitry Gutov]

On 01/21/2016 08:07 PM, Eli Zaretskii wrote:

> I think having the *xref* buffer visible is _the_ reason we could get
> rid of tags-loop-continue.

Here's where I'm currently stumped:

xref-find-definitions has a family of commands (namely -other-window and 
-other-frame) which promise to display the location somewhere else than 
the current window.

If we're allowed to quit the *xref* buffer before jumping to the "final 
destination", we can nominally satisfy the contract by using 
switch-to-buffer or pop-to-buffer (maybe with pop-up-frames bound to t) 
after that. The *xref* buffer and its window are out of the picture by 
that point.

However, now we have the *xref* buffer back in the picture. I think that 
means we have to satisfy the this-window/other-window/other-frame 
contract while *xref* is displayed.

- xref-find-definitions-other-frame seems easiest: just bind 
pop-up-frames to t and call pop-to-buffer like before.
- xref-find-definitions promises to show the destination buffer in the 
current window. What will RET in *xref* do? Show the buffers in the 
window xref-find-definitions was called from? That seems to make the 
most sense, but it will obscure the original code. Maybe we'd want to 
consult it while picking the exact option among the suggested definitions?
- xref-find-definitions-other-window should, apparently, pick some 
window which isn't the original one, nor the one which displays the 
*xref* buffer. Or create a new one, in a pop-to-buffer fashion. Is there 
a function in window.el I can reuse, and/or display-buffer alist 
argument that would make it ignore whole two buffers, and not just the 
currently selected one?

Compilation has no such contract, so there's nothing corresponding in 
there that I could borrow.

Alternatively, we *do* treat xref-find-definitions differently, and 
don't keep the *xref* buffer visible after the user made their choice. 
But if the *xref* buffer looks the same as in other cases, it would be 
confusing. So ideally, we'd have a different choice-picking mechanism in 
this case (not *xref* buffer like it works and looks right now), but I 
really don't know where to start writing it (and don't want to do it now).

Yet alternatively, as soon as we find out that there are several 
definitions of the given function, we abandon all that 
other-window/other-frame business, and simply make RET always behave the 
same in *xref*. That seems like a cop-out. But maybe it's what we should 
do anyway until someone implements the second option (the previous 
paragraph).

> No, I think all the matches that the user saw already, whether she
> accepted the replacement or not, should be marked in some way, so that
> continuing the replacement goes to the first unseen one.

Good, that should be easier to do.

Re: xref and displaying locations in appropriate window or frame

[martin rudalics]

 > - xref-find-definitions-other-window should, apparently, pick some
 > window which isn't the original one, nor the one which displays the
 > *xref* buffer. Or create a new one, in a pop-to-buffer fashion. Is
 > there a function in window.el I can reuse, and/or display-buffer alist
 > argument that would make it ignore whole two buffers, and not just the
 > currently selected one?

No.  Satisfying a contract that requires three windows to appear
simultaneously on a frame is impossible with ‘display-buffer’ on a
default Emacs.

I can only give my personal preference, feel free to ignore it: *xref*
would be displayed by ‘with-temp-buffer-window’ so that I can use
‘temp-buffer-resize-mode’ on it.  By default *xref* would be shown at
the bottom of the frame with columns arranged as in the *Completions*
buffer.

Conceptually, this should allow to split the "original" window into two
side-by-side windows where the left one would continue to display the
original buffer and the right one would display the buffer chosen by
‘xref-find-definitions-other-window’.  If there's already another window
on the side of the original window, that window would be reused by
‘xref-find-definitions-other-window’.

Obviously, if the frame is too narrow, splitting will fail and the
buffer will be shown in the original window.  But, as mentioned above,
there's nothing you can do about this.  The doc-string of
‘xref-find-definitions-other-window’ should probably mention it.

And ‘xref-find-definitions’ would display its buffer in the original
window above the *xref* window.

martin

Re: xref and displaying locations in appropriate window or frame

[Dmitry Gutov]

On 01/24/2016 01:55 PM, martin rudalics wrote:

> I can only give my personal preference, feel free to ignore it: *xref*
> would be displayed by ‘with-temp-buffer-window’ so that I can use
> ‘temp-buffer-resize-mode’ on it.

With its standard-output binding, with-temp-buffer-window is a kind of 
weird beast. Why would I prefer to use the low-level printing 
primitives, instead of `insert'?

Otherwise, I'd be happy to make temp-buffer-resize-mode work. But 
anyway, it seems orthogonal to my question: after *xref* is displayed 
already, how do I show locations from it?

 > By default *xref* would be shown at
 > the bottom of the frame with columns arranged as in the *Completions*
 > buffer.

xref's output is tree-like. It seems hard to arrange it in multiple columns.

What if the original window is already at the bottom of the frame? And, 
say, isn't tall enough to split?

> Conceptually, this should allow to split the "original" window into two
> side-by-side windows where the left one would continue to display the
> original buffer and the right one would display the buffer chosen by
> ‘xref-find-definitions-other-window’.  If there's already another window
> on the side of the original window, that window would be reused by
> ‘xref-find-definitions-other-window’.

How will this happen?

> Obviously, if the frame is too narrow, splitting will fail and the
> buffer will be shown in the original window.  But, as mentioned above,
> there's nothing you can do about this.  The doc-string of
> ‘xref-find-definitions-other-window’ should probably mention it.

I imagine then the user might expect it to be shown above or below the 
original window. Won't they?

> And ‘xref-find-definitions’ would display its buffer in the original
> window above the *xref* window.

Yes, displaying the buffers in the original window is not hard, we just 
have to save a reference to it (although it'd be bad if the user 
switches to *xref* in that window manually).

Re: xref and displaying locations in appropriate window or frame

[martin rudalics]

 > With its standard-output binding, with-temp-buffer-window is a kind of
 > weird beast. Why would I prefer to use the low-level printing
 > primitives, instead of `insert'?

Ignore ‘standard-output’.  The only important thing to know is that
‘with-temp-buffer-window’ initially erases the buffer it displays, so
you have to ‘insert’ within BODY and never before.

 > Otherwise, I'd be happy to make temp-buffer-resize-mode work. But
 > anyway, it seems orthogonal to my question: after *xref* is displayed
 > already, how do I show locations from it?

Currently the *xref* window occupies one half of my screen and usually
wastes lots of screen space.  So making it smaller should give users
more space for the buffers they eventually want to show.

 >  > By default *xref* would be shown at
 >  > the bottom of the frame with columns arranged as in the *Completions*
 >  > buffer.
 >
 > xref's output is tree-like. It seems hard to arrange it in multiple columns.

I thought it's forest-like.  If it's really tree-like then rotating it
will be probably hard :-(

 > What if the original window is already at the bottom of the frame?
 > And, say, isn't tall enough to split?

Then *xref* will reuse the window on the top that cannot be resized and
we lose.  I wonder whether this happens often with the *Completions*
window though.

 >> Conceptually, this should allow to split the "original" window into two
 >> side-by-side windows where the left one would continue to display the
 >> original buffer and the right one would display the buffer chosen by
 >> ‘xref-find-definitions-other-window’.  If there's already another window
 >> on the side of the original window, that window would be reused by
 >> ‘xref-find-definitions-other-window’.
 >
 > How will this happen?

With a wide window, ‘split-window-sensibly’ will probably try to split
that window into two side-by-side windows based on the assumption that
it didn't do so before when displaying *xref* (that's why I would try to
display *xref* on the bottom).  As for the "not reusing the original
window part" this will happen only if the original window is not the
larger one.  So you would have to temporarily select the original window
in the ‘xref-find-definitions-other-window’ call.  Not nice, but I see
no better choice.  You could also temporarily dedicate the original
window to its buffer.  Not nice either.

 >> Obviously, if the frame is too narrow, splitting will fail and the
 >> buffer will be shown in the original window.  But, as mentioned above,
 >> there's nothing you can do about this.  The doc-string of
 >> ‘xref-find-definitions-other-window’ should probably mention it.
 >
 > I imagine then the user might expect it to be shown above or below the
 > original window. Won't they?

How would we do that?  We have already two vertically stacked windows -
the original one and the *xref* window.  As a rule, ‘display-buffer’
refuses to make a third window.  The default of ‘split-height-threshold’
is 80 and we usually start with a total root window height of 34.  I
asked a couple of times whether this makes any sense but nobody cared.

Now obviously you can use ‘display-buffer-overriding-action’.  But the
idea of ‘display-buffer’ based functions is to give users the necessary
means to tweak the behavior to their working environment (display size,
frame/window preferences, maximized/normal-sized frames, etc.).  So you
want to have a good reason for overriding the user.

 > Yes, displaying the buffers in the original window is not hard, we
 > just have to save a reference to it (although it'd be bad if the user
 > switches to *xref* in that window manually).

Why would she want to do that if you keep *xref* visible as long as it's
needed?  If the *xref* window is gone, the user should never switch to
*xref* manually but ask you to redisplay it.

Note: Everything I wrote here is based on your initial assumption to
keep *xref* visible all the time.  If you don't do that, the three
windows rule doesn't apply and you shouldn't have any of the problems I
cited.

martin

Re: xref and displaying locations in appropriate window or frame

[martin rudalics]

 > As for the "not reusing the original
 > window part" this will happen only if the original window is not the
 > larger one.

Silly me.  Reusing goess for the LRU window, so the problem happens when
the original window is the LRU one.  After displaying one buffer in the
other window the original window usually is the LRU one, so the rest of
the paragraph should apply as is.

martin

Re: xref and displaying locations in appropriate window or frame

[Dmitry Gutov]

On 01/24/2016 05:38 PM, martin rudalics wrote:

> Ignore ‘standard-output’.  The only important thing to know is that
> ‘with-temp-buffer-window’ initially erases the buffer it displays, so
> you have to ‘insert’ within BODY and never before.

That doesn't seem to be true. Try:

(with-temp-buffer-window "test" t nil
   (insert "abc"))

It shows the buffer "test" empty, and "abc" gets inserted into the 
buffer that was current before with-temp-buffer-window call.

> Currently the *xref* window occupies one half of my screen and usually
> wastes lots of screen space.  So making it smaller should give users
> more space for the buffers they eventually want to show.

Yup. That's about temp-buffer-resize-mode. But it seems orthogonal to 
the problem I currently have.

> I thought it's forest-like.  If it's really tree-like then rotating it
> will be probably hard :-(

Anyway, IME most lines in xref take more than half of its width (which 
is ~110 here). So rearranging them wouldn't help much.

>  > What if the original window is already at the bottom of the frame?
>  > And, say, isn't tall enough to split?
>
> Then *xref* will reuse the window on the top that cannot be resized and
> we lose.  I wonder whether this happens often with the *Completions*
> window though.

The current issue is that people want *xref* to behave less like 
*Completions* (transient, disappearing soon) and more like 
*Compilation*, which stays until the user explicitly buries it or kills 
it or its window.

That may be not ideal for xref-find-definitions, but it seems more 
appropriate for all other commands using the xref UI.

> With a wide window, ‘split-window-sensibly’ will probably try to split
> that window into two side-by-side windows based on the assumption that
> it didn't do so before when displaying *xref* (that's why I would try to
> display *xref* on the bottom).  As for the "not reusing the original
> window part" this will happen only if the original window is not the
> larger one.  So you would have to temporarily select the original window
> in the ‘xref-find-definitions-other-window’ call.  Not nice, but I see
> no better choice.  You could also temporarily dedicate the original
> window to its buffer.  Not nice either.

I think I need to "not reuse the original window", nor xref's window. 
And reusing the original window is more preferable than reusing the 
xref's window.

Can I make xref's window temporarily dedicated, and call pop-to-buffer 
from the original window?

> How would we do that?  We have already two vertically stacked windows -
> the original one and the *xref* window.  As a rule, ‘display-buffer’
> refuses to make a third window.  The default of ‘split-height-threshold’
> is 80 and we usually start with a total root window height of 34.

So if the frame is too narrow, and there are two windows only, the 
location will be displayed in the original window? OK, that should be fine.

> I asked a couple of times whether this makes any sense but nobody cared.

What makes sense? Having a split threshold? I think it does. Beyond 
that, I'd say window management might be too complex for a casual 
commenter to say whether it makes sense or not.

> Now obviously you can use ‘display-buffer-overriding-action’.  But the
> idea of ‘display-buffer’ based functions is to give users the necessary
> means to tweak the behavior to their working environment (display size,
> frame/window preferences, maximized/normal-sized frames, etc.).  So you
> want to have a good reason for overriding the user.

Right. I really want to use the standard behavior as much as possible.

>  > Yes, displaying the buffers in the original window is not hard, we
>  > just have to save a reference to it (although it'd be bad if the user
>  > switches to *xref* in that window manually).
>
> Why would she want to do that if you keep *xref* visible as long as it's
> needed?  If the *xref* window is gone, the user should never switch to
> *xref* manually but ask you to redisplay it.

They can press `q', but then switch back to it a while later. I see no 
reason to prohibit this.

Do we prohibit things like that in some other buffers?

> Note: Everything I wrote here is based on your initial assumption to
> keep *xref* visible all the time.  If you don't do that, the three
> windows rule doesn't apply and you shouldn't have any of the problems I
> cited.

That is indeed the whole reason I've written the "I'm stumped" email.

Re: xref and displaying locations in appropriate window or frame

[martin rudalics]

 > That doesn't seem to be true. Try:
 >
 > (with-temp-buffer-window "test" t nil
 >    (insert "abc"))
 >

 > It shows the buffer "test" empty, and "abc" gets inserted into the
 > buffer that was current before with-temp-buffer-window call.

Because of "Do not make that buffer current for running the forms in
BODY."  You have to use ‘with-current-buffer’ around the ‘insert’.

 > Yup. That's about temp-buffer-resize-mode. But it seems orthogonal to
 > the problem I currently have.

Not entirely.  I'd make the *xref* window as small as possible so it
doesn't get split.  And I'd like to see it always at the same frame
position.

 > Anyway, IME most lines in xref take more than half of its width (which
 > is ~110 here). So rearranging them wouldn't help much.

With a maximized frame I get 200 columns here.  Anyway.  Don't bother
about laying out its contents.  But here usually the *xref* buffer never
occupies its full _height_.  That's where ‘temp-buffer-resize-mode’
would come in handy.

 > The current issue is that people want *xref* to behave less like
 > *Completions* (transient, disappearing soon) and more like
 > *Compilation*, which stays until the user explicitly buries it or
 > kills it or its window.

This should be of no importance.  Help windows are also displayed via
‘with-temp-buffer-window’ and don't disappear soon.  Some people keep
the help window open all the time.  The IMHO important aspect is that
*Completions* uses ‘display-buffer-at-bottom’ which calls plain
‘split-window’ and thus is not limited by ‘split-height-threshold’.  You
can obviously use ‘display-buffer-at-bottom’ with plain ‘display-buffer’
as well.  But then ‘temp-buffer-resize-mode’ won't get called.

 > I think I need to "not reuse the original window", nor xref's
 > window. And reusing the original window is more preferable than
 > reusing the xref's window.

That's my understanding as well.

 > Can I make xref's window temporarily dedicated, and call pop-to-buffer
 > from the original window?

Yes.  But the one-window-per-frame user might get a new frame then.
She's not your target (because of the assumption that the original
window and the *xref* window are already there when you want to display
the other buffer).  But even softly (that's all you need here) dedicated
windows sometimes behave erratically.

 > So if the frame is too narrow, and there are two windows only, the
 > location will be displayed in the original window? OK, that should be
 > fine.

If the other window is the *xref* window and the *xref* window was
"used" later.  You might have to "touch" it from time to time ;-)

 >> I asked a couple of times whether this makes any sense but nobody cared.
 >
 > What makes sense? Having a split threshold? I think it does. Beyond
 > that, I'd say window management might be too complex for a casual
 > commenter to say whether it makes sense or not.

A threshold that is more than twice as large as the default value?

 >> Why would she want to do that if you keep *xref* visible as long as it's
 >> needed?  If the *xref* window is gone, the user should never switch to
 >> *xref* manually but ask you to redisplay it.
 >
 > They can press `q', but then switch back to it a while later. I see no
 > reason to prohibit this.

Neither do I.  But in a sense this is a bit like an ediff user deleting
the control panel and switching back to it later.  The ideal layout may
have gone at that time.

 > Do we prohibit things like that in some other buffers?

Not to my knowledge.  I just wouldn't call it good user practice.  For
example, switching to *Help* in an arbitrary window and doing
‘quit-window’ there is not likely producing good results.  The same will
hold for ‘q’ in a window where you manually switched to *xref*.  Maybe
some command to "bring back" the *xref* buffer would be more useful than
simply switching to it.

martin

Re: xref and displaying locations in appropriate window or frame

[Dmitry Gutov]

On 01/24/2016 09:12 PM, martin rudalics wrote:

> Because of "Do not make that buffer current for running the forms in
> BODY."  You have to use ‘with-current-buffer’ around the ‘insert’.

Could we decouple temp-buffer-resize-mode from the "write to 
standard-output" mode of operation? Can I just call 
resize-temp-buffer-window once after the xref buffer is displayed?

>  > Yup. That's about temp-buffer-resize-mode. But it seems orthogonal to
>  > the problem I currently have.
>
> Not entirely.  I'd make the *xref* window as small as possible so it
> doesn't get split.

If won't make any difference if *xref* is tall enough (like when we 
display Grep results in it).

And anyway, *xref* window getting split is not a problem, as far as I'm 
concerned. Keeping *xref* buffer visible is the goal.

 > And I'd like to see it always at the same frame position.

Maybe the actual solution is indeed to use a different display mechanism 
for xref-find-definitions with several options. Then it could use an 
actual temporary electric window at the bottom of the current window 
that gets deleted as soon as we're done.

>  > Anyway, IME most lines in xref take more than half of its width (which
>  > is ~110 here). So rearranging them wouldn't help much.
>
> With a maximized frame I get 200 columns here.  Anyway.  Don't bother
> about laying out its contents.

I get ~230, but the first thing I do is a side-by-side split. :) While 
we can do space-saving layout in *Completions*, most buffers, like 
file-visiting ones, don't have that luxury anyway.

> But here usually the *xref* buffer never
> occupies its full _height_.

It might, if you call xref-find-references, or project-find-regexp, 
depending on what you're searching for.

>  > The current issue is that people want *xref* to behave less like
>  > *Completions* (transient, disappearing soon) and more like
>  > *Compilation*, which stays until the user explicitly buries it or
>  > kills it or its window.
>
> This should be of no importance.

We don't use temp-buffer-resize-mode in Compilation or Grep buffers, 
right? Even though Grep likewise might return only a few matches.

> Help windows are also displayed via
> ‘with-temp-buffer-window’ and don't disappear soon.  Some people keep
> the help window open all the time.

Were the Help windows actually _temporary_ sometime?

> The IMHO important aspect is that
> *Completions* uses ‘display-buffer-at-bottom’ which calls plain
> ‘split-window’ and thus is not limited by ‘split-height-threshold’.  You
> can obviously use ‘display-buffer-at-bottom’ with plain ‘display-buffer’
> as well.  But then ‘temp-buffer-resize-mode’ won't get called.

I don't know if it's that important. Also consider this:

If I have a frame with two full-height windows side-by-side, and I'm 
calling project-find-regexp which returns a lot of results, I'd want it 
to be displayed in the "other" window, rather than necessarily split the 
current one.

Or, if I have just one window in a maximized frame, and do the search, 
and I've customized the split thresholds appropriately, I want 
split-window-right to be called, and see *xref* to the right.

Instead of having the "split below" performed, and seeing *xref* use 
full width, and only half the height of the current frame.

>  > Can I make xref's window temporarily dedicated, and call pop-to-buffer
>  > from the original window?
>
> Yes.  But the one-window-per-frame user might get a new frame then.
> She's not your target (because of the assumption that the original
> window and the *xref* window are already there when you want to display
> the other buffer).

Wouldn't she want a new frame anyway?

> But even softly (that's all you need here) dedicated
> windows sometimes behave erratically.

Can we fix that? So far using dedicated buffers sounds like the most 
appropriate solution.

>  > So if the frame is too narrow, and there are two windows only, the
>  > location will be displayed in the original window? OK, that should be
>  > fine.
>
> If the other window is the *xref* window and the *xref* window was
> "used" later.  You might have to "touch" it from time to time ;-)

That doesn't sound like something a display-buffer consumer should do. 
Should it?

> A threshold that is more than twice as large as the default value?

(frame-height) evaluates to 58 here.

Maybe it does make sense, maybe it doesn't. I'm fine with it, though, 
because I don't mind doing doing my vertical splits manually.

>  >> Why would she want to do that if you keep *xref* visible as long as
> it's
>  >> needed?  If the *xref* window is gone, the user should never switch to
>  >> *xref* manually but ask you to redisplay it.
>  >
>  > They can press `q', but then switch back to it a while later. I see no
>  > reason to prohibit this.
>
> Neither do I.  But in a sense this is a bit like an ediff user deleting
> the control panel and switching back to it later.  The ideal layout may
> have gone at that time.

But *Grep* works fine in that situation, doesn't it?

>  > Do we prohibit things like that in some other buffers?
>
> Not to my knowledge.  I just wouldn't call it good user practice.  For
> example, switching to *Help* in an arbitrary window and doing
> ‘quit-window’ there is not likely producing good results.  The same will
> hold for ‘q’ in a window where you manually switched to *xref*.

quit-window is different, and it works as expected anyway, I'd say: if 
the window configuration hasn't changed too much, it will undo the 
action that displayed it. If the window configuration did change too 
much, it will just bury the current buffer. Everybody happy.

> Maybe
> some command to "bring back" the *xref* buffer would be more useful than
> simply switching to it.

I can easily imagine having several *xref* buffers at the same time 
(we'll just have to add more coherent naming).

Re: xref and displaying locations in appropriate window or frame

[martin rudalics]

 > Could we decouple temp-buffer-resize-mode from the "write to
 > standard-output" mode of operation? Can I just call
 > resize-temp-buffer-window once after the xref buffer is displayed?

Hopefully.  Just add

(when temp-buffer-resize-mode (resize-temp-buffer-window window))

at some suitable place.

 > If won't make any difference if *xref* is tall enough (like when we
 > display Grep results in it).

If the *xref* buffer usually fills its window in both dimensions there's
no need to do anything.

 > And anyway, *xref* window getting split is not a problem, as far as
 > I'm concerned. Keeping *xref* buffer visible is the goal.

So the main problem is that showing the target buffer uses the *xref*
window and you want to avoid that.  In the following let's assume that
"O" is the originally selected window, "X" is the *xref* window, "T" is
the target window that shows the defined object and "N" is some other
non-selected window.

Suppose O is the sole window on its frame.  In a "vertically oriented"
frame you would go from

  -----
|  O  |
|     |
|     |
|     |
|     |
  -----

via

  -----
|  O  |
|     |
|     |
|-----|
|  X  |
  -----

to

  -----
|  O  |
|-----|
|  T  |
|-----|
|  X  |
  -----

and subsequently T should be reused for the remaining targets.  This
will work when the user has customized ‘split-height-threshold’
appropriately - otherwise O will be used for showing T.

In a "horizontally" orientd frame you would go from

  ------------
|     O      |
|            |
|            |
|            |
  ------------

via

  ------------
|     O      |
|            |
|------------|
|     X      |
  ------------

to

  ------------
|  O  |   T  |
|     |      |
|------------|
|     X      |
  ------------

This will usually work with the default ‘split-width-threshold’,
otherwise O gets used for showing T.

Now suppose that both O and N exist.  In this case you would, in the
vertically oriented case, go from

  -----
|  O  |
|     |
|-----|
|  N  |
|     |
  -----

via

  -----
|  O  |
|-----|
|  N  |
|-----|
|  X  |
  -----

to

  -----
|  O  |
|-----|
|  T  |
|-----|
|  X  |
  -----

Horizontally from

  ------------
|  O  |   N  |
|     |      |
|     |      |
|     |      |
  ------------

via

  ------------
|  O  |   N  |
|     |      |
|------------|
|     X      |
  ------------

to

  ------------
|  O  |   T  |
|     |      |
|------------|
|     X      |
  ------------

One tricky case is to set up X when O and N exist already.  If you reuse
N for showing X you will find it difficult to subsequently show T
without reusing X.  That's why I would try to always create a new,
hopefully smaller, window for X.

The second tricky case is to make sure that for a new target always the
previous T window gets used via ‘display-buffer-use-some-window’.  To
make this happen you will either have to mark the O and X windows as
dedicated or make sure the T window is the LRU window when displaying
the next target.  (I silently assumed that N will be automatically used
for displaying T initially because O was selected and X would have to be
selected by you when it's created.)

Hopefully, this covers the most common cases we will see in the wild.

 > Maybe the actual solution is indeed to use a different display
 > mechanism for xref-find-definitions with several options. Then it
 > could use an actual temporary electric window at the bottom of the
 > current window that gets deleted as soon as we're done.

At least that's how I would customize the display of *xref*.  Whatever
you choose for the default might be entirely different based on the
needs of a majority of users.

 > We don't use temp-buffer-resize-mode in Compilation or Grep buffers,
 > right? Even though Grep likewise might return only a few matches.

IIUC these buffers get filled asynchronously.  How should
‘temp-buffer-resize-mode’ work with such buffers?  Do you produce *xref*
asynchronously?

 > Were the Help windows actually _temporary_ sometime?

Depends on the semantics of "temporary".

 > If I have a frame with two full-height windows side-by-side, and I'm
 > calling project-find-regexp which returns a lot of results, I'd want
 > it to be displayed in the "other" window, rather than necessarily
 > split the current one.

I thought the other window is where you eventually wanted to show the
target buffer.

 > Or, if I have just one window in a maximized frame, and do the search,
 > and I've customized the split thresholds appropriately, I want
 > split-window-right to be called, and see *xref* to the right.

Once more: Where would you show the target buffer then?  I think what
you say makes perfect sense in a setup where the *xref* buffer is
replaced by the target buffer.  But we're talking about the scenario
where the *xref* buffer should remain visible after displaying the
target buffer.

 > Instead of having the "split below" performed, and seeing *xref* use
 > full width, and only half the height of the current frame.

Hopefully less than half the height when you fit the window to its
buffer.

 >> Yes.  But the one-window-per-frame user might get a new frame then.
 >> She's not your target (because of the assumption that the original
 >> window and the *xref* window are already there when you want to display
 >> the other buffer).
 >
 > Wouldn't she want a new frame anyway?

I thought about people who work with one and only one window.  We
shouldn't create a no-way-out situation for them.

 >> But even softly (that's all you need here) dedicated
 >> windows sometimes behave erratically.
 >
 > Can we fix that? So far using dedicated buffers sounds like the most
 > appropriate solution.

One problem with dedicated windows is that if an application and the
user both start dedicating the same window to its buffer there might be
conflicts.  I doubt that such conflicts can be "fixed" easily.

 >> If the other window is the *xref* window and the *xref* window was
 >> "used" later.  You might have to "touch" it from time to time ;-)
 >
 > That doesn't sound like something a display-buffer consumer should
 > do. Should it?

It's a hack, indeed.

 >> A threshold that is more than twice as large as the default value?
 >
 > (frame-height) evaluates to 58 here.

Less than 80, still.

 > Maybe it does make sense, maybe it doesn't. I'm fine with it, though,
 > because I don't mind doing doing my vertical splits manually.

‘display-buffer’ can't split it.  The very first example above will work
only if the user has customized ‘split-height-threshold’.  Otherwise, T
will be shown in the O window.

 > But *Grep* works fine in that situation, doesn't it?

I never use it.  My grep hits appear in a side window where I just list
the files where at least one hit occurred.  Selecting a file shows all
hits in that file.  Selecting a particular hit shows that hit in the
window on the right.

 > quit-window is different, and it works as expected anyway, I'd say: if
 > the window configuration hasn't changed too much, it will undo the
 > action that displayed it. If the window configuration did change too
 > much, it will just bury the current buffer. Everybody happy.

Did you try it after manually switching to such a buffer?

 >> Maybe
 >> some command to "bring back" the *xref* buffer would be more useful than
 >> simply switching to it.
 >
 > I can easily imagine having several *xref* buffers at the same time
 > (we'll just have to add more coherent naming).

Then I'd say: Maybe some prefixed command to "bring back" an existing
*xref* buffer would be more useful than simply switching to it.

martin

Re: xref and displaying locations in appropriate window or frame

[Dmitry Gutov]

On 01/25/2016 12:50 PM, martin rudalics wrote:

> If the *xref* buffer usually fills its window in both dimensions there's
> no need to do anything.

Usually or not, depends on which commands you use, and what you search 
for. Probably not most of the time.

>   -----
> |  O  |
> |-----|
> |  T  |
> |-----|
> |  X  |
>   -----
>
> and subsequently T should be reused for the remaining targets.  This
> will work when the user has customized ‘split-height-threshold’
> appropriately - otherwise O will be used for showing T.

That's fine.

> In a "horizontally" orientd frame you would go from
>
>   ------------
> |     O      |
> |            |
> |            |
> |            |
>   ------------
>
> via
>
>   ------------
> |     O      |
> |            |
> |------------|
> |     X      |
>   ------------

That's not so fine: I'd prefer to go to

   ------------
  |  O  |   X  |
  |     |      |
  |     |      |
  |     |      |
   ------------

at this step instead. Which is how Emacs normally allocates windows.

Note the benefit: as long as the contents of O fit in its width (no 
exceedingly-long lines), we get to see more of its contents.

Ideally, on the next step we get a layout like this:

  ------------
|   O |   X  |
|     |------|
|     |      |
|     |   T  |
  ------------

But I can live with O being split instead.

Having X in the split below O might be even better (giving T a 
full-height window), but I don't see a easy way to that configuration.

Note, however, that from the X-below-O configuration I quoted above you 
can't each either of the good target configurations.

> to
>
>   ------------
> |  O  |   T  |
> |     |      |
> |------------|
> |     X      |
>   ------------

This would be a waste of space on the right side of X.

> Now suppose that both O and N exist.  In this case you would, in the
> vertically oriented case, go from
>
>   -----
> |  O  |
> |     |
> |-----|
> |  N  |
> |     |
>   -----
>
> via
>
>   -----
> |  O  |
> |-----|
> |  N  |
> |-----|
> |  X  |
>   -----
>
> to
>
>   -----
> |  O  |
> |-----|
> |  T  |
> |-----|
> |  X  |
>   -----

This is also fine.

> The second tricky case is to make sure that for a new target always the
> previous T window gets used via ‘display-buffer-use-some-window’.  To
> make this happen you will either have to mark the O and X windows as
> dedicated or make sure the T window is the LRU window when displaying
> the next target.  (I silently assumed that N will be automatically used
> for displaying T initially because O was selected and X would have to be
> selected by you when it's created.)

Dedicated it is, then.

>  > Maybe the actual solution is indeed to use a different display
>  > mechanism for xref-find-definitions with several options. Then it
>  > could use an actual temporary electric window at the bottom of the
>  > current window that gets deleted as soon as we're done.
>
> At least that's how I would customize the display of *xref*.  Whatever
> you choose for the default might be entirely different based on the
> needs of a majority of users.

Unless someone would like to send a patch, I'll hold off on implementing 
this, because we've not really stabilized on anything, including the 
calling convention of xref-show-xrefs-function.

And the above feature would be closely related to that variable.

>  > We don't use temp-buffer-resize-mode in Compilation or Grep buffers,
>  > right? Even though Grep likewise might return only a few matches.
>
> IIUC these buffers get filled asynchronously.  How should
> ‘temp-buffer-resize-mode’ work with such buffers?

Resize after every bit of output? Admittedly, it can be annoying.

> Do you produce *xref* asynchronously?

Not yet, we I hope we manage to do that. Only working synchronously is 
one of its drawbacks compared to Grep.

>  > Were the Help windows actually _temporary_ sometime?
>
> Depends on the semantics of "temporary".

I'd only call that a window that usually disappears before the next 
command. But that's just me.

>  > If I have a frame with two full-height windows side-by-side, and I'm
>  > calling project-find-regexp which returns a lot of results, I'd want
>  > it to be displayed in the "other" window, rather than necessarily
>  > split the current one.
>
> I thought the other window is where you eventually wanted to show the
> target buffer.

I don't think that when the user calls any other-window command, they 
have a specific window in mind (for that, they'd have to know the window 
numbering somehow). IMHO, -other-window just means "some other window in 
the current frame".

>  > Or, if I have just one window in a maximized frame, and do the search,
>  > and I've customized the split thresholds appropriately, I want
>  > split-window-right to be called, and see *xref* to the right.
>
> Once more: Where would you show the target buffer then?

We'd split one of the windows again and show the target buffer in the 
new window. See my diagram at the beginning of this email.

>  > Instead of having the "split below" performed, and seeing *xref* use
>  > full width, and only half the height of the current frame.
>
> Hopefully less than half the height when you fit the window to its
> buffer.

Like mentioned, xref's contents can be long (even if they usually 
aren't, in xref-find-definitions output).

>  >> Yes.  But the one-window-per-frame user might get a new frame then.
>  >> She's not your target (because of the assumption that the original
>  >> window and the *xref* window are already there when you want to display
>  >> the other buffer).
>  >
>  > Wouldn't she want a new frame anyway?
>
> I thought about people who work with one and only one window.  We
> shouldn't create a no-way-out situation for them.

I'm accepting suggestions on what to do in this case. We should handle 
the more common ones first, however.

> One problem with dedicated windows is that if an application and the
> user both start dedicating the same window to its buffer there might be
> conflicts.  I doubt that such conflicts can be "fixed" easily.

So, then problem will occur when I un-dedicate it at the end, in 
unwind-protect? I suppose I can save its dedication status, and then 
restore it.

>  > Maybe it does make sense, maybe it doesn't. I'm fine with it, though,
>  > because I don't mind doing doing my vertical splits manually.
>
> ‘display-buffer’ can't split it.  The very first example above will work
> only if the user has customized ‘split-height-threshold’.  Otherwise, T
> will be shown in the O window.

Indeed. Anyway, I'd be fine with changing the default, as long as 
side-by-side splits are still preferred.

>  > But *Grep* works fine in that situation, doesn't it?
>
> I never use it.  My grep hits appear in a side window where I just list
> the files where at least one hit occurred.  Selecting a file shows all
> hits in that file.  Selecting a particular hit shows that hit in the
> window on the right.

All right, *Compilation*, then?

(I'm not too enamored with your description of Grep solution--too many 
steps--but that's beside the point.)

>  > quit-window is different, and it works as expected anyway, I'd say: if
>  > the window configuration hasn't changed too much, it will undo the
>  > action that displayed it. If the window configuration did change too
>  > much, it will just bury the current buffer. Everybody happy.
>
> Did you try it after manually switching to such a buffer?

Yes. Like I said, when I switch to it manually and press `q', it just 
buries the Help buffer. Is there a particular problem scenario you have 
in mind?

>  > I can easily imagine having several *xref* buffers at the same time
>  > (we'll just have to add more coherent naming).
>
> Then I'd say: Maybe some prefixed command to "bring back" an existing
> *xref* buffer would be more useful than simply switching to it.

IMHO, the users won't bother, and will either switch to that buffer 
manually, or just repeat the search.

Re: xref and displaying locations in appropriate window or frame

[martin rudalics]

 >>   ------------
 >> |     O      |
 >> |            |
 >> |------------|
 >> |     X      |
 >>   ------------
 >
 > That's not so fine: I'd prefer to go to
 >
 >    ------------
 >   |  O  |   X  |
 >   |     |      |
 >   |     |      |
 >   |     |      |
 >    ------------
 >
 > at this step instead. Which is how Emacs normally allocates windows.
 >
 > Note the benefit: as long as the contents of O fit in its width (no exceedingly-long lines), we get to see more of its contents.
 >
 > Ideally, on the next step we get a layout like this:
 >
 >   ------------
 > |   O |   X  |
 > |     |------|
 > |     |      |
 > |     |   T  |
 >   ------------

This is no good layout for IDEs.  Source/code windows like O and T
should always form a rectangle.  Auxiliary windows like X should be
arranged around that rectangle.  And obviously it precludes fitting
*xref* to its buffer width.  A window fit to its buffer should never
impose its width/height on other windows.

 > But I can live with O being split instead.

This would nullify the above benefit.  In any case the larger of the two
windows will be split.

 > Having X in the split below O might be even better (giving T a
 > full-height window), but I don't see a easy way to that configuration.

Neither do I.

 > Note, however, that from the X-below-O configuration I quoted above
 > you can't each either of the good target configurations.

You could split the parent window of O and X.

 >> to
 >>
 >>   ------------
 >> |  O  |   T  |
 >> |     |      |
 >> |------------|
 >> |     X      |
 >>   ------------
 >
 > This would be a waste of space on the right side of X.

When X has short lines it could be shown on the left of O like this.

  -----------------
|X|   O   |   T   |
| |       |       |
| |       |       |
| |       |       |
| |       |       |
  -----------------

 >> IIUC these buffers get filled asynchronously.  How should
 >> ‘temp-buffer-resize-mode’ work with such buffers?
 >
 > Resize after every bit of output? Admittedly, it can be annoying.

Very.

 >> Do you produce *xref* asynchronously?
 >
 > Not yet, we I hope we manage to do that. Only working synchronously is
 > one of its drawbacks compared to Grep.

Then ‘fit-window-to-buffer’ will be moot anyway.

 > We'd split one of the windows again and show the target buffer in the
 > new window. See my diagram at the beginning of this email.

Then we're back at the initial problem that by default Emacs never shows
more than two windows on a frame :-(

 >> One problem with dedicated windows is that if an application and the
 >> user both start dedicating the same window to its buffer there might be
 >> conflicts.  I doubt that such conflicts can be "fixed" easily.
 >
 > So, then problem will occur when I un-dedicate it at the end, in
 > unwind-protect? I suppose I can save its dedication status, and then
 > restore it.

Right.  I doubt you can do any better.  But do it.

 > Indeed. Anyway, I'd be fine with changing the default, as long as
 > side-by-side splits are still preferred.

It always depends on the size and shape of your frame.

 > All right, *Compilation*, then?

IIRC the original question was where *Grep* and *Compilation* display
their targets.  Here I practically always create a new window.  But by
default the target will be usually displayed in the original window, the
one selected at the time you called grep or compile.

 > (I'm not too enamored with your description of Grep solution--too many
 > steps--but that's beside the point.)

I prefer the first step rather than being overwhelmed by too many hits
with too much information.  And the second step is the same I use for
plain searching in buffers.

 > Yes. Like I said, when I switch to it manually and press `q', it just
 > buries the Help buffer. Is there a particular problem scenario you
 > have in mind?

No.  I'm always glad if it works as intended.

 > IMHO, the users won't bother, and will either switch to that buffer
 > manually, or just repeat the search.

So let's not prevent them from doing that ;-)

martin

Re: xref and displaying locations in appropriate window or frame

[Ingo Lohmar]

This is an important discussion, and unfortunately I currently have too
little time left to follow the details.  So feel free to ignore this
message if it's besides the point.  But anyway...

On Mon, Jan 25 2016 19:18 (+0100), martin rudalics wrote:
> >   ------------
> > |   O |   X  |
> > |     |------|
> > |     |      |
> > |     |   T  |
> >   ------------

> This is no good layout for IDEs.  Source/code windows like O and T
> should always form a rectangle.  Auxiliary windows like X should be
> arranged around that rectangle.

FWIW, I love the overall direction of extending Emacs' IDE-related
facilities, *but* I do not think that it should strive to emulate all
their behavior, particularly not in this respect.  AFAICT, you have not
given any argument for *why* these should be guidelines for a window
layout, except that IDEs do it that way.

I regularly curse at the braindead window management of any IDE I have
had to work with so far.  Emacs shines in the flexibility with which I
can use all its features the way *I* want, and with the window layout I
deem suitable.  And for me, that's literally *never* a rectangular area
for source files.  In the above example, I find the displayed window
layout not only acceptable, but perfectly fine, just like
 ------------
|   T |   X  |
|     |------|
|     |      |
|     |   O  |
 ------------
would be fine for me (not as a result of the described workflow, but as
a layout resulting from any kind of workflow).

I think that it would be more useful if the present elaborate window
management would become more accessible (maybe it's only a matter of
documentation and a few variable settings) to fix a certain layout (or
layout-related guidelines like you described) *should the user want
that*.  Wouldn't this eliminate most of the need to code such decisions
into very general features like xref?

Ingo

Re: xref and displaying locations in appropriate window or frame

[martin rudalics]

 >>>    ------------
 >>> |   O |   X  |
 >>> |     |------|
 >>> |     |      |
 >>> |     |   T  |
 >>>    ------------
 >
 >> This is no good layout for IDEs.  Source/code windows like O and T
 >> should always form a rectangle.  Auxiliary windows like X should be
 >> arranged around that rectangle.
 >
 > FWIW, I love the overall direction of extending Emacs' IDE-related
 > facilities, *but* I do not think that it should strive to emulate all
 > their behavior, particularly not in this respect.  AFAICT, you have not
 > given any argument for *why* these should be guidelines for a window
 > layout, except that IDEs do it that way.

I'm no expert in IDEs, I don't use them and I don't advocate their
concepts.  So I'm certainly not qualified to give you an adequate
response.  Anyway.

Years ago proposals were made how to turn Emacs into an IDE.  You will
find a remnant in the

   Perspectives work well even if you do the equivalent of C-x 4 C-f
   because of the distinction between view windows vs file windows.  In
   Emacs this is more or less the "dedicated window" feature, but we have
   never really made it work for this.

entry of etc/TODO.  Now first we have to agree that in our example above
O and T behave as "file windows" and X is a "view window".  ECB calls
view windows "informational windows".  Emacs-IDE IIUC calls file windows
"source window" and subdivides view windows into "menu windows" and
"output windows".  I'm not sure whether X would classify as a menu or
output window, maybe it's both.  In any case X is not a source window.

Keeping file and view windows in a way that file windows form an inner
rectangular area and view windows are arranged around that area has the
following advantages:

- View windows can be easily made persistent (which is what the current
   thread is about).  Creating a file window does not remove them.
   Displaying a buffer in an existing file window does not affect them.

- View windows can be arranged in a predictable way so that the user
   always finds them in a specified part of the frame.  Compare this with
   the placement of X in the horizontal and vertical variations of our
   example.

- Most IDEs implicitly dedicate view windows to their buffers.  So we
   would not have to worry about how to do that with our X window.

- Orthogonally to the before, view windows can be shared by different
   but related buffers in a predictable way.  This means that you can
   switch view windows' buffers en bloc when switching, for example, from
   editing to debugging mode and back.

- It's easy to switch from a navigational mode where you show view
   windows, to an editing mode where you expand the file windows area to
   fill the entire frame and back.  Try that with the layout on the top
   of this reply or your layout below.

- View windows can be easily arranged according to their orientation:
   Vertically oriented windows (like the speedbar, browsers for files,
   buffers, tags and bookmarks) on the left or right, horizontally
   oriented ones (like compilation output or the eshell window) at the
   top or bottom.  This minimizes space and is the reason why I asked
   about the orientation of the *xref* window.

- If you have at most one view window on each side of a frame, you can
   easily fit them to their buffers to additionally minimze space.
   Fitting windows in the file windows area is much more tricky and may
   have unwanted side-effects.

 > I regularly curse at the braindead window management of any IDE I have
 > had to work with so far.  Emacs shines in the flexibility with which I
 > can use all its features the way *I* want, and with the window layout I
 > deem suitable.  And for me, that's literally *never* a rectangular area
 > for source files.  In the above example, I find the displayed window
 > layout not only acceptable, but perfectly fine, just like
 >   ------------
 > |   T |   X  |
 > |     |------|
 > |     |      |
 > |     |   O  |
 >   ------------
 > would be fine for me (not as a result of the described workflow, but as
 > a layout resulting from any kind of workflow).

Just that such layout is quite tricky to set up.  You have to

(setq X (split-window O nil 'above))

followed by

(setq T (split-window (window-parent O) nil 'left))

Most Emacs developers wouldn't even know that such a possibility exist.

 > I think that it would be more useful if the present elaborate window
 > management would become more accessible (maybe it's only a matter of
 > documentation and a few variable settings) to fix a certain layout (or
 > layout-related guidelines like you described) *should the user want
 > that*.  Wouldn't this eliminate most of the need to code such decisions
 > into very general features like xref?

Personally, I prefer chaos.  So I usually split the selected window to
display a buffer and when my frame is crowded by too many small windows
I kill them off in one rush.  I certainly would not recommed this
practice to anyone.  So all I can do is to refer to layout decisions
that have been made and tested elsewhere.

martin

Re: xref and displaying locations in appropriate window or frame

[Dmitry Gutov]

On 01/26/2016 01:05 PM, martin rudalics wrote:

> Now first we have to agree that in our example above
> O and T behave as "file windows" and X is a "view window"...
>
> Keeping file and view windows in a way that file windows form an inner
> rectangular area and view windows are arranged around that area has the
> following advantages:
>
> - View windows can be easily made persistent...
> - View windows can be arranged in a predictable way so that the user
>    always finds them in a specified part of the frame.
> - Most IDEs implicitly dedicate view windows to their buffers.  So we
>    would not have to worry about how to do that with our X window.

First, I'd like to point out that your suggestion was to split the 
current window and display X in the bottom part of the split. Which, if 
there were, say, two side-by-side windows originally, wouldn't put X in 
any of "classical" areas designated for "view" windows by IDEs.

But suppose I misunderstood, and the end result would be putting X into 
a lower part of the frame, below all file windows. Which fits an average 
IDE fine, because they don't have side-by-side splits for file windows 
(let's keep to Emacs terminology here), so one can at least expect that 
a average line of code is more or less as long as the frame width. Maybe 
less, but probably longer that width/2.

Thus, a file search output will be just as wide, and one can't really do 
better that display it in a full-width window as well at the bottom. I'd 
say that would show too few lines, when my font of choice is used, but 
the IDEs seem to handle it fine somehow with their defaults.

That's not necessarily untrue in Emacs community, where we're often more 
conservative, and hold to 80-100 chars per line. Then, we can afford to 
put file windows side-by-side, and xref output (though not Grep, because 
it includes a file name on each line) is about the same width, so by 
putting it at the bottom we'll waste the right half of the "view windows 
area".

But I don't really have a better layout in mind, and different long-time 
users probably solve this question differently. So, really, the best I 
can do is use as much from the default window allocation strategy as I 
can, and hope that users with more exotic demands manage to override the 
given behavior to their satisfaction.

Re: xref and displaying locations in appropriate window or frame

[martin rudalics]

 > First, I'd like to point out that your suggestion was to split the
 > current window and display X in the bottom part of the split. Which,
 > if there were, say, two side-by-side windows originally, wouldn't put
 > X in any of "classical" areas designated for "view" windows by IDEs.

My suggestion was and is to display X at the bottom of the frame via
‘display-buffer-at-bottom’ like *Completions*.  So if there were, say,
two side-by-side windows originally, this would put X in a "classical"
area designated for "view" windows by IDEs.

 > But suppose I misunderstood, and the end result would be putting X
 > into a lower part of the frame, below all file windows. Which fits an
 > average IDE fine, because they don't have side-by-side splits for file
 > windows (let's keep to Emacs terminology here),

What makes you think that average IDEs don't have side-by-side splits
for file windows?  ECB has them IIRC.

 > so one can at least
 > expect that a average line of code is more or less as long as the
 > frame width. Maybe less, but probably longer that width/2.
 >
 > Thus, a file search output will be just as wide, and one can't really
 > do better that display it in a full-width window as well at the
 > bottom. I'd say that would show too few lines, when my font of choice
 > is used, but the IDEs seem to handle it fine somehow with their
 > defaults.

Yes.  Do you see any problems with that?

 > That's not necessarily untrue in Emacs community, where we're often
 > more conservative, and hold to 80-100 chars per line. Then, we can
 > afford to put file windows side-by-side,

... assuming your 229 columns wide frame, I suppose ...

 > and xref output (though not
 > Grep, because it includes a file name on each line) is about the same
 > width, so by putting it at the bottom we'll waste the right half of
 > the "view windows area".

Yes.  We're back at my inital proposal to give *xref* buffers a
multicolumn layout.

 > But I don't really have a better layout in mind, and different
 > long-time users probably solve this question differently. So, really,
 > the best I can do is use as much from the default window allocation
 > strategy as I can, and hope that users with more exotic demands manage
 > to override the given behavior to their satisfaction.

Let's see.

martin

Re: xref and displaying locations in appropriate window or frame

[Dmitry Gutov]

On 01/27/2016 12:10 PM, martin rudalics wrote:
> My suggestion was and is to display X at the bottom of the frame via
> ‘display-buffer-at-bottom’ like *Completions*.  So if there were, say,
> two side-by-side windows originally, this would put X in a "classical"
> area designated for "view" windows by IDEs.

I see. But that's an interesting comparison, because *completions* only 
seems to use display-buffer-at-bottom when you're typing in the 
minibuffer, but not when completion occurs in a file buffer. So It's 
only used when *completions* would appear above the place you're 
currently looking at.

> What makes you think that average IDEs don't have side-by-side splits
> for file windows?  ECB has them IIRC.

I've used the popular ones. ECB is just an Emacs extension, and a 
dormant one, at that.

IIRC, Intellij IDEA has added the capability to do side-by-side splits, 
but they're not used by most users, and you can't split the view window 
area anyway (and we can!).

>  > Thus, a file search output will be just as wide, and one can't really
>  > do better that display it in a full-width window as well at the
>  > bottom. I'd say that would show too few lines, when my font of choice
>  > is used, but the IDEs seem to handle it fine somehow with their
>  > defaults.
>
> Yes.  Do you see any problems with that?

IIUC, in Emacs it would require me to lower the font size to function 
adequately, and that would negatively impact readability.

>  > and xref output (though not
>  > Grep, because it includes a file name on each line) is about the same
>  > width, so by putting it at the bottom we'll waste the right half of
>  > the "view windows area".
>
> Yes.  We're back at my inital proposal to give *xref* buffers a
> multicolumn layout.

Indeed, it would be an improvement in that situation.

Re: xref and displaying locations in appropriate window or frame

[martin rudalics]

 > I see. But that's an interesting comparison, because *completions*
 > only seems to use display-buffer-at-bottom when you're typing in the
 > minibuffer, but not when completion occurs in a file buffer. So It's
 > only used when *completions* would appear above the place you're
 > currently looking at.

Juri's intention was to put it right above the minibuffer.  But I
proposed ‘display-buffer-at-bottom’ to you only because it already is
in window.el.  You can always write your own ‘display-buffer’ action
function and put it into xref.el or, if it's of more common use, into
window.el.  This way you can avoid all limitations.

Just that when you display the target buffer, its window's size should
somehow correspond to the expectations of the user.  That's why in a
split I would always try to make it as large as the original window.

 > IIRC, Intellij IDEA has added the capability to do side-by-side
 > splits, but they're not used by most users, and you can't split the
 > view window area anyway (and we can!).

I hardly ever played around with IDEs so I wouldn't know.

 >>  > Thus, a file search output will be just as wide, and one can't really
 >>  > do better that display it in a full-width window as well at the
 >>  > bottom. I'd say that would show too few lines, when my font of choice
 >>  > is used, but the IDEs seem to handle it fine somehow with their
 >>  > defaults.
 >>
 >> Yes.  Do you see any problems with that?
 >
 > IIUC, in Emacs it would require me to lower the font size to function
 > adequately, and that would negatively impact readability.

Why can't you increase the window height?

martin

Re: xref and displaying locations in appropriate window or frame

[Dmitry Gutov]

On 01/27/2016 09:08 PM, martin rudalics wrote:

> Juri's intention was to put it right above the minibuffer.  But I
> proposed ‘display-buffer-at-bottom’ to you only because it already is
> in window.el.  You can always write your own ‘display-buffer’ action
> function and put it into xref.el or, if it's of more common use, into
> window.el.  This way you can avoid all limitations.

display-buffer-at-bottom looks adequate for its purpose. I'm only 
pointing out that *completions* is very rarely _below_ where you are.

I don't want to write my own action because it'll just be another piece 
of logic behaving differently from the rest. Hardly a beneficial thing.

>  > IIUC, in Emacs it would require me to lower the font size to function
>  > adequately, and that would negatively impact readability.
>
> Why can't you increase the window height?

If we're emulating an IDE, though, the standard is to default to ~30% of 
the frame height, or less. The user might change the height, but even 
so, they're unlikely to increase it above 50% of the frame height, and 
in doing that, they'll cut the height of all file-visiting windows by half.

Re: xref and displaying locations in appropriate window or frame

[Juri Linkov]

> I hardly ever played around with IDEs so I wouldn't know.

Implementing an IDE-like mode in Emacs implies displaying the *xref*
buffer in the same fixed bottom window shared with all other view buffers
like *grep*, *compilation*, *Completions*, ...

 ------------
|  O  |   T  |
|     |      |
|------------|
|     X      |
 ------------

and using the tab-bar to switch between these buffers in that bottom window.

OTOH, in non-IDE mode let's use the default behavior of display-buffer to display
*xref* the same way as *grep* and *compilation* are displayed, i.e.:

 ------------
|     |      |
|  T  |   X  |
|     |      |
 ------------

or in narrow frames:

 -----
|  T  |
|-----|
|  X  |
 -----

One problem with xref is that currently it doesn't keep the *xref*
buffer displayed all the time during the next-error navigation,
and I don't understand why.

Re: xref and displaying locations in appropriate window or frame

[Dmitry Gutov]

On 01/28/2016 01:45 AM, Juri Linkov wrote:

> One problem with xref is that currently it doesn't keep the *xref*
> buffer displayed all the time during the next-error navigation,
> and I don't understand why.

What do you think is this discussion about?

But I can also point out that the next-error-function docstring doesn't 
prescribe anything like that. And next-error-move-function, apparently, 
could choose whatever way it wants, to display the error location. 
Including deleting all other windows.

Re: xref and displaying locations in appropriate window or frame

[martin rudalics]

 > Implementing an IDE-like mode in Emacs implies displaying the *xref*
 > buffer in the same fixed bottom window shared with all other view buffers
 > like *grep*, *compilation*, *Completions*, ...
 >
 >   ------------
 > |  O  |   T  |
 > |     |      |
 > |------------|
 > |     X      |
 >   ------------
 >
 > and using the tab-bar to switch between these buffers in that bottom window.

Alternatively, it should be posible to display *xref* and *grep in two
side-by-side windows on the bottom of the frame like:

  ------------
|  O  |   T  |
|     |      |
|------------|
|  X  |   C  |
  ------------

I always wanted to rewrite ‘tabulated-list-mode’ so that it auto-adapts
columns to the size of the corresponding window whenever it changes.

 > One problem with xref is that currently it doesn't keep the *xref*
 > buffer displayed all the time during the next-error navigation,
 > and I don't understand why.

I suppose there should be three modes but my understanding of this might
be completely inadequate:

- One that never displays the *xref* window but displays the next target
   buffer via a command.  This is what etags did once IIRC.  I don't know
   whether it's still around and has/had suitable navigational facilities
   to return to the previous target buffer, for example.  Completion at
   point works in a similar way if I'm not mistaken.

- One that keeps the *xref* window open forever until the user deletes
   it explicitly.  That's the variant we discuss here.  I think that this
   variant should show the *xref* window at the bottom of the frame and
   should show *xref* even if there is only one possible choice.

- One that auto-hides the *xref* window as soon as the user makes a
   choice.  That's the one proposed by xref.el and I believe it would
   need an explicit command to redisplay the *xref* buffer instead of
   asking the user to explicitly switch to it.  This variant should show
   the *xref* buffer via ‘pop-to-buffer’ and probably replace it with the
   target buffer whenever the user makes a choice.  It would immediately
   show the target buffer when there's only one choice.  Completing via
   the *Completions* window very much works according to this principle.

It might be also useful to mix these approaches by having one command
that shows the target buffer and buries the *xref* buffer and another
command that shows the target buffer and leaves the *xref* window alone.

Sorry if I misinterpreted things.  Alas, the ‘next-error’ discussion so
far escaped my attention.  Any reassessment of what it's supposed to do
and how that is related to showing something in a window would be highly
welcome.  The thread of bug#20489 is too confusing for me.  At the very
least, the term ‘next-error’ for xref sounds like a misnomer to me.

martin

RE: xref and displaying locations in appropriate window or frame

[Drew Adams]

> I always wanted to rewrite ‘tabulated-list-mode’ so that it auto-adapts
> columns to the size of the corresponding window whenever it changes.

Please don't do that, unless you give users and libraries the option.
Some contexts may want that; some may not. 

Re: xref and displaying locations in appropriate window or frame

[Juri Linkov]

> I suppose there should be three modes but my understanding of this might
> be completely inadequate:
>
> - One that never displays the *xref* window but displays the next target
>   buffer via a command.  This is what etags did once IIRC.  I don't know
>   whether it's still around and has/had suitable navigational facilities
>   to return to the previous target buffer, for example.  Completion at
>   point works in a similar way if I'm not mistaken.
>
> - One that keeps the *xref* window open forever until the user deletes
>   it explicitly.  That's the variant we discuss here.  I think that this
>   variant should show the *xref* window at the bottom of the frame and
>   should show *xref* even if there is only one possible choice.
>
> - One that auto-hides the *xref* window as soon as the user makes a
>   choice.  That's the one proposed by xref.el and I believe it would
>   need an explicit command to redisplay the *xref* buffer instead of
>   asking the user to explicitly switch to it.  This variant should show
>   the *xref* buffer via ‘pop-to-buffer’ and probably replace it with the
>   target buffer whenever the user makes a choice.  It would immediately
>   show the target buffer when there's only one choice.  Completing via
>   the *Completions* window very much works according to this principle.

I think that once *xref* is displayed, it has to remain displayed
as long as the user continues the current navigation.

Whether to display *xref* initially should depend on the initial command, so
we could have two commands: one that displays *xref*, and another that doesn't
(i.e. your first and second options above).

In other respects, I see no reason for *xref* to operate differently from *grep*
and other similar existing next-error providers, so to display the *xref* window
using the default display action, and never auto-hide it.

Re: xref and displaying locations in appropriate window or frame

[martin rudalics]

 > I think that once *xref* is displayed, it has to remain displayed
 > as long as the user continues the current navigation.

And how do we establish the fact that the user has discontinued the
current navigation?  The only way to faithfully do that is by killing
the *xref* buffer.

martin

Re: xref and displaying locations in appropriate window or frame

[Juri Linkov]

>> I think that once *xref* is displayed, it has to remain displayed
>> as long as the user continues the current navigation.
>
> And how do we establish the fact that the user has discontinued the
> current navigation?  The only way to faithfully do that is by killing
> the *xref* buffer.

There is no need to detect the end of the navigation.  The user can hide
the *xref* buffer anytime, and/or start a new navigation.

Re: xref and displaying locations in appropriate window or frame

[Dmitry Gutov]

On 01/28/2016 12:42 PM, martin rudalics wrote:

> Sorry if I misinterpreted things.  Alas, the ‘next-error’ discussion so
> far escaped my attention.  Any reassessment of what it's supposed to do
> and how that is related to showing something in a window would be highly
> welcome.  The thread of bug#20489 is too confusing for me.  At the very
> least, the term ‘next-error’ for xref sounds like a misnomer to me.

Lots of modes integrate with `next-error': not only Compilation, but 
also Grep, Occur, ChangeLog, and others.

Having Grep in that list seems particularly relevant.

Re: xref and displaying locations in appropriate window or frame

[martin rudalics]

 > Lots of modes integrate with `next-error': not only Compilation, but
 > also Grep, Occur, ChangeLog, and others.
 >
 > Having Grep in that list seems particularly relevant.

I just found this remarkable sentence in the user manual:

   This works by treating the matches reported
   by `grep' as if they were errors.

Emacs contortionism knows no bounds.

martin

Re: xref and displaying locations in appropriate window or frame

[Dmitry Gutov]

On 01/29/2016 10:27 AM, martin rudalics wrote:

> I just found this remarkable sentence in the user manual:
>
>    This works by treating the matches reported
>    by `grep' as if they were errors.
>
> Emacs contortionism knows no bounds.

That's just silly wording. If "as if they were errors" is a problem, we 
could rename `next-error' to `next-location', and all other functions 
and variables accordingly.

I don't think it'll change much in the user experience, though.

Re: xref and displaying locations in appropriate window or frame

[Juri Linkov]

> That's just silly wording. If "as if they were errors" is a problem, we
> could rename `next-error' to `next-location', and all other functions and
> variables accordingly.

Better ‘next-occurrence’ or shorter ‘next-occur’ as a reference to the
more general utility ‘occur’.  What do you think about basing *xref*
on *Occur*: either by inheriting its mode, or at least its formatting
to bring both closer to each other?

Re: xref and displaying locations in appropriate window or frame

[Dmitry Gutov]

On 01/25/2016 09:18 PM, martin rudalics wrote:

> This is no good layout for IDEs.  Source/code windows like O and T
> should always form a rectangle.  Auxiliary windows like X should be
> arranged around that rectangle.

IDE-like window layout is not one of my goals here. I think I've 
explained how it would be less than idea.

That's not to say that the users shouldn't be able to choose this window 
management strategy (using display-buffer-alist?), but let's not bake 
this choice into xref.

>  > But I can live with O being split instead.
>
> This would nullify the above benefit.  In any case the larger of the two
> windows will be split.

It might be handy to split the window that shows the shortest buffer, if 
all other parameters are equal. But that's tangential to this discussion.

>  > Note, however, that from the X-below-O configuration I quoted above
>  > you can't each either of the good target configurations.
>
> You could split the parent window of O and X.

Very well (they have a parent window?). But that seems to imply manual 
layout management, instead of using e.g. pop-to-buffer.

> When X has short lines it could be shown on the left of O like this.
>
>   -----------------
> |X|   O   |   T   |
> | |       |       |
> | |       |       |
> | |       |       |
> | |       |       |
>   -----------------

Let's say that the lines in X are about half of the frame's width. At 
least, that's my usual experience.

>  >> Do you produce *xref* asynchronously?
>  >
>  > Not yet, we I hope we manage to do that. Only working synchronously is
>  > one of its drawbacks compared to Grep.
>
> Then ‘fit-window-to-buffer’ will be moot anyway.

Yes, sorry. It could still be useful in the alternative presentation 
method for xref-find-definitions, to be written by somebody, sometimes 
later.

>  > We'd split one of the windows again and show the target buffer in the
>  > new window. See my diagram at the beginning of this email.
>
> Then we're back at the initial problem that by default Emacs never shows
> more than two windows on a frame :-(

I suppose so. But its resolution should be orthogonal to what I do.

>  >> One problem with dedicated windows is that if an application and the
>  >> user both start dedicating the same window to its buffer there might be
>  >> conflicts.  I doubt that such conflicts can be "fixed" easily.
>  >
>  > So, then problem will occur when I un-dedicate it at the end, in
>  > unwind-protect? I suppose I can save its dedication status, and then
>  > restore it.
>
> Right.  I doubt you can do any better.  But do it.

Thanks!

>  > Indeed. Anyway, I'd be fine with changing the default, as long as
>  > side-by-side splits are still preferred.
>
> It always depends on the size and shape of your frame.

Ok, always preferred on my machine (229x58), then. :)

You might want to initiate a separate discussion about that. I'm not the 
person to make this choice, and nobody else is responding, this deep 
into this thread.

>  > All right, *Compilation*, then?
>
> IIRC the original question was where *Grep* and *Compilation* display
> their targets.  Here I practically always create a new window.  But by
> default the target will be usually displayed in the original window, the
> one selected at the time you called grep or compile.

The question was about the user being able to bury *Grep*, then switch 
back to it, and continue using it without issue. But indeed, *Grep* and 
*Compilation* have it easier.

>  > IMHO, the users won't bother, and will either switch to that buffer
>  > manually, or just repeat the search.
>
> So let's not prevent them from doing that ;-)

All right.

Re: xref and displaying locations in appropriate window or frame

[martin rudalics]

 > IDE-like window layout is not one of my goals here. I think I've
 > explained how it would be less than idea.
 >
 > That's not to say that the users shouldn't be able to choose this
 > window management strategy (using display-buffer-alist?), but let's
 > not bake this choice into xref.

While personally I prefer window management by chaos, it's up to you to
justify your choice.

 >> You could split the parent window of O and X.
 >
 > Very well (they have a parent window?). But that seems to imply manual
 > layout management, instead of using e.g. pop-to-buffer.

Back to where we were: ‘pop-to-buffer’ is based on the <= 2 windows per
frame paradigm.

 >> When X has short lines it could be shown on the left of O like this.
 >>
 >>   -----------------
 >> |X|   O   |   T   |
 >> | |       |       |
 >> | |       |       |
 >> | |       |       |
 >> | |       |       |
 >>   -----------------
 >

 > Let's say that the lines in X are about half of the frame's width. At
 > least, that's my usual experience.

The default frame's width?

 >>  > We'd split one of the windows again and show the target buffer in the
 >>  > new window. See my diagram at the beginning of this email.
 >>
 >> Then we're back at the initial problem that by default Emacs never shows
 >> more than two windows on a frame :-(
 >
 > I suppose so. But its resolution should be orthogonal to what I do.

Sometimes you want the cake and eat it.

 > The question was about the user being able to bury *Grep*, then switch
 > back to it, and continue using it without issue. But indeed, *Grep*
 > and *Compilation* have it easier.

Ahh, funny.  I never switch back to *Compilation* manually.  I always
keep it open until I have resolved all issues.  And my grep sidebars
hardly occupy any space.  I often show two or more greps or searches
simultaneously.  And whenever I remove a grep sidebar from the frame,
its buffer gets killed automatically.  I wouldn't remember anyway what I
needed it for.

martin

Re: xref and displaying locations in appropriate window or frame

[Dmitry Gutov]

On 01/26/2016 01:05 PM, martin rudalics wrote:

> Back to where we were: ‘pop-to-buffer’ is based on the <= 2 windows per
> frame paradigm.

Why <= 2? Are you saying I should use some different function, after 
applying the dedicated status and switch to the window O?

I thought pop-to-buffer is basically the default choice for displaying a 
buffer when you're not sure which window to use.

>  > Let's say that the lines in X are about half of the frame's width. At
>  > least, that's my usual experience.
>
> The default frame's width?

Of a maximized frame's width. Which is 229 here.

>  >> Then we're back at the initial problem that by default Emacs never
> shows
>  >> more than two windows on a frame :-(
>  >
>  > I suppose so. But its resolution should be orthogonal to what I do.
>
> Sometimes you want the cake and eat it.

Everybody does.

> Ahh, funny.  I never switch back to *Compilation* manually.  I always
> keep it open until I have resolved all issues.  And my grep sidebars
> hardly occupy any space.  I often show two or more greps or searches
> simultaneously.  And whenever I remove a grep sidebar from the frame,
> its buffer gets killed automatically.  I wouldn't remember anyway what I
> needed it for.

I do, sometimes. And maybe the user has their own special subroutine 
which knows which buffer to show and why.

Re: xref and displaying locations in appropriate window or frame

[martin rudalics]

 > Why <= 2? Are you saying I should use some different function, after
 > applying the dedicated status and switch to the window O?

Did you try it?  In a default Emacs this won't split anything but either
reuse O or make a new frame.

 > I thought pop-to-buffer is basically the default choice for displaying
 > a buffer when you're not sure which window to use.

It is.  But in a default Emacs you still won't get your third window.
You can't beat the system by using ‘pop-to-buffer’ alone.

Which IMHO is no problem per se.  But you probably have to explain
somewhere that ‘xref-find-definitions-other-window’ _by default_ behaves
just like ‘xref-find-definitions’ when leaving *xref* visible.

martin

Re: xref and displaying locations in appropriate window or frame

[Dmitry Gutov]

On 01/27/2016 12:10 PM, martin rudalics wrote:
>  > Why <= 2? Are you saying I should use some different function, after
>  > applying the dedicated status and switch to the window O?
>
> Did you try it?  In a default Emacs this won't split anything but either
> reuse O or make a new frame.

Why is it a drawback of pop-to-buffer, though? It should work fine, as 
long as split thresholds have adequate values.

>  > I thought pop-to-buffer is basically the default choice for displaying
>  > a buffer when you're not sure which window to use.
>
> It is.  But in a default Emacs you still won't get your third window.
> You can't beat the system by using ‘pop-to-buffer’ alone.

I think "beating the system" here would be a wrong choice.

> Which IMHO is no problem per se.  But you probably have to explain
> somewhere that ‘xref-find-definitions-other-window’ _by default_ behaves
> just like ‘xref-find-definitions’ when leaving *xref* visible.

You're right, it's a problem, and I don't know a good solution. It's not 
a great thing to have to document.

Re: xref and displaying locations in appropriate window or frame

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org, martin rudalics <rudalics@gmx.at>,
>  Helmut Eller <eller.helmut@gmail.com>
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 24 Jan 2016 05:19:21 +0300
> 
> xref-find-definitions has a family of commands (namely -other-window and 
> -other-frame) which promise to display the location somewhere else than 
> the current window.

But AFAICS they only do that if there's a single candidate for the
definition, i.e. if the *xref* buffer is not displayed at all.  Which
confused the heck out of me the first time I tried "C-x 5 .", btw.

> If we're allowed to quit the *xref* buffer before jumping to the "final 
> destination", we can nominally satisfy the contract by using 
> switch-to-buffer or pop-to-buffer (maybe with pop-up-frames bound to t) 
> after that. The *xref* buffer and its window are out of the picture by 
> that point.
> 
> However, now we have the *xref* buffer back in the picture. I think that 
> means we have to satisfy the this-window/other-window/other-frame 
> contract while *xref* is displayed.

Yes, I think so.  It will also fix the above confusion, IMO.

> - xref-find-definitions-other-frame seems easiest: just bind 
> pop-up-frames to t and call pop-to-buffer like before.

Right.

> - xref-find-definitions promises to show the destination buffer in the 
> current window. What will RET in *xref* do? Show the buffers in the 
> window xref-find-definitions was called from?

Yes, I think so.

> That seems to make the most sense, but it will obscure the original
> code. Maybe we'd want to consult it while picking the exact option
> among the suggested definitions?

I don't think I understand you here.  By "obscure the original code"
do you mean the code will be harder to read?  Or do you mean something
else?

And what do you mean by "consult" -- consult what?

> - xref-find-definitions-other-window should, apparently, pick some 
> window which isn't the original one, nor the one which displays the 
> *xref* buffer. Or create a new one, in a pop-to-buffer fashion.

Probably, yes.

> Is there a function in window.el I can reuse, and/or display-buffer
> alist argument that would make it ignore whole two buffers, and not
> just the currently selected one?

I hope Martin will help you out here.

> Alternatively, we *do* treat xref-find-definitions differently, and 
> don't keep the *xref* buffer visible after the user made their choice. 
> But if the *xref* buffer looks the same as in other cases, it would be 
> confusing. So ideally, we'd have a different choice-picking mechanism in 
> this case (not *xref* buffer like it works and looks right now), but I 
> really don't know where to start writing it (and don't want to do it now).

I think we should try the former route first, it sounds simpler.

> Yet alternatively, as soon as we find out that there are several 
> definitions of the given function, we abandon all that 
> other-window/other-frame business, and simply make RET always behave the 
> same in *xref*. That seems like a cop-out.

I think this should change, it's a confusing inconsistency if the user
asked for another window/frame.

Thanks.

Re: xref and displaying locations in appropriate window or frame

[Dmitry Gutov]

On 01/24/2016 06:43 PM, Eli Zaretskii wrote:

>> xref-find-definitions has a family of commands (namely -other-window and
>> -other-frame) which promise to display the location somewhere else than
>> the current window.
>
> But AFAICS they only do that if there's a single candidate for the
> definition, i.e. if the *xref* buffer is not displayed at all.  Which
> confused the heck out of me the first time I tried "C-x 5 .", btw.

They do it for the final destination, but not for buffers temporarily 
displayed when you press `n' or `p'. E.g.:

Press `C-x 4 .', type log-edit-menu, pick an element, press RET - and 
you'll see its location displayed in the "other" window. Same with `C-x 
5 .', though to see the expected effect the destination buffer must not 
be already displayed in the current frame.

But if we're not allowed to hide *xref* on RET either, xref-goto-xref 
and xref-show-location-at-point's behavior should be close to this, and 
only differ in which window ends up being selected.

>> That seems to make the most sense, but it will obscure the original
>> code. Maybe we'd want to consult it while picking the exact option
>> among the suggested definitions?
>
> I don't think I understand you here.  By "obscure the original code"
> do you mean the code will be harder to read?  Or do you mean something
> else?
>
> And what do you mean by "consult" -- consult what?

I only mean that the original buffer will be hidden, and the user won't 
be able to look at its contents while making the choice. Which might be 
considered bad, for the default behavior. Maybe not too terrible, though.

(When there's only one option, jumping to it in the current window seems 
best to me, so changing M-. to be bound to 
xref-find-definitions-other-window instead doesn't seem like a good 
alternative.)

Re: xref and displaying locations in appropriate window or frame

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org, rudalics@gmx.at, eller.helmut@gmail.com
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 24 Jan 2016 20:27:29 +0300
> 
> On 01/24/2016 06:43 PM, Eli Zaretskii wrote:
> 
> >> xref-find-definitions has a family of commands (namely -other-window and
> >> -other-frame) which promise to display the location somewhere else than
> >> the current window.
> >
> > But AFAICS they only do that if there's a single candidate for the
> > definition, i.e. if the *xref* buffer is not displayed at all.  Which
> > confused the heck out of me the first time I tried "C-x 5 .", btw.
> 
> They do it for the final destination, but not for buffers temporarily 
> displayed when you press `n' or `p'. E.g.:
> 
> Press `C-x 4 .', type log-edit-menu, pick an element, press RET - and 
> you'll see its location displayed in the "other" window. Same with `C-x 
> 5 .', though to see the expected effect the destination buffer must not 
> be already displayed in the current frame.

With RET, yes.  But this doesn't happen with '.'.  Isn't that
confusing?

> But if we're not allowed to hide *xref* on RET either, xref-goto-xref 
> and xref-show-location-at-point's behavior should be close to this, and 
> only differ in which window ends up being selected.

RET runs xref-goto-xref, so whatever RET does, xref-goto-xref will do
the same, no?  What am I missing?

As for xref-show-location-at-point, it doesn't bury the *xref* buffer
when I try it now, so it looks like it already avoids hiding *xref*.

I have a terrible feeling that I'm missing something important here.

> >> That seems to make the most sense, but it will obscure the original
> >> code. Maybe we'd want to consult it while picking the exact option
> >> among the suggested definitions?
> >
> > I don't think I understand you here.  By "obscure the original code"
> > do you mean the code will be harder to read?  Or do you mean something
> > else?
> >
> > And what do you mean by "consult" -- consult what?
> 
> I only mean that the original buffer will be hidden, and the user won't 
> be able to look at its contents while making the choice. Which might be 
> considered bad, for the default behavior. Maybe not too terrible, though.

No, I don't think it's terrible.  There's always
xref-pop-marker-stack, right?

> (When there's only one option, jumping to it in the current window seems 
> best to me

I agree.

Re: xref and displaying locations in appropriate window or frame

[Dmitry Gutov]

On 01/24/2016 08:58 PM, Eli Zaretskii wrote:

> With RET, yes.  But this doesn't happen with '.'.  Isn't that
> confusing?

Somewhat, yes. But it avoided the problem of showing a buffer while 
avoiding touching two windows.

> RET runs xref-goto-xref, so whatever RET does, xref-goto-xref will do
> the same, no?

Yes. Including hiding the xref buffer, like currently implemented.

> As for xref-show-location-at-point, it doesn't bury the *xref* buffer
> when I try it now, so it looks like it already avoids hiding *xref*.

Avoids, yes. And it doesn't fulfill the "show in this/other 
window/frame" contract, like you've observed.

It's possible that we can easily have only one or the other.

> I have a terrible feeling that I'm missing something important here.

Not sure if you are.

>> I only mean that the original buffer will be hidden, and the user won't
>> be able to look at its contents while making the choice. Which might be
>> considered bad, for the default behavior. Maybe not too terrible, though.
>
> No, I don't think it's terrible.  There's always
> xref-pop-marker-stack, right?

I suppose.

Re: xref and displaying locations in appropriate window or frame

[Dmitry Gutov]

On 01/24/2016 05:43 PM, Eli Zaretskii wrote:

>> However, now we have the *xref* buffer back in the picture. I think that
>> means we have to satisfy the this-window/other-window/other-frame
>> contract while *xref* is displayed.
>
> Yes, I think so.  It will also fix the above confusion, IMO.

Having tried this, I don't think this is feasible.

First, if xref-show-location-at-point (called when ./,/n/p is pressed) 
tries to satisfy the "other frame" contract, if the user hasn't done 
some special frame-related configuration, doesn't use a tiling window 
manager, etc, we get the location buffer displayed in a new, selected 
frame on top of the current one. There's no way to keep pressing "n" or 
"p" to jump through the locations.

Second, we shouldn't use one strategy in xref-show-location-at-point, 
and another in xref-goto-xref: even if the user wanted to see the target 
in a new frame, they are unlikely to appreciate seeing it both in "some 
other" window in the current frame, and in the new frame as well after 
they press RET.

So, retaining the other-frame contract is out. other-window is easier, 
but, like Martin noted, the approach available to us (show in some 
window that's not the original one, and not the xref one) is also iffy, 
because it might be not _the_ "other window" respective to the original 
one. The xref buffer could very well be displayed in that window, so we 
can't use it.

Further, even though the user asked to display the destination using a 
particular approach, by the time they choose the location from the list, 
they might have forgotten their original request: several commands will 
have passed by that time.

Overall, when the xref buffer gets to be displayed, I think always using 
the "some other window" seems best after. We could also implement the 
this-window/other-frame modifiers for xref-goto-xref later.

>> ...ideally, we'd have a different choice-picking mechanism in
>> this case (not *xref* buffer like it works and looks right now), but I
>> really don't know where to start writing it (and don't want to do it now).
>
> I think we should try the former route first, it sounds simpler.
>
>> Yet alternatively, as soon as we find out that there are several
>> definitions of the given function, we abandon all that
>> other-window/other-frame business, and simply make RET always behave the
>> same in *xref*. That seems like a cop-out.
>
> I think this should change, it's a confusing inconsistency if the user
> asked for another window/frame.

The inconsistency is unfortunate, but it stems from our attempt to 
shoehorn the xref buffer into two different use cases.

Ultimately, I think the multiple-choice xref-find-definitions case would 
be better served by a selection UI that emphasizes its transitiveness, 
goes away as soon as the user made their choice, and itself has no 
long-term impact on the window configuration.

It's probably best implemented using an overlay of some sort on top of 
the current frame. See the similar feature in Atom (who inherited it 
from Sublime) on the screenshots here: 
https://atom.io/docs/latest/using-atom-moving-in-atom

I went in that direction in xref previously, when all changes made to 
the window configuration by ,/./n/p were being undone before the next 
command. But that was a half-measure anyway, and the "transient" 
interface doesn't serve other commands well (those where you usually 
want to operate on several locations from the list, and not just pick 
one and forget the other matches).

It's worth noting that SLIME uses its xref buffer exactly in a transient 
fashion, and Helmut's contribution had that behavior, but I've come to 
believe it's a mistake.

Re: tags-loop-continue

[Dmitry Gutov]

On 01/21/2016 07:07 PM, Eli Zaretskii wrote:

> No, I think all the matches that the user saw already, whether she
> accepted the replacement or not, should be marked in some way, so that
> continuing the replacement goes to the first unseen one.

Any suggestions for the decoration? Use some existing face? 
mode-line-inactive? Add a new face, with strike-through?

Re: tags-loop-continue

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 22 Feb 2016 01:49:58 +0200
> 
> On 01/21/2016 07:07 PM, Eli Zaretskii wrote:
> 
> > No, I think all the matches that the user saw already, whether she
> > accepted the replacement or not, should be marked in some way, so that
> > continuing the replacement goes to the first unseen one.
> 
> Any suggestions for the decoration? Use some existing face? 

A face sounds good.

> mode-line-inactive? Add a new face, with strike-through?

How about file-name-shadow?

Re: tags-loop-continue

[Stefan Monnier]

> Unfortunately, I think it makes much more sense to bind
> tags-loop-continue back to 'M-,', and bind xref-pop-marker-stack to
> 'M-*', the old binding of pop-tag-mark, which xref-pop-marker-stack
> replaces.  When tags-loop-continue is no longer needed, we could use
> its binding for xref-pop-marker-stack, but until then we cannot use
> its key for an entirely different command, I think.

Would it be possible to bind M-, to a new command which dispatches
either to tags-loop-continue or to xref-pop-marker-stack?
IOW is there some way to guess reliably which one makes sense?


        Stefan "not familiar with these uses of tags-loop-continue"

Re: tags-loop-continue

[Dmitry Gutov]

On 01/18/2016 02:12 AM, Stefan Monnier wrote:

> IOW is there some way to guess reliably which one makes sense?

I don't think so.

Re: tags-loop-continue

[Stefan Monnier]

>> IOW is there some way to guess reliably which one makes sense?
> I don't think so.

Couldn't we have a global boolean var (call it `M-,-should-use-xref')
and then set it to t whenever an xref command is used, and set it to nil
whenever a command that could interact with etags-loop-continue is used?


        Stefan

Re: tags-loop-continue

[Dmitry Gutov]

On 01/18/2016 05:20 AM, Stefan Monnier wrote:

> Couldn't we have a global boolean var (call it `M-,-should-use-xref')
> and then set it to t whenever an xref command is used, and set it to nil
> whenever a command that could interact with etags-loop-continue is used?

It will be a mess, if you ask me.

The idea behind using tags-loop-continue is that the user can call 
tags-search, get to the first match, mess around in whatever way she 
wants there, then call tags-loop-continue to advance to the second 
match, and so on.

There's no reason to assume that "messing around" won't include calling 
some xref command. And then tags-loop-continue will be broken.

Re: tags-loop-continue

[Stefan Monnier]

>> Couldn't we have a global boolean var (call it `M-,-should-use-xref')
>> and then set it to t whenever an xref command is used, and set it to nil
>> whenever a command that could interact with etags-loop-continue is used?
> The idea behind using tags-loop-continue is that the user can call
> tags-search, get to the first match, mess around in whatever way she wants
> there, then call tags-loop-continue to advance to the second match, and
> so on.
> There's no reason to assume that "messing around" won't include calling some
> xref command.  And then tags-loop-continue will be broken.

Presumably if the user uses both xref and etags-search, then she knows
about both meanings of M-, and she should hence "intuitively"
understand that there's a conflict.

For that specific case, we could let the user use C-u M-, in order to
specify which of the two commands to use.

Admittedly, I'm not sure this assumption that "the user will intuitively
know that there's a conflict" holds.

Maybe we'd be better off keeping M-, for tags-loop-continue for now and
use M-* for xref-pop-marker-stack.  It at least has the benefit of
reducing the differences between 24.5 and 25.1.
So it can be seen as an intermediate step and in 26.1 we could get rid
of tags-loop-continue (assuming we figure out how) and move
xref-pop-marker-stack to M-,


        Stefan

Re: tags-loop-continue

[Dmitry Gutov]

On 01/18/2016 05:48 AM, Stefan Monnier wrote:

> Presumably if the user uses both xref and etags-search, then she knows
> about both meanings of M-, and she should hence "intuitively"
> understand that there's a conflict.

Sure she does.

> For that specific case, we could let the user use C-u M-, in order to
> specify which of the two commands to use.

Or, you know, she could just use M-x tags-loop-continue for 
tags-loop-continue.

> Admittedly, I'm not sure this assumption that "the user will intuitively
> know that there's a conflict" holds.

Right.

> Maybe we'd be better off keeping M-, for tags-loop-continue for now and
> use M-* for xref-pop-marker-stack.  It at least has the benefit of
> reducing the differences between 24.5 and 25.1.
> So it can be seen as an intermediate step and in 26.1 we could get rid
> of tags-loop-continue (assuming we figure out how) and move
> xref-pop-marker-stack to M-,

If, to be rid of tags-loop-continue, implementing the two Dired commands 
to use the xref UI is enough, I'll have that soon.

Otherwise, why put ourselves in an inconsistent state (and force users 
to re-learn keys twice)? If we're so worried about backward 
compatibility, let's rip out all new xref bindings and on-obsolete all 
corresponding etags commands.

The interested users would enable some xref-bindings-mode we can add 
without much fuss. The rest will continue to live undisturbed.

Re: tags-loop-continue

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 18 Jan 2016 05:57:34 +0300
> Cc: emacs-devel@gnu.org
> 
> If, to be rid of tags-loop-continue, implementing the two Dired commands 
> to use the xref UI is enough, I'll have that soon.

Thanks.