* Dedicated window for *log-edit-files*
@ 2019-10-25 11:48 João Távora
2019-10-25 12:48 ` Stefan Monnier
` (2 more replies)
0 siblings, 3 replies; 13+ messages in thread
From: João Távora @ 2019-10-25 11:48 UTC (permalink / raw
To: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 891 bytes --]
When finalizing a commit with VC, (I usually do it from vc-next-action
but maybe there are other ways), a buffer and a window popup for
*log-edit-files*, showing the files touched by the "commit" (here
I'm using "commit" to designate the corresponding VC action
across VCSystems).
For me personally, the window is quite annoying because it's
in the path of my "C-x o" workflow: very frequently I want to jump
back to the source buffer to do some last minute adjustment.
My questions are:
1. can I get rid of the `*log-edit-files*` window & buffer?
1.2. what about just the window?
2. does the buffer serve any other purpose besides
informing me?
3. supposing the answer to 2 is "No" would some
overlay text in the *vc-log* buffer, much like the overlay
trickery that is already done there, server the same
purpose?
Would a patch that does 3 be acceptable?
João
[-- Attachment #2: Type: text/html, Size: 1442 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Dedicated window for *log-edit-files*
2019-10-25 11:48 Dedicated window for *log-edit-files* João Távora
@ 2019-10-25 12:48 ` Stefan Monnier
2019-10-25 15:36 ` João Távora
2019-10-25 14:43 ` Drew Adams
2019-10-26 8:12 ` martin rudalics
2 siblings, 1 reply; 13+ messages in thread
From: Stefan Monnier @ 2019-10-25 12:48 UTC (permalink / raw
To: João Távora; +Cc: emacs-devel
João Távora [2019-10-25 12:48:19] wrote:
> When finalizing a commit with VC, (I usually do it from vc-next-action
> but maybe there are other ways), a buffer and a window popup for
> *log-edit-files*, showing the files touched by the "commit" (here
> I'm using "commit" to designate the corresponding VC action
> across VCSystems).
>
> For me personally, the window is quite annoying because it's
> in the path of my "C-x o" workflow: very frequently I want to jump
> back to the source buffer to do some last minute adjustment.
>
> My questions are:
>
> 1. can I get rid of the `*log-edit-files*` window & buffer?
> 1.2. what about just the window?
Remove `log-edit-show-files` from `log-edit-hook`.
[ Yes, non-nil default values for non-preloaded hooks are evil.
I confess to doing it, but I plead insanity. ]
> 2. does the buffer serve any other purpose besides
> informing me?
No.
> 3. supposing the answer to 2 is "No" would some overlay text in the
> *vc-log* buffer, much like the overlay trickery that is already done
> there, server the same purpose?
That could work, but I think a separate buffer&window is just as well
(makes it easier to copy&paste, hide, etc...).
Maybe we should arrange for `C-x o` not to switch to it (on GUI frames
you could still point&click to select it in those rare cases that you
want to, not sure what UI to use for the tty case: maybe just force the
user to C-x b to the *log-edit-files* buffer in another window).
Stefan
^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: Dedicated window for *log-edit-files*
2019-10-25 11:48 Dedicated window for *log-edit-files* João Távora
2019-10-25 12:48 ` Stefan Monnier
@ 2019-10-25 14:43 ` Drew Adams
2019-10-25 15:21 ` João Távora
2019-10-26 8:12 ` martin rudalics
2 siblings, 1 reply; 13+ messages in thread
From: Drew Adams @ 2019-10-25 14:43 UTC (permalink / raw
To: João Távora, emacs-devel
Is this about a dedicated window? If so, how?
(I see "dedicated" in the Subject line but nowhere in the message body.)
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Dedicated window for *log-edit-files*
2019-10-25 14:43 ` Drew Adams
@ 2019-10-25 15:21 ` João Távora
0 siblings, 0 replies; 13+ messages in thread
From: João Távora @ 2019-10-25 15:21 UTC (permalink / raw
To: Drew Adams; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 548 bytes --]
On Fri, Oct 25, 2019 at 3:45 PM Drew Adams <drew.adams@oracle.com> wrote:
> Is this about a dedicated window? If so, how?
>
> (I see "dedicated" in the Subject line but nowhere in the message body.)
>
I believe it is, or at least I am pretty sure I tried to change buffers
interactively in the window and got the error beep. What I
actually wanted was to change buffers in the other window.
So, if indeed it is a dedicated window, that's not strictly
the reason why I am bothered by said window.
Sorry for the confusion.
João
[-- Attachment #2: Type: text/html, Size: 935 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Dedicated window for *log-edit-files*
2019-10-25 12:48 ` Stefan Monnier
@ 2019-10-25 15:36 ` João Távora
2019-10-25 15:50 ` Stefan Monnier
2019-10-29 21:37 ` Juri Linkov
0 siblings, 2 replies; 13+ messages in thread
From: João Távora @ 2019-10-25 15:36 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 590 bytes --]
On Fri, Oct 25, 2019 at 1:48 PM Stefan Monnier <monnier@iro.umontreal.ca>
wrote:
> Remove `log-edit-show-files` from `log-edit-hook`.
Oh, that works perfectly! Thanks.
> [ Yes, non-nil default values for non-preloaded hooks are evil.
> I confess to doing it, but I plead insanity. ]
Why evil? How else would you arrange to have this
default behaviour?
Not that I agree with this particular one: I think
log-edit-show-files does more harm than good,
and should be out of the default value (maybe
mentioned in the docstring). But that's another
discussion.
João
[-- Attachment #2: Type: text/html, Size: 855 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Dedicated window for *log-edit-files*
2019-10-25 15:36 ` João Távora
@ 2019-10-25 15:50 ` Stefan Monnier
2019-10-25 21:38 ` João Távora
2019-10-29 21:37 ` Juri Linkov
1 sibling, 1 reply; 13+ messages in thread
From: Stefan Monnier @ 2019-10-25 15:50 UTC (permalink / raw
To: João Távora; +Cc: emacs-devel
>> [ Yes, non-nil default values for non-preloaded hooks are evil.
>> I confess to doing it, but I plead insanity. ]
> Why evil?
Because you can't conveniently add/remove values from it (you either
have to wait for the file to be loaded to do that, or force loading it
eagerly at startup, or completely override the default value with your
own).
We discussed a few times teaching Custom how to modify lists like these
(so what is stored in your config file for this variable is morally
a sort of "diff" rather than the current result of applying the diff).
> How else would you arrange to have this default behaviour?
Typically we add ad-hoc config vars to enable/disable features instead
that also helps with discoverability. But yes, it has its own disadvantages.
Stefan
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Dedicated window for *log-edit-files*
2019-10-25 15:50 ` Stefan Monnier
@ 2019-10-25 21:38 ` João Távora
2019-10-25 23:51 ` Stefan Monnier
0 siblings, 1 reply; 13+ messages in thread
From: João Távora @ 2019-10-25 21:38 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 949 bytes --]
On Fri, Oct 25, 2019, 16:50 Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> >> [ Yes, non-nil default values for non-preloaded hooks are evil.
> >> I confess to doing it, but I plead insanity. ]
> > Why evil?
>
> Because you can't conveniently add/remove values from it (you either
> have to wait for the file to be loaded to do that, or force loading it
> eagerly at startup, or completely override the default value with your
> own).
>
Makes sense. I suppose an autoload cookie could do it, but
maybe it's kind of ugly.
> We discussed a few times teaching Custom how to modify lists like these
> (so what is stored in your config file for this variable is morally
> a sort of "diff" rather than the current result of applying the diff).
>
Yes. But it wouldn't work for Custom-hat... err... avoiders like me,
right?
Anyway, it's the first time I bump into this problem, so it mustn't
be so terrible.
João
[-- Attachment #2: Type: text/html, Size: 1662 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Dedicated window for *log-edit-files*
2019-10-25 21:38 ` João Távora
@ 2019-10-25 23:51 ` Stefan Monnier
0 siblings, 0 replies; 13+ messages in thread
From: Stefan Monnier @ 2019-10-25 23:51 UTC (permalink / raw
To: João Távora; +Cc: emacs-devel
> Makes sense. I suppose an autoload cookie could do it, but
> maybe it's kind of ugly.
Autoloaded variables are their own kind of evil ;-)
> Yes. But it wouldn't work for Custom-hat... err... avoiders like me, right?
For ... coders, you can use (with-eval-after-load 'log-edit (remove-hook
...)) or just (re)use the Custom machinery manually.
Stefan
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Dedicated window for *log-edit-files*
2019-10-25 11:48 Dedicated window for *log-edit-files* João Távora
2019-10-25 12:48 ` Stefan Monnier
2019-10-25 14:43 ` Drew Adams
@ 2019-10-26 8:12 ` martin rudalics
2019-10-26 12:00 ` Stefan Monnier
2 siblings, 1 reply; 13+ messages in thread
From: martin rudalics @ 2019-10-26 8:12 UTC (permalink / raw
To: João Távora, emacs-devel
> When finalizing a commit with VC, (I usually do it from vc-next-action
> but maybe there are other ways), a buffer and a window popup for
> *log-edit-files*, showing the files touched by the "commit" (here
> I'm using "commit" to designate the corresponding VC action
> across VCSystems).
>
> For me personally, the window is quite annoying because it's
> in the path of my "C-x o" workflow: very frequently I want to jump
> back to the source buffer to do some last minute adjustment.
Probbaly, 'log-edit-show-files' should mark the window as dedicated
only if it appears on a separate frame.
But the corresponding code is weird. For starters, wrapping some sort
of 'pop-to-buffer' in 'save-selected-window' is not reasonable IMHO.
And both, 'cvs-pop-to-buffer-same-frame' and 'cvs-bury-buffer', should
be eventually rewritten via 'display-buffer' such that "q" just quits
the associated window using its 'quit-restore' parameter.
martin
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Dedicated window for *log-edit-files*
2019-10-26 8:12 ` martin rudalics
@ 2019-10-26 12:00 ` Stefan Monnier
2019-10-27 7:49 ` martin rudalics
0 siblings, 1 reply; 13+ messages in thread
From: Stefan Monnier @ 2019-10-26 12:00 UTC (permalink / raw
To: martin rudalics; +Cc: João Távora, emacs-devel
> Probbaly, 'log-edit-show-files' should mark the window as dedicated
> only if it appears on a separate frame.
It should never appear on a separate frame, IIRC (that's the
"-same-frame" part of cvs-pop-to-buffer-same-frame).
> But the corresponding code is weird. For starters, wrapping some sort
> of 'pop-to-buffer' in 'save-selected-window' is not reasonable IMHO.
> And both, 'cvs-pop-to-buffer-same-frame' and 'cvs-bury-buffer', should
> be eventually rewritten via 'display-buffer' such that "q" just quits
> the associated window using its 'quit-restore' parameter.
Quite so,
Stefan
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Dedicated window for *log-edit-files*
2019-10-26 12:00 ` Stefan Monnier
@ 2019-10-27 7:49 ` martin rudalics
2019-10-27 17:43 ` Stefan Monnier
0 siblings, 1 reply; 13+ messages in thread
From: martin rudalics @ 2019-10-27 7:49 UTC (permalink / raw
To: Stefan Monnier; +Cc: João Távora, emacs-devel
> It should never appear on a separate frame, IIRC (that's the
> "-same-frame" part of cvs-pop-to-buffer-same-frame).
'display-buffer-pop-up-frame' is a 'display-buffer-fallback-action' so
"never" is not necessarily "never".
martin
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Dedicated window for *log-edit-files*
2019-10-27 7:49 ` martin rudalics
@ 2019-10-27 17:43 ` Stefan Monnier
0 siblings, 0 replies; 13+ messages in thread
From: Stefan Monnier @ 2019-10-27 17:43 UTC (permalink / raw
To: martin rudalics; +Cc: João Távora, emacs-devel
>> It should never appear on a separate frame, IIRC (that's the
>> "-same-frame" part of cvs-pop-to-buffer-same-frame).
> 'display-buffer-pop-up-frame' is a 'display-buffer-fallback-action' so
> "never" is not necessarily "never".
I know, but if it's always set as dedicated and will only be shown in
its own frame as a last recourse, then it's a good indication that
the original coder wanted it to be dedicated even if not shown in its
own frame ;-)
Stefan
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Dedicated window for *log-edit-files*
2019-10-25 15:36 ` João Távora
2019-10-25 15:50 ` Stefan Monnier
@ 2019-10-29 21:37 ` Juri Linkov
1 sibling, 0 replies; 13+ messages in thread
From: Juri Linkov @ 2019-10-29 21:37 UTC (permalink / raw
To: João Távora; +Cc: Stefan Monnier, emacs-devel
>> Remove `log-edit-show-files` from `log-edit-hook`.
>
> Oh, that works perfectly! Thanks.
Also it's possible to display the same window with *log-edit-files* buffer
later, after typing ‘C-c C-c’ when you don't need to switch windows,
if ‘log-edit-confirm’ is customized to ‘t’.
PS: typing ‘C-h v log-edit-confirm RET’ displays in *Help* buffer:
log-edit-confirm is a variable defined in ‘log-edit.el’.
Its value is t
Original value was changed
And indeed the original value was changed because I customized it to ‘t’,
but what was the original value? It took a while to realize that the value
itself is ‘changed’. To remove such ambiguity should it add quotes?
Original value was ‘changed’
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2019-10-29 21:37 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-10-25 11:48 Dedicated window for *log-edit-files* João Távora
2019-10-25 12:48 ` Stefan Monnier
2019-10-25 15:36 ` João Távora
2019-10-25 15:50 ` Stefan Monnier
2019-10-25 21:38 ` João Távora
2019-10-25 23:51 ` Stefan Monnier
2019-10-29 21:37 ` Juri Linkov
2019-10-25 14:43 ` Drew Adams
2019-10-25 15:21 ` João Távora
2019-10-26 8:12 ` martin rudalics
2019-10-26 12:00 ` Stefan Monnier
2019-10-27 7:49 ` martin rudalics
2019-10-27 17:43 ` Stefan Monnier
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.