From: Sean Whitton <spwhitton@spwhitton.name>
To: Dmitry Gutov <dgutov@yandex.ru>
Cc: 73387@debbugs.gnu.org, monnier@iro.umontreal.ca,
Juri Linkov <juri@linkov.net>
Subject: bug#73387: 30.0.90; C-x v v in diff-mode doesn't work after C-c C-n
Date: Mon, 30 Sep 2024 17:38:39 +0800 [thread overview]
Message-ID: <878qv9scps.fsf@melete.silentflame.com> (raw)
In-Reply-To: <a7a8ed3e-519d-4ce6-badd-bef2a8c96cf0@yandex.ru> (Dmitry Gutov's message of "Mon, 30 Sep 2024 03:27:56 +0300")
Hello,
On Mon 30 Sep 2024 at 03:27am +03, Dmitry Gutov wrote:
> On 30/09/2024 02:46, Sean Whitton wrote:
>> Hello,
>> On Fri 27 Sep 2024 at 10:13pm +03, Dmitry Gutov wrote:
>>
>>>> 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.
>> Hmm, I thought that we thought the modified buffer string approach was
>> too messy. Would you mind outlining your proposal as a whole and how it
>> differs from my most recent one?
>
> Actually, how about we start with your suggested steps, sans for the last one,
> for now. Meaning, just aborting with a message when the buffer is narrowed,
> without the user option.
>
> We would not be removing any existing functionality this way (this scenario
> didn't work before, after all), and we could add it later.
>
> Would that work for your habits/scenarios?
You mean, just adding the command which kills hunks?
--
Sean Whitton
next prev parent reply other threads:[~2024-09-30 9:38 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-20 16:08 bug#73387: 30.0.90; C-x v v in diff-mode doesn't work after C-c C-n Sean Whitton
2024-09-22 12:46 ` Sean Whitton
2024-09-23 22:41 ` Dmitry Gutov
2024-09-23 22:41 ` Dmitry Gutov
2024-09-24 6:32 ` Juri Linkov
2024-09-24 15:54 ` Sean Whitton
2024-09-24 17:36 ` Dmitry Gutov
2024-09-25 6:34 ` Sean Whitton
2024-09-25 23:46 ` Dmitry Gutov
2024-09-27 11:55 ` Sean Whitton
2024-09-27 19:13 ` Dmitry Gutov
2024-09-29 23:46 ` Sean Whitton
2024-09-30 0:27 ` Dmitry Gutov
2024-09-30 9:38 ` Sean Whitton [this message]
2024-09-30 10:11 ` Dmitry Gutov
2024-09-30 13:10 ` Sean Whitton
2024-09-30 13:25 ` Sean Whitton
2024-09-30 14:15 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878qv9scps.fsf@melete.silentflame.com \
--to=spwhitton@spwhitton.name \
--cc=73387@debbugs.gnu.org \
--cc=dgutov@yandex.ru \
--cc=juri@linkov.net \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).