bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Dmitry Gutov
Subject: bug#73387: 30.0.90; C-x v v in diff-mode doesn't work after C-c C-n
Date: Fri, 27 Sep 2024 22:13:56 +0300
User-agent: Mozilla Thunderbird

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]