bug#73387: 30.0.90; C-x v v in diff-mode doesn't work after C-c C-n

[Dmitry Gutov <dgutov@yandex.ru>]

On 27/09/2024 14:55, Sean Whitton wrote:
> Hello,
> 
> On Thu 26 Sep 2024 at 02:46am +03, Dmitry Gutov wrote:
> 
>> Suppose C-c C-n (or probably a different but similar binding) edited the diff
>> instead of applying the narrowing, in a way that retained the file header(s),
>> but keeping only the hunks intersecting the region or just the current one.
>>
>> Would that work for you just as well, or do you prefer to use narrowing
>> anyway, for some other reasons?
> 
> It would work for me, and has a few advantages:
> 
> - it means you just hit 'g' afterwards, not C-x n w and then 'g'

Yep.

Or you could use 'undo' to get back to a previous state of the buffer.

> - it fits better with our general paradigm of killing what you don't
>    want to include and then committing.
> 
> On the other hand, it doesn't seem ideal that after C-c C-n you can, for
> example, use C-c C-a or C-c M-k, but not C-x v v.  That could break you
> out of your mental flow.

Fair point, and maybe we could support both.

> What do you think about this:
> 
> - add a command which does the kill-all-but-this-hunk (or hunks in
>    region if mark active) thing -- it's generally useful.
> 
> - make C-x v v on a narrowed buffer, by default, issue a message saying
>    "Cannot commit patch when narrowed, consider <binding of new command>"

Or it would implement that previous alternative - using the modified 
buffer string that's limited to the current narrowing.

I'm somewhat concerned about supporting both approaches (how different 
are the code paths going to be?), but if that's needed for usability, 
perhaps it's okay.

> - add a user option that when non-nil means C-x v v on a narrowed buffer
>    automatically widens, invokes the new command, and then commits.

And/or Emacs could by default prompt whether it should do that. And that 
prompting behavior could indeed be decided by a user option.

> My thinking is that the latter behaviour is complex and so shouldn't be
> the default, but once you understand what's going on then there is a
> good chance you want to enable it.

Maybe if the prompt is easy enough to understand, that will be fine...