Dedicated window for *log-edit-files*

Dedicated window for *log-edit-files*

[João Távora]

[-- 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 --]

Re: Dedicated window for *log-edit-files*

[Stefan Monnier]

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

RE: Dedicated window for *log-edit-files*

[Drew Adams]

Is this about a dedicated window?  If so, how?

(I see "dedicated" in the Subject line but nowhere in the message body.)

Re: Dedicated window for *log-edit-files*

[João Távora]

[-- 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 --]

Re: Dedicated window for *log-edit-files*

[João Távora]

[-- 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 --]

Re: Dedicated window for *log-edit-files*

[Stefan Monnier]

>> [ 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

Re: Dedicated window for *log-edit-files*

[João Távora]

[-- 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 --]

Re: Dedicated window for *log-edit-files*

[Stefan Monnier]

> 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

Re: Dedicated window for *log-edit-files*

[martin rudalics]

 > 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

Re: Dedicated window for *log-edit-files*

[Stefan Monnier]

> 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

Re: Dedicated window for *log-edit-files*

[martin rudalics]

 > 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

Re: Dedicated window for *log-edit-files*

[Stefan Monnier]

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

Re: Dedicated window for *log-edit-files*

[Juri Linkov]

>> 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’