GNU bug report logs -
#42210
Add -other-window variants of project-prefix-map commands
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 42210 in the body.
You can then email your comments to 42210 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
juri <at> linkov.net, dgutov <at> yandex.ru, bug-gnu-emacs <at> gnu.org:
bug#42210; Package
emacs.
(Sun, 05 Jul 2020 06:15:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Sean Whitton <spwhitton <at> spwhitton.name>:
New bug report received and forwarded. Copy sent to
juri <at> linkov.net, dgutov <at> yandex.ru, bug-gnu-emacs <at> gnu.org.
(Sun, 05 Jul 2020 06:15:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello,
On Fri 03 Jul 2020 at 05:54PM -07, Sean Whitton wrote:
> It seems like it would be a good idea to have
>
> C-x 4 p f
> be like
> C-x 4 4 C-x p f
>
> C-x 5 p e
> be like
> C-x 5 5 C-x p e
>
> etc., since many of the commands in project-prefix-map involve switching
> to another buffer. Certainly project-switch-project, project-find-file
> and project-switch-to-buffer would be wanted.
Here is a patch implementing commands under C-x 4 p. If the approach is
thought sound I can also prepare patches for C-x 5 p and C-x t p.
I have tested the attached change except for the autoload cookies which
I am not sure will work with my new macro. And I'm not sure I should be
doing this with a macro instead of a function which calls fset -- please
advise.
If you want me to do copyright assignment before investing time giving
me feedback on my patch, I would be happy to.
--
Sean Whitton
[0001-Add-define-other-window-command-and-project-other-wi.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42210; Package
emacs.
(Sun, 05 Jul 2020 14:42:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 42210 <at> debbugs.gnu.org (full text, mbox):
> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Date: Sat, 04 Jul 2020 23:13:58 -0700
> Cc: dgutov <at> yandex.ru, juri <at> linkov.net
>
> Here is a patch implementing commands under C-x 4 p. If the approach is
> thought sound I can also prepare patches for C-x 5 p and C-x t p.
Thanks. Please accompany these changes with suitable changes to NEWS
and the user manual.
> If you want me to do copyright assignment before investing time giving
> me feedback on my patch, I would be happy to.
Form sent off-list.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42210; Package
emacs.
(Sun, 05 Jul 2020 18:38:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 42210 <at> debbugs.gnu.org (full text, mbox):
1. I disagree with calling the macro `define-other-window-command'.
My disagreement is this: Defining an other-window command
should do just that. It should not define a command that
only "prefers" to display in another window. It should
define a command that actually displays in another window.
And your doc string in fact says the latter, though the
behavior is, I guess, only the former. Please consider
renaming the macro and fixing the doc string, to make clear
that it's NOT other-window but only maybe-other-window.
2. Why "resultant buffer". What does the buffer result
from? It's about whatever FUNCTION displays, no?
3. Presumably FUNCTION must be a _command_. If so,
the arg should be called COMMAND, and the doc adjusted
accordingly.
#2 and #3 are minor. I'm more concerned about #1.
Emacs has many commands that are _really_ other-window.
They generally use `pop-to-buffer' or
`switch-to-buffer-other-window'.
If this macro produces commands that only "prefer" to
use another window, then the name and doc string are
false advertising.
4. Why not have a macro that _really_ provides an
other-window command?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42210; Package
emacs.
(Sun, 05 Jul 2020 20:26:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 42210 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Sun 05 Jul 2020 at 11:35AM -07, Drew Adams wrote:
> 1. I disagree with calling the macro `define-other-window-command'.
>
> My disagreement is this: Defining an other-window command
> should do just that. It should not define a command that
> only "prefers" to display in another window. It should
> define a command that actually displays in another window.
>
> And your doc string in fact says the latter, though the
> behavior is, I guess, only the former. Please consider
> renaming the macro and fixing the doc string, to make clear
> that it's NOT other-window but only maybe-other-window.
Hmm, but doesn't pop-to-buffer-other-window also only prefer to use
another window, and ultimately defers to the display-buffer-alist
machinery?
> 2. Why "resultant buffer". What does the buffer result
> from? It's about whatever FUNCTION displays, no?
Please feel free to suggest alternative phrasing that will be short
enough to fit in one line, which I understand to be required.
> 3. Presumably FUNCTION must be a _command_. If so,
> the arg should be called COMMAND, and the doc adjusted
> accordingly.
No, it can just be a function too.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42210; Package
emacs.
(Mon, 06 Jul 2020 00:01:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 42210 <at> debbugs.gnu.org (full text, mbox):
> > 1. I disagree with calling the macro `define-other-window-command'.
> >
> > My disagreement is this: Defining an other-window command
> > should do just that. It should not define a command that
> > only "prefers" to display in another window. It should
> > define a command that actually displays in another window.
> >
> > And your doc string in fact says the latter, though the
> > behavior is, I guess, only the former. Please consider
> > renaming the macro and fixing the doc string, to make clear
> > that it's NOT other-window but only maybe-other-window.
>
> Hmm, but doesn't pop-to-buffer-other-window also only prefer to use
> another window, and ultimately defers to the display-buffer-alist
> machinery?
1. (There is no `pop-to-buffer-other-window', is there?)
The doc of `pop-to-buffer' goes out of its way to tell
about its relation with `display-buffer' - because it
passes its arg to it.
The doc of `switch-to-buffer-other-window' just says
directly that it selects the buffer in another window.
Only at its very end does it mention the possibility
that `display-buffer' can alter behavior:
This uses the function `display-buffer' as a subroutine;
see its documentation for additional customization
information.
What's not so good is to (a) not say what THIS function
is for: other-window and (b) not mention `display-buffer',
while suggesting some other behavior than other-window.
2. I suppose `display-buffer(-alist)' can override
anything now.
If that's all that's meant then I think it shouldn't
be put that way. It's OK (but might not be needed or
appropriate) to add some mention of it at the end.
But I don't think the behavior of the command should
be described that way.
The point of the resulting function is (presumably)
to use another window. The point of any additional
`display-buffer*' shenanigans - or other Lisp code
that might have an effect on things - could be just
about anything.
This doc should be about what the resulting function
intends to do, not whatever some other code might
make it do instead. If you want to go the other route,
then make the relation explicit, as does the doc of
`pop-to-buffer' and `switch-to-buffer-other-window'.
> > 2. Why "resultant buffer". What does the buffer result
> > from? It's about whatever FUNCTION displays, no?
>
> Please feel free to suggest alternative phrasing that will be short
> enough to fit in one line, which I understand to be required.
Define an other-window version of FUNCTION.
or
Define a function like FUNCTION that outputs to another window.
or
Define a function like FUNCTION but that outputs to another window.
> > 3. Presumably FUNCTION must be a _command_. If so,
> > the arg should be called COMMAND, and the doc adjusted
> > accordingly.
>
> No, it can just be a function too.
You're right; I was wrong about that.
However, isn't the real purpose of this macro to
define commands, which you can bind to keys to get
other-window behavior? Is there really some other
expected use case? Would anyone use it for a
non-interactive function?
If you want to be exact then yes, FUNCTION. But
in that case I think the doc should say that
FUNCTION is typically a command, i.e., give the
use case that's the raison d'etre for the macro.
BTW, this part of your patch doesn't seem right:
(called-interactively-p).
Argument KIND is optional (should it really be?),
but the behavior of calling the function without
KIND is not documented, and it always just returns
nil.
(I filed bug #42222 about KIND being optional etc.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42210; Package
emacs.
(Mon, 06 Jul 2020 00:56:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 42210 <at> debbugs.gnu.org (full text, mbox):
> Here is a patch implementing commands under C-x 4 p. If the approach is
> thought sound I can also prepare patches for C-x 5 p and C-x t p.
>
> I have tested the attached change except for the autoload cookies which
> I am not sure will work with my new macro. And I'm not sure I should be
> doing this with a macro instead of a function which calls fset -- please
> advise.
Thanks for the patch. On emacs-devel you said that rather than add
definitions of project-find-file-other-window, etc.
display-buffer-override-next-command could be used. But there is no
display-buffer-override-next-command in your patch, and definitions of
project-find-file-other-window etc. are still added (with the help of macro).
Would it be possible to define the 'C-x 4 p' map the same way as
'C-x p p' is defined? There is a patch in https://debbugs.gnu.org/41890#127
to use the default project keymap 'C-x p' in 'C-x p p'. You could try to
use the same keymap in 'C-x 4 p', and wrap the command call with
display-buffer-override-next-command.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42210; Package
emacs.
(Mon, 06 Jul 2020 01:59:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 42210 <at> debbugs.gnu.org (full text, mbox):
Hello Juri,
Thanks for taking a look.
On Mon 06 Jul 2020 at 03:19AM +03, Juri Linkov wrote:
>> Here is a patch implementing commands under C-x 4 p. If the approach is
>> thought sound I can also prepare patches for C-x 5 p and C-x t p.
>>
>> I have tested the attached change except for the autoload cookies which
>> I am not sure will work with my new macro. And I'm not sure I should be
>> doing this with a macro instead of a function which calls fset -- please
>> advise.
>
> Thanks for the patch. On emacs-devel you said that rather than add
> definitions of project-find-file-other-window, etc.
> display-buffer-override-next-command could be used. But there is no
> display-buffer-override-next-command in your patch, and definitions of
> project-find-file-other-window etc. are still added (with the help of macro).
Yeah. After thinking about it a bit more I thought that this would be
more consistent with both the way the other C-x 4 commands work and how
the C-x p subcommands work -- i.e., it's just an ordinary keymap.
Additionally, my approach means that the -other-window functions are
available to be called from lisp, just as switch-to-buffer-other-window
and find-file-other-window already are, which might be useful.
From my perspective, the use of define-other-window-command is
sufficient to resolve my concerns (posted to emacs-devel) about having to
define all the functions. And I think that the macro could be useful in
user init files and maybe elsewhere.
> Would it be possible to define the 'C-x 4 p' map the same way as
> 'C-x p p' is defined? There is a patch in https://debbugs.gnu.org/41890#127
> to use the default project keymap 'C-x p' in 'C-x p p'. You could try to
> use the same keymap in 'C-x 4 p', and wrap the command call with
> display-buffer-override-next-command.
I could give it a shot, but wouldn't it be less useful, since the
-other-window functions would no longer be available to be called from
lisp?
As I say, I think the concerns about having to define the functions is
resolved by define-other-window-command (or whatever it ends up called).
Maybe you could explain why you think doing it like C-x p p would be
better. Thanks again.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42210; Package
emacs.
(Mon, 06 Jul 2020 23:17:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 42210 <at> debbugs.gnu.org (full text, mbox):
>> Thanks for the patch. On emacs-devel you said that rather than add
>> definitions of project-find-file-other-window, etc.
>> display-buffer-override-next-command could be used. But there is no
>> display-buffer-override-next-command in your patch, and definitions of
>> project-find-file-other-window etc. are still added (with the help of macro).
>
> Yeah. After thinking about it a bit more I thought that this would be
> more consistent with both the way the other C-x 4 commands work and how
> the C-x p subcommands work -- i.e., it's just an ordinary keymap.
>
> Additionally, my approach means that the -other-window functions are
> available to be called from lisp, just as switch-to-buffer-other-window
> and find-file-other-window already are, which might be useful.
Actually, keeping consistency with existing C-x 4 commands
is not a requirement. It's quite possible that existing commands
will be declared deprecated as currently is discussed on emacs-devel.
>> Would it be possible to define the 'C-x 4 p' map the same way as
>> 'C-x p p' is defined? There is a patch in https://debbugs.gnu.org/41890#127
>> to use the default project keymap 'C-x p' in 'C-x p p'. You could try to
>> use the same keymap in 'C-x 4 p', and wrap the command call with
>> display-buffer-override-next-command.
>
> I could give it a shot, but wouldn't it be less useful, since the
> -other-window functions would no longer be available to be called from
> lisp?
I see it as an advantage that makes the namespace cleaner - there will be
no more such useless duplicates as
switch-to-buffer
switch-to-buffer-other-frame
switch-to-buffer-other-tab
switch-to-buffer-other-window
and similarly for dozens of other commands. When browsing command names
e.g. in command completions of M-x or C-h f this will reduce the mess.
For a rare case when the users might want to bind an other-window command
directly to a non-prefix key in an init file, then maybe it's possible
to provide a macro or better a wrapper function that could be used like
(global-set-key (kbd "C-x w b") (with-other-window 'switch-to-buffer))
> Maybe you could explain why you think doing it like C-x p p would be
> better. Thanks again.
Let's see what the emacs-devel discussion will bring, maybe C-x 4
will be bound to a command like C-x p p is implemented in
https://debbugs.gnu.org/41890#50
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42210; Package
emacs.
(Wed, 08 Jul 2020 06:28:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 42210 <at> debbugs.gnu.org (full text, mbox):
Hello Juri,
On Tue 07 Jul 2020 at 01:59AM +03, Juri Linkov wrote:
> Actually, keeping consistency with existing C-x 4 commands
> is not a requirement. It's quite possible that existing commands
> will be declared deprecated as currently is discussed on emacs-devel.
Okay.
>>> Would it be possible to define the 'C-x 4 p' map the same way as
>>> 'C-x p p' is defined? There is a patch in https://debbugs.gnu.org/41890#127
>>> to use the default project keymap 'C-x p' in 'C-x p p'. You could try to
>>> use the same keymap in 'C-x 4 p', and wrap the command call with
>>> display-buffer-override-next-command.
I'm not completely clear on the changes you're planning to C-x 4 -- do
they interact with my proposal, such that I should wait to reroll my
patch, or can I go ahead and try something equivalent to the patch in
#41890 you linked to?
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42210; Package
emacs.
(Thu, 09 Jul 2020 00:29:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 42210 <at> debbugs.gnu.org (full text, mbox):
>>>> Would it be possible to define the 'C-x 4 p' map the same way as
>>>> 'C-x p p' is defined? There is a patch in https://debbugs.gnu.org/41890#127
>>>> to use the default project keymap 'C-x p' in 'C-x p p'. You could try to
>>>> use the same keymap in 'C-x 4 p', and wrap the command call with
>>>> display-buffer-override-next-command.
>
> I'm not completely clear on the changes you're planning to C-x 4 -- do
> they interact with my proposal, such that I should wait to reroll my
> patch, or can I go ahead and try something equivalent to the patch in
> #41890 you linked to?
While it's still unclear whether the global keymap ‘C-x 4’ will be replaced
by a command, if you want, feel free to try implementing the same to a more
localized keymap ‘C-x 4 p’ based on patches in bug#41890 and on the ELPA
package ‘other-frame-window’.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42210; Package
emacs.
(Sat, 11 Jul 2020 17:10:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 42210 <at> debbugs.gnu.org (full text, mbox):
Hello Juri,
On Thu 09 Jul 2020 at 03:10AM +03, Juri Linkov wrote:
> While it's still unclear whether the global keymap ‘C-x 4’ will be replaced
> by a command, if you want, feel free to try implementing the same to a more
> localized keymap ‘C-x 4 p’ based on patches in bug#41890 and on the ELPA
> package ‘other-frame-window’.
Have taken a look at this and I think it's a good idea.
I've posted to #41890 to ask about the status of that patch since my
work will interact with it.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42210; Package
emacs.
(Sat, 18 Jul 2020 16:07:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 42210 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello Dmitry and others,
On Sun 12 Jul 2020 at 11:12PM +03, Dmitry Gutov wrote:
> There's no decision indeed. I'd like to know what people think, and if
> there's no strong opinion, how the proposal would look in practice.
>
> So unless you're strapped for time, a prototype patch would help.
Okay, here's a prototype. I had to rebase Philip's patch so I thought I
might as well attach my version of that too.
I have been wanting the new C-x 4 p bindings all week as C-x p f with
fido-mode has replaced a lot of my use of C-x C-f, so I hope I can
replace my use of C-x 4 f with C-x 4 p f soon :)
--
Sean Whitton
[0001-Use-same-keys-in-project-switch-project-as-in-projec.patch (text/x-diff, attachment)]
[0002-WIP-Add-project-other-place-commands-and-functions-w.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42210; Package
emacs.
(Sun, 19 Jul 2020 23:48:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 42210 <at> debbugs.gnu.org (full text, mbox):
On 18.07.2020 19:06, Sean Whitton wrote:
> Okay, here's a prototype. I had to rebase Philip's patch so I thought I
> might as well attach my version of that too.
The code LGTM, but I still wonder whether we do need the prompt in this
case. The downsides are that we'll need to keep the list up-to-date, and
at some point (maybe) it will grow too big to fit in the prompt. Will we
need a variable project-other-place-use-entire-map too?
Juri, did you have this particular approach in mind, or something different?
> I have been wanting the new C-x 4 p bindings all week as C-x p f with
> fido-mode has replaced a lot of my use of C-x C-f, so I hope I can
> replace my use of C-x 4 f with C-x 4 p f soon:)
I'm happy to hear that.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42210; Package
emacs.
(Mon, 20 Jul 2020 00:40:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 42210 <at> debbugs.gnu.org (full text, mbox):
>> Okay, here's a prototype. I had to rebase Philip's patch so I thought I
>> might as well attach my version of that too.
>
> The code LGTM, but I still wonder whether we do need the prompt in this
> case. The downsides are that we'll need to keep the list up-to-date, and
> at some point (maybe) it will grow too big to fit in the prompt. Will we
> need a variable project-other-place-use-entire-map too?
>
> Juri, did you have this particular approach in mind, or something different?
Indeed, this approach. I think it's a step forward. Actually two steps forward.
Both patches improve this part of project functionality greatly.
Regarding project-other-place-use-entire-map, I don't know, first need
to try using new commands for some time to see what's missing.
Currently to open a new project in a new tab I have to type:
‘C-x t t C-x p p’ then a project dir and some key e.g. ‘v’.
When Sean will turn the prototype into the final patch,
then the key sequence will be much shorter:
‘C-x t p v’.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42210; Package
emacs.
(Mon, 20 Jul 2020 01:05:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 42210 <at> debbugs.gnu.org (full text, mbox):
On 20.07.2020 03:30, Juri Linkov wrote:
> Indeed, this approach. I think it's a step forward. Actually two steps forward.
> Both patches improve this part of project functionality greatly.
>
> Regarding project-other-place-use-entire-map, I don't know, first need
> to try using new commands for some time to see what's missing.
OK then, here's a question:
Should project-other-place-commands include an entry for
project-or-external-find-file?
> Currently to open a new project in a new tab I have to type:
> ‘C-x t t C-x p p’ then a project dir and some key e.g. ‘v’.
> When Sean will turn the prototype into the final patch,
> then the key sequence will be much shorter:
> ‘C-x t p v’.
Sounds neat.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42210; Package
emacs.
(Mon, 20 Jul 2020 10:22:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 42210 <at> debbugs.gnu.org (full text, mbox):
Sean Whitton <spwhitton <at> spwhitton.name> writes:
> +(defcustom project-switch-use-entire-map t
> + "Make `project-switch-project' use entire `project-prefix-map'.
> +If nil, `project-switch-project' will only recognize commands
> +listed in `project-switch-commands', and signal an error when
> +others are invoked. Otherwise, all keys in
> +`project-switch-commands', are legal even if they aren't listed
^^^
superfluous comma
> +in the minibuffer."
> + :type 'bool
^^^
ean
> + :version "28.1")
[...]
> +;; "other-place" because non-prototype patch will also add an entry
> +;; in ctl-x-5-map and under C-x t p
> +(defcustom project-other-place-commands
> + '((project-find-file . "Find file")
> + (project-switch-to-buffer . "Switch to buffer")
> + (project-dired . "Dired")
> + ;; Eshell uses the current window by default, but Shell defaults
> + ;; to using the other window. If a user has added an entry to
> + ;; `display-buffer-alist' for Shell, they probably want to add an
> + ;; entry here, too
^^
missing full stop
> + (project-eshell . "Eshell")
> + (project-switch-project . "Switch project"))
> + "Alist mapping commands to descriptions.
> +Used by `project-other-window-command' to construct a dispatch menu of
> +commands available to be displayed in another window.
> +
> +Commands in this list should be ones which normally display their
> +buffer in the current window.
> +
> Each element looks like (COMMAND LABEL), where COMMAND should be
> bound in `project-prefix-map'. LABEL is used to distinguish the
> choice in the dispatch menu."
Thanks,
--
Basil
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42210; Package
emacs.
(Mon, 20 Jul 2020 14:46:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 42210 <at> debbugs.gnu.org (full text, mbox):
> From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
> Date: Mon, 20 Jul 2020 13:21:22 +0300
> Cc: "Philip K." <philip <at> warpmail.net>, 41890 <at> debbugs.gnu.org,
> 42210 <at> debbugs.gnu.org, Dmitry Gutov <dgutov <at> yandex.ru>, juri <at> linkov.net
>
> Sean Whitton <spwhitton <at> spwhitton.name> writes:
>
> > +(defcustom project-switch-use-entire-map t
> > + "Make `project-switch-project' use entire `project-prefix-map'.
> > +If nil, `project-switch-project' will only recognize commands
> > +listed in `project-switch-commands', and signal an error when
> > +others are invoked. Otherwise, all keys in
> > +`project-switch-commands', are legal even if they aren't listed
> ^^^
> superfluous comma
Also, GNU standards frown on using "legal" when you actually mean
"valid". "Legal" and "illegal" should be reserved to describing
issues pertaining to laws and breaking the laws.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42210; Package
emacs.
(Mon, 20 Jul 2020 16:50:03 GMT)
Full text and
rfc822 format available.
Message #56 received at 42210 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Mon 20 Jul 2020 at 02:46AM +03, Dmitry Gutov wrote:
> On 18.07.2020 19:06, Sean Whitton wrote:
>> Okay, here's a prototype. I had to rebase Philip's patch so I thought I
>> might as well attach my version of that too.
>
> The code LGTM, but I still wonder whether we do need the prompt in this
> case. The downsides are that we'll need to keep the list up-to-date, and
> at some point (maybe) it will grow too big to fit in the prompt. Will we
> need a variable project-other-place-use-entire-map too?
If all one has in mind is C-x 4, then it doesn't seem like this is a big
danger -- many commands display in the other window by default, such as
project-find-regexp, and it reasonable to guess that a good proportion
of new commands which get added will also be like this.
However, if you have C-x 5 and C-x t in mind as well, then it starts to
seem like we'll want project-other-place-use-entire-map.
How about having a project-other-window-commands defcustom for C-x 4 p,
and using the entirety of project-prefix-map for C-x 5 p and C-x t t?
C-x 4 p can prompt as per my patch, and C-x 5 p and C-x t t could just
put a static message in the minibuffer like other-frame-prefix and
other-tab-prefix do at present.
>> I have been wanting the new C-x 4 p bindings all week as C-x p f with
>> fido-mode has replaced a lot of my use of C-x C-f, so I hope I can
>> replace my use of C-x 4 f with C-x 4 p f soon:)
>
> I'm happy to hear that.
I intended to say a bit more: C-x p f has replaced a lot of my use of
C-x b too. It is very nice not to have to guess whether something is
already visited and just complete across all the project's files. I use
C-x 4 b a lot so I'm looking forward to C-x 4 p f.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42210; Package
emacs.
(Mon, 20 Jul 2020 20:57:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 42210 <at> debbugs.gnu.org (full text, mbox):
> How about having a project-other-window-commands defcustom for C-x 4 p,
> and using the entirety of project-prefix-map for C-x 5 p and C-x t t?
> C-x 4 p can prompt as per my patch, and C-x 5 p and C-x t t could just
> put a static message in the minibuffer like other-frame-prefix and
> other-tab-prefix do at present.
Currently there are separate key sequences ‘C-x p’ and ‘C-x p p’
followed by almost the same list of possibles suffixes, where e.g.
‘C-x p f’ visits a file of the current project, whereas ‘C-x p p f’
prompts for another project and visits its file.
Should the same distinction be preserved in other-place commands?
Then ‘C-x 4 p f’ will visit a file of the current project in another
window, whereas ‘C-x 4 p p f’ will prompt for another project and visit
its file in another window. The same distinction could apply also to
‘C-x 5 p f’ / ‘C-x 5 p p f’ and ‘C-x t p f’ / ‘C-x t p p f’.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42210; Package
emacs.
(Mon, 20 Jul 2020 20:57:03 GMT)
Full text and
rfc822 format available.
Message #62 received at 42210 <at> debbugs.gnu.org (full text, mbox):
> OK then, here's a question:
>
> Should project-other-place-commands include an entry for
> project-or-external-find-file?
I don't see why someone might want to use such commands as
project-or-external-find-file or project-or-external-find-regexp.
These commands operate on some obscure directories
(copied from the output of '(project-external-roots (project-current t))'):
"/usr/local/share/emacs/site-lisp/"
"/usr/share/emacs/site-lisp/autoconf/"
"/usr/share/emacs/site-lisp/gtk-doc-tools/"
...
I don't know why the user might want to find files or search in such
non-project directories as /usr/share/emacs/site-lisp/gtk-doc-tools/.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42210; Package
emacs.
(Mon, 20 Jul 2020 21:02:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 42210 <at> debbugs.gnu.org (full text, mbox):
On 20.07.2020 23:47, Juri Linkov wrote:
> I don't know why the user might want to find files or search in such
> non-project directories as/usr/share/emacs/site-lisp/gtk-doc-tools/
Apparently these directories are in your load-path.
I think it makes sense to search for files across your load path sometimes.
Or if you have multiple tag files loaded, it would search across
directories containing those files.
And that's just with the built-in backend. Other projects can have other
examples of what constitutes external roots.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42210; Package
emacs.
(Mon, 20 Jul 2020 21:04:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 42210 <at> debbugs.gnu.org (full text, mbox):
On 20.07.2020 23:41, Juri Linkov wrote:
> Should the same distinction be preserved in other-place commands?
> Then ‘C-x 4 p f’ will visit a file of the current project in another
> window, whereas ‘C-x 4 p p f’ will prompt for another project and visit
> its file in another window.
Sure.
Doesn't this work with the latest proposed patch?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42210; Package
emacs.
(Mon, 20 Jul 2020 21:25:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 42210 <at> debbugs.gnu.org (full text, mbox):
Hello Juri,
On Mon 20 Jul 2020 at 11:41PM +03, Juri Linkov wrote:
>> How about having a project-other-window-commands defcustom for C-x 4 p,
>> and using the entirety of project-prefix-map for C-x 5 p and C-x t t?
>> C-x 4 p can prompt as per my patch, and C-x 5 p and C-x t t could just
>> put a static message in the minibuffer like other-frame-prefix and
>> other-tab-prefix do at present.
>
> Currently there are separate key sequences ‘C-x p’ and ‘C-x p p’
> followed by almost the same list of possibles suffixes, where e.g.
> ‘C-x p f’ visits a file of the current project, whereas ‘C-x p p f’
> prompts for another project and visits its file.
>
> Should the same distinction be preserved in other-place commands?
> Then ‘C-x 4 p f’ will visit a file of the current project in another
> window, whereas ‘C-x 4 p p f’ will prompt for another project and visit
> its file in another window. The same distinction could apply also to
> ‘C-x 5 p f’ / ‘C-x 5 p p f’ and ‘C-x t p f’ / ‘C-x t p p f’.
Yes, I think so, but I'm not sure how that directly addresses the
suggestion of mine you quote.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42210; Package
emacs.
(Mon, 20 Jul 2020 22:01:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 42210 <at> debbugs.gnu.org (full text, mbox):
On 20.07.2020 19:49, Sean Whitton wrote:
> How about having a project-other-window-commands defcustom for C-x 4 p,
> and using the entirety of project-prefix-map for C-x 5 p and C-x t t?
> C-x 4 p can prompt as per my patch, and C-x 5 p and C-x t t could just
> put a static message in the minibuffer like other-frame-prefix and
> other-tab-prefix do at present.
Just to clarify: are you proposing this because you really like how the
prompt works, yet can't find a good way to incorporate it for the two
other prefixes?
> I intended to say a bit more: C-x p f has replaced a lot of my use of
> C-x b too. It is very nice not to have to guess whether something is
> already visited and just complete across all the project's files. I use
> C-x 4 b a lot so I'm looking forward to C-x 4 p f.
Right! That mirrors my experience: it's often handy to just search
across the project files because you're guaranteed to find the needed
file, and because there is no ambiguity caused by having only the base
name available.
One can also "guess" the eventual file name based on the partial matches
in its name and in its parent directories' names.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42210; Package
emacs.
(Tue, 21 Jul 2020 00:34:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 42210 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Tue 21 Jul 2020 at 01:00AM +03, Dmitry Gutov wrote:
> On 20.07.2020 19:49, Sean Whitton wrote:
>
>> How about having a project-other-window-commands defcustom for C-x 4 p,
>> and using the entirety of project-prefix-map for C-x 5 p and C-x t t?
>> C-x 4 p can prompt as per my patch, and C-x 5 p and C-x t t could just
>> put a static message in the minibuffer like other-frame-prefix and
>> other-tab-prefix do at present.
>
> Just to clarify: are you proposing this because you really like how the
> prompt works, yet can't find a good way to incorporate it for the two
> other prefixes?
I wouldn't say that I really like the prompt, but it could be useful to
someone to see the bindings available to them, when we're sure it's
going to fit.
I do think we should avoid binding commands under C-x 4 where the
versions under C-x p would already display in another window -- I think
it is potentially quite confusing to have bindings with identical
behaviour under both C-x 4 p and C-x p.
But that means we need the defcustom, because a user could use
display-buffer-alist to change which commands under C-x p will use
another window.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42210; Package
emacs.
(Tue, 21 Jul 2020 23:41:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 42210 <at> debbugs.gnu.org (full text, mbox):
>>> How about having a project-other-window-commands defcustom for C-x 4 p,
>>> and using the entirety of project-prefix-map for C-x 5 p and C-x t t?
>>> C-x 4 p can prompt as per my patch, and C-x 5 p and C-x t t could just
>>> put a static message in the minibuffer like other-frame-prefix and
>>> other-tab-prefix do at present.
>>
>> Just to clarify: are you proposing this because you really like how the
>> prompt works, yet can't find a good way to incorporate it for the two
>> other prefixes?
>
> I wouldn't say that I really like the prompt, but it could be useful to
> someone to see the bindings available to them, when we're sure it's
> going to fit.
While the prompt is active, the key '?' and 'C-h' could (and I think should)
display a list of *ALL* available key bindings from the project keymap
in the *Help* buffer (like e.g. 'query-replace' does after typing 'C-h').
> I do think we should avoid binding commands under C-x 4 where the
> versions under C-x p would already display in another window -- I think
> it is potentially quite confusing to have bindings with identical
> behaviour under both C-x 4 p and C-x p.
Shouldn't some key sequence force displaying the project buffer in the
same window (when a version under C-x p displays it in another window)?
> But that means we need the defcustom, because a user could use
> display-buffer-alist to change which commands under C-x p will use
> another window.
I now understand that your top message above implies that a user
could customize display-buffer-alist to display a buffer in another window,
but usually users don't customize display-buffer-alist to display a buffer
in another frame/tab?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42210; Package
emacs.
(Wed, 22 Jul 2020 00:39:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 42210 <at> debbugs.gnu.org (full text, mbox):
On 22.07.2020 02:38, Juri Linkov wrote:
>>> Just to clarify: are you proposing this because you really like how the
>>> prompt works, yet can't find a good way to incorporate it for the two
>>> other prefixes?
>>
>> I wouldn't say that I really like the prompt, but it could be useful to
>> someone to see the bindings available to them, when we're sure it's
>> going to fit.
That's a valid benefit.
There is also a package called 'which-key', but I think it's
incompatible with the implementation strategy here.
> While the prompt is active, the key '?' and 'C-h' could (and I think should)
> display a list of *ALL* available key bindings from the project keymap
> in the *Help* buffer (like e.g. 'query-replace' does after typing 'C-h').
If we're using the prompt, it shows all allowed bindings already.
> Shouldn't some key sequence force displaying the project buffer in the
> same window (when a version under C-x p displays it in another window)?
At the moment, there's none.
>> But that means we need the defcustom, because a user could use
>> display-buffer-alist to change which commands under C-x p will use
>> another window.
>
> I now understand that your top message above implies that a user
> could customize display-buffer-alist to display a buffer in another window,
> but usually users don't customize display-buffer-alist to display a buffer
> in another frame/tab?
Either way, I think the concern that someone could type 'C-x p 4 g' and
see that the search results are *still* displayed in another window
(gasp), is not too significant.
Like, there's no other behavior that should result from key sequence,
and if someone wanted to make doubly sure the resulting buffer will be
displayed in the other window, why not let them.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42210; Package
emacs.
(Wed, 22 Jul 2020 01:32:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 42210 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Wed 22 Jul 2020 at 02:38AM +03, Juri Linkov wrote:
> While the prompt is active, the key '?' and 'C-h' could (and I think should)
> display a list of *ALL* available key bindings from the project keymap
> in the *Help* buffer (like e.g. 'query-replace' does after typing 'C-h').
What would determine which of the bindings get shown in the prompt,
then, supposing there were too many to fit them all?
>> I do think we should avoid binding commands under C-x 4 where the
>> versions under C-x p would already display in another window -- I think
>> it is potentially quite confusing to have bindings with identical
>> behaviour under both C-x 4 p and C-x p.
>
> Shouldn't some key sequence force displaying the project buffer in the
> same window (when a version under C-x p displays it in another window)?
It's hard to know what key sequence to use.
>> But that means we need the defcustom, because a user could use
>> display-buffer-alist to change which commands under C-x p will use
>> another window.
>
> I now understand that your top message above implies that a user
> could customize display-buffer-alist to display a buffer in another window,
> but usually users don't customize display-buffer-alist to display a buffer
> in another frame/tab?
I exclusively use it to display buffers in other windows :)
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42210; Package
emacs.
(Wed, 22 Jul 2020 01:34:02 GMT)
Full text and
rfc822 format available.
Message #89 received at 42210 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Wed 22 Jul 2020 at 03:38AM +03, Dmitry Gutov wrote:
> Either way, I think the concern that someone could type 'C-x p 4 g' and
> see that the search results are *still* displayed in another window
> (gasp), is not too significant.
I think it could be a barrier to learning how to use project.el -- it's
weird for the same thing to be bound to two places, so the user might
think they've misunderstood something when they see it happen.
> Like, there's no other behavior that should result from key sequence,
> and if someone wanted to make doubly sure the resulting buffer will be
> displayed in the other window, why not let them.
This makes sense, and would be useful, so probably overrides my worry
about it being harder to learn. So, shall I prepare a new patch which
just uses the whole prefix map and drops the defcustom?
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42210; Package
emacs.
(Wed, 22 Jul 2020 19:31:02 GMT)
Full text and
rfc822 format available.
Message #92 received at 42210 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Tue 21 Jul 2020 at 06:33PM -07, Sean Whitton wrote:
> On Wed 22 Jul 2020 at 03:38AM +03, Dmitry Gutov wrote:
>
>> Like, there's no other behavior that should result from key sequence,
>> and if someone wanted to make doubly sure the resulting buffer will be
>> displayed in the other window, why not let them.
>
> This makes sense, and would be useful, so probably overrides my worry
> about it being harder to learn. So, shall I prepare a new patch which
> just uses the whole prefix map and drops the defcustom?
Hmm, a further complication: I would like to be able to bind C-x 4 p C-o
to work like C-x 4 C-o.
I think this could be achieved by having an additional keymap, and the
command bound to C-x 4 p can look up keys in both project-prefix-map and
this new keymap.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42210; Package
emacs.
(Thu, 23 Jul 2020 00:37:02 GMT)
Full text and
rfc822 format available.
Message #95 received at 42210 <at> debbugs.gnu.org (full text, mbox):
>> While the prompt is active, the key '?' and 'C-h' could (and I think should)
>> display a list of *ALL* available key bindings from the project keymap
>> in the *Help* buffer (like e.g. 'query-replace' does after typing 'C-h').
>
> What would determine which of the bindings get shown in the prompt,
> then, supposing there were too many to fit them all?
Maybe it's possible to show all them by using 'read-char-choice' when only
the initial letters are displayed in the prompt like "(f, g, d, v, s, ?): "
or using 'read-answer' or 'read-multiple-choice', e.g.:
(read-multiple-choice "Select project"
'((?f "Find file")
(?g "Find regexp")
(?d "dired")
(?v "vc-dir")
(?s "shell")))
>>> I do think we should avoid binding commands under C-x 4 where the
>>> versions under C-x p would already display in another window -- I think
>>> it is potentially quite confusing to have bindings with identical
>>> behaviour under both C-x 4 p and C-x p.
>>
>> Shouldn't some key sequence force displaying the project buffer in the
>> same window (when a version under C-x p displays it in another window)?
>
> It's hard to know what key sequence to use.
Indeed, it's hard to find a key prefix analogous to 'C-x 4 1'.
Maybe 'C-x 4 1 p'?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42210; Package
emacs.
(Thu, 23 Jul 2020 15:08:01 GMT)
Full text and
rfc822 format available.
Message #98 received at 42210 <at> debbugs.gnu.org (full text, mbox):
Hello Juri,
On Thu 23 Jul 2020 at 03:32AM +03, Juri Linkov wrote:
>>> While the prompt is active, the key '?' and 'C-h' could (and I think should)
>>> display a list of *ALL* available key bindings from the project keymap
>>> in the *Help* buffer (like e.g. 'query-replace' does after typing 'C-h').
>>
>> What would determine which of the bindings get shown in the prompt,
>> then, supposing there were too many to fit them all?
>
> Maybe it's possible to show all them by using 'read-char-choice' when only
> the initial letters are displayed in the prompt like "(f, g, d, v, s, ?): "
> or using 'read-answer' or 'read-multiple-choice', e.g.:
>
> (read-multiple-choice "Select project"
> '((?f "Find file")
> (?g "Find regexp")
> (?d "dired")
> (?v "vc-dir")
> (?s "shell")))
If we're only displaying single letters, then I'm not sure there is much
point in prompting at all? Either someone knows what letter to press or
they don't -- in either case the prompt seems useless.
>>>> I do think we should avoid binding commands under C-x 4 where the
>>>> versions under C-x p would already display in another window -- I think
>>>> it is potentially quite confusing to have bindings with identical
>>>> behaviour under both C-x 4 p and C-x p.
>>>
>>> Shouldn't some key sequence force displaying the project buffer in the
>>> same window (when a version under C-x p displays it in another window)?
>>
>> It's hard to know what key sequence to use.
>
> Indeed, it's hard to find a key prefix analogous to 'C-x 4 1'.
> Maybe 'C-x 4 1 p'?
I'd be cautious about this, because it breaks the general semantics of
C-x 4 1. It seems reasonable that someone might have a major-mode in
which 'p' displays another buffer, and then they might want to use C-x 4
1 to reuse the same window.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42210; Package
emacs.
(Thu, 23 Jul 2020 23:47:02 GMT)
Full text and
rfc822 format available.
Message #101 received at 42210 <at> debbugs.gnu.org (full text, mbox):
On 22.07.2020 22:28, Sean Whitton wrote:
>> This makes sense, and would be useful, so probably overrides my worry
>> about it being harder to learn. So, shall I prepare a new patch which
>> just uses the whole prefix map and drops the defcustom?
Since we're struggling between the choices, and you don't feel a strong
attachment to the prompt either, yes, please.
Then we can install it and maybe continue the discussion of an optional
patch which will add the prompt on top of it.
> Hmm, a further complication: I would like to be able to bind C-x 4 p C-o
> to work like C-x 4 C-o.
>
> I think this could be achieved by having an additional keymap, and the
> command bound to C-x 4 p can look up keys in both project-prefix-map and
> this new keymap.
Yup. The new keymap could inherit from project-prefix-map, then the
lookup should be just one funcall.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42210; Package
emacs.
(Fri, 24 Jul 2020 02:05:02 GMT)
Full text and
rfc822 format available.
Message #104 received at 42210 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello,
On Fri 24 Jul 2020 at 02:46AM +03, Dmitry Gutov wrote:
> On 22.07.2020 22:28, Sean Whitton wrote:
>>> [...]
>
> Since we're struggling between the choices, and you don't feel a strong
> attachment to the prompt either, yes, please.
>
> Then we can install it and maybe continue the discussion of an optional
> patch which will add the prompt on top of it.
Cool, what do you think to the attached?
>> Hmm, a further complication: I would like to be able to bind C-x 4 p C-o
>> to work like C-x 4 C-o.
>>
>> I think this could be achieved by having an additional keymap, and the
>> command bound to C-x 4 p can look up keys in both project-prefix-map and
>> this new keymap.
>
> Yup. The new keymap could inherit from project-prefix-map, then the
> lookup should be just one funcall.
In the end I didn't use inheritance; hopefully it is clear from the
patch why I thought this would not be a good idea.
--
Sean Whitton
[0001-Add-project-display-buffer-and-project-display-buffe.patch (text/x-diff, attachment)]
[0002-Add-project-other-place-commands.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42210; Package
emacs.
(Fri, 24 Jul 2020 06:02:02 GMT)
Full text and
rfc822 format available.
Message #107 received at 42210 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 23 Jul 2020 19:04:13 -0700
> Cc: "Basil L. Contovounesios" <contovob <at> tcd.ie>,
> "Philip K." <philip <at> warpmail.net>, 41890 <at> debbugs.gnu.org,
> 42210 <at> debbugs.gnu.org
>
> -(defun project-switch-to-buffer ()
> +(defun project-switch-to-buffer (&optional switching-function)
> "Switch to another buffer belonging to the current project.
> This function prompts for another buffer, offering as candidates
> buffers that belong to the same project as the current buffer.
> Two buffers belong to the same project if their project instances,
> -as reported by `project-current' in each buffer, are identical."
> +as reported by `project-current' in each buffer, are identical.
> +
> +Optional argument SWITCHING-FUNCTION is the function used to
> +switch the buffer. It defaults to `switch-to-buffer'."
> (interactive)
This interface strikes me as unusual and even unexpected for a command
that switches to another buffer. I would expect it to have an API
similar to that of switch-to-buffer: that it should accept the buffer
to switch to as an argument, and set up that argument in the
'interactive' spec according to the preferences of this command
(offering buffers in the same project etc.). The API you propose
makes it awkward, to say the least, to invoke this command from Lisp.
Granted, the original API doesn't allow such invocation, either, but
as long as we are changing this API, let's try fixing that, okay?
> +(defun project-display-buffer ()
> + "Display a buffer of the current project without selecting it.
This doesn't say where that buffer will be displayed. Please add that
important detail to the doc string.
> +(defun project-display-buffer-other-frame ()
> + "Display a buffer of the current project, preferably in another frame.
> +
> +See `project-switch-to-buffer' for what it means for a buffer to
> +belong to the current project."
The "preferably" part needs to be explained some more, perhaps by
pointing to display-buffer-other-frame for the details. Otherwise it
leaves some of the command's MO a mystery.
> +(defvar project-other-window-map
> + (let ((map (make-sparse-keymap)))
> + (define-key map "\C-o" #'project-display-buffer)
> + map)
> + "Keymap for additional project commands to display in other windows.")
Do you mean "commands _that_ display in other windows"? If so, please
use "that" instead of "to". Also, I think the doc string should
explain what do those commands display in those other windows.
> +(defvar project-other-frame-map
> + (let ((map (make-sparse-keymap)))
> + (define-key map "\C-o" #'project-display-buffer-other-frame)
> + map)
> + "Keymap for additional project commands to display in other frames.")
Same here.
> +;;;###autoload
> +(defun project-other-window-command ()
> + "Invoke a project command but display its buffer in another window.
^
Comma is missing there.
More importantly, the "its" part is ambiguous. What does it allude
to?
> +(defun project-other-frame-command ()
> + "Invoke a project command but display its buffer in another frame.
Same here.
> +(defun project-other-tab-command ()
> + "Invoke a project command but display its buffer in another tab.
Same here, except that in this case even the idea of "displaying in a
tab" is unclear. This needs rewording.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42210; Package
emacs.
(Fri, 24 Jul 2020 15:13:02 GMT)
Full text and
rfc822 format available.
Message #110 received at 42210 <at> debbugs.gnu.org (full text, mbox):
Hello Eli,
On Fri 24 Jul 2020 at 09:01AM +03, Eli Zaretskii wrote:
>> Date: Thu, 23 Jul 2020 19:04:13 -0700
>> Cc: "Basil L. Contovounesios" <contovob <at> tcd.ie>,
>> "Philip K." <philip <at> warpmail.net>, 41890 <at> debbugs.gnu.org,
>> 42210 <at> debbugs.gnu.org
>>
>> -(defun project-switch-to-buffer ()
>> +(defun project-switch-to-buffer (&optional switching-function)
>> "Switch to another buffer belonging to the current project.
>> This function prompts for another buffer, offering as candidates
>> buffers that belong to the same project as the current buffer.
>> Two buffers belong to the same project if their project instances,
>> -as reported by `project-current' in each buffer, are identical."
>> +as reported by `project-current' in each buffer, are identical.
>> +
>> +Optional argument SWITCHING-FUNCTION is the function used to
>> +switch the buffer. It defaults to `switch-to-buffer'."
>> (interactive)
>
> This interface strikes me as unusual and even unexpected for a command
> that switches to another buffer. I would expect it to have an API
> similar to that of switch-to-buffer: that it should accept the buffer
> to switch to as an argument, and set up that argument in the
> 'interactive' spec according to the preferences of this command
> (offering buffers in the same project etc.). The API you propose
> makes it awkward, to say the least, to invoke this command from Lisp.
I added the argument just so I could reuse the code in
project-switch-to-buffer, so a simple alternative for the purposes of my
patch would be to factor that code out into a new
project--select-project-buffer defun. Then no existing APIs would be
changed.
Would that be sufficient?
> Granted, the original API doesn't allow such invocation, either, but
> as long as we are changing this API, let's try fixing that, okay?
This is a bit tricky actually -- what should the function do if some
Lisp code passes it a buffer which is not part of the current project?
Throw an error? But then surely the Lisp code would prefer to just
check if the buffer is part of the project itself, and use
switch-to-buffer.
I'd be grateful if you could say more about the sort of Lisp code you
have in mind. I'm struggling to imagine wanting to call this function
from Lisp except via call-interactively.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42210; Package
emacs.
(Fri, 24 Jul 2020 16:14:02 GMT)
Full text and
rfc822 format available.
Message #113 received at 42210 <at> debbugs.gnu.org (full text, mbox):
> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Cc: dgutov <at> yandex.ru, juri <at> linkov.net, contovob <at> tcd.ie, philip <at> warpmail.net,
> 41890 <at> debbugs.gnu.org, 42210 <at> debbugs.gnu.org
> Date: Fri, 24 Jul 2020 08:12:13 -0700
>
> > This interface strikes me as unusual and even unexpected for a command
> > that switches to another buffer. I would expect it to have an API
> > similar to that of switch-to-buffer: that it should accept the buffer
> > to switch to as an argument, and set up that argument in the
> > 'interactive' spec according to the preferences of this command
> > (offering buffers in the same project etc.). The API you propose
> > makes it awkward, to say the least, to invoke this command from Lisp.
>
> I added the argument just so I could reuse the code in
> project-switch-to-buffer, so a simple alternative for the purposes of my
> patch would be to factor that code out into a new
> project--select-project-buffer defun. Then no existing APIs would be
> changed.
>
> Would that be sufficient?
What you added is not my problem, my problem is that there's no easy
way of calling this function from Lisp.
> > Granted, the original API doesn't allow such invocation, either, but
> > as long as we are changing this API, let's try fixing that, okay?
>
> This is a bit tricky actually -- what should the function do if some
> Lisp code passes it a buffer which is not part of the current project?
Just switch to that buffer, I think.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42210; Package
emacs.
(Fri, 24 Jul 2020 21:22:02 GMT)
Full text and
rfc822 format available.
Message #116 received at 42210 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello,
On Fri 24 Jul 2020 at 07:12PM +03, Eli Zaretskii wrote:
> Just switch to that buffer, I think.
Okay, then I think the attached addresses feedback received. Thanks!
--
Sean Whitton
[v2-0001-Factor-out-project-read-project-buffer-from-proje.patch (text/x-diff, attachment)]
[v2-0002-Add-project-display-buffer-and-project-display-bu.patch (text/x-diff, attachment)]
[v2-0003-Add-project-other-place-commands.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42210; Package
emacs.
(Fri, 24 Jul 2020 22:55:02 GMT)
Full text and
rfc822 format available.
Message #119 received at 42210 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Sean,
On 25.07.2020 00:20, Sean Whitton wrote:
> Okay, then I think the attached addresses feedback received. Thanks!
These are good patches, working well.
But here's a change on top of yours that simplified things a little, and
makes a few things unnecessary (I think). All by using the variable
called switch-to-buffer-obey-display-actions.
What do you and others think?
I'll easily admit to being out of my depth when it comes to window
management, so if there are reasons to go with the full-on approach, no
objections from me.
[project-other-place-shorter.diff (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42210; Package
emacs.
(Fri, 24 Jul 2020 23:14:02 GMT)
Full text and
rfc822 format available.
Message #122 received at 42210 <at> debbugs.gnu.org (full text, mbox):
Hello Dmitry,
Thanks for taking a look.
On Sat 25 Jul 2020 at 01:54AM +03, Dmitry Gutov wrote:
> On 25.07.2020 00:20, Sean Whitton wrote:
>> Okay, then I think the attached addresses feedback received. Thanks!
>
> These are good patches, working well.
>
> But here's a change on top of yours that simplified things a little, and
> makes a few things unnecessary (I think). All by using the variable
> called switch-to-buffer-obey-display-actions.
>
> What do you and others think?
I don't think this is going to work, for two reasons:
- for consistency with the existing C-x 4 C-o binding, C-x 4 p C-o
should be bound to project-display-buffer, but C-x p C-o should not,
so we cannot add the C-o binding to project-prefix-map, so another map
is needed
- I suspect that by relying on switch-to-buffer-obey-display-actions,
when you use project-display-buffer the other window will end up
selected, which is not meant to happen.
> I'll easily admit to being out of my depth when it comes to window
> management, so if there are reasons to go with the full-on approach, no
> objections from me.
Right, it's really complicated, so I wrote the patch as conservatively
as possible.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42210; Package
emacs.
(Fri, 24 Jul 2020 23:46:02 GMT)
Full text and
rfc822 format available.
Message #125 received at 42210 <at> debbugs.gnu.org (full text, mbox):
On 25.07.2020 02:13, Sean Whitton wrote:
> I don't think this is going to work, for two reasons:
>
> - for consistency with the existing C-x 4 C-o binding, C-x 4 p C-o
> should be bound to project-display-buffer, but C-x p C-o should not,
> so we cannot add the C-o binding to project-prefix-map, so another map
> is needed
>
> - I suspect that by relying on switch-to-buffer-obey-display-actions,
> when you use project-display-buffer the other window will end up
> selected, which is not meant to happen.
Fair enough, thank you.
I'll wait a day or two for the others to have a chance to leave some
closing feedback, and then it's off to master.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42210; Package
emacs.
(Sat, 25 Jul 2020 06:16:02 GMT)
Full text and
rfc822 format available.
Message #128 received at 42210 <at> debbugs.gnu.org (full text, mbox):
> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Cc: dgutov <at> yandex.ru, juri <at> linkov.net, contovob <at> tcd.ie, philip <at> warpmail.net,
> 41890 <at> debbugs.gnu.org, 42210 <at> debbugs.gnu.org
> Date: Fri, 24 Jul 2020 14:20:59 -0700
>
> Okay, then I think the attached addresses feedback received. Thanks!
Thanks, I have only one minor comment:
> +(defun project-display-buffer (buffer-or-name)
> + "Display BUFFER-OR-NAME in some window, without selecting it.
> +When called interactively, prompts for a buffer belonging to the
> +current project. Two buffers belong to the same project if their
> +project instances, as reported by `project-current' in each
> +buffer, are identical."
This doc string should mention display-buffer, for the same reasons
and with the same surrounding test as how
project-display-buffer-other-frame mentions
display-buffer-other-frame.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42210; Package
emacs.
(Sun, 26 Jul 2020 05:16:02 GMT)
Full text and
rfc822 format available.
Message #131 received at 42210 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello,
On Sat 25 Jul 2020 at 09:14AM +03, Eli Zaretskii wrote:
> This doc string should mention display-buffer, for the same reasons
> and with the same surrounding test as how
> project-display-buffer-other-frame mentions
> display-buffer-other-frame.
Thank you, fixed, along with fixing some references to function
arguments which were incorrect in the previous series (they were
'buffer-or-name' in one place but 'buffer' in another).
--
Sean Whitton
[v3-0001-Factor-out-project-read-project-buffer-from-proje.patch (text/x-diff, attachment)]
[v3-0002-Add-project-display-buffer-and-project-display-bu.patch (text/x-diff, attachment)]
[v3-0003-Add-project-other-place-commands.patch (text/x-diff, attachment)]
Reply sent
to
Dmitry Gutov <dgutov <at> yandex.ru>:
You have taken responsibility.
(Mon, 27 Jul 2020 00:02:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Sean Whitton <spwhitton <at> spwhitton.name>:
bug acknowledged by developer.
(Mon, 27 Jul 2020 00:02:02 GMT)
Full text and
rfc822 format available.
Message #136 received at 42210-done <at> debbugs.gnu.org (full text, mbox):
On 26.07.2020 08:15, Sean Whitton wrote:
> Thank you, fixed, along with fixing some references to function
> arguments which were incorrect in the previous series (they were
> 'buffer-or-name' in one place but 'buffer' in another).
Applied and pushed. Thanks all!
With that, I'm closing the associated bug report.
Please file new reports for any follow-up patches.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Mon, 24 Aug 2020 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 243 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.