Sean Whitton <spwhit...@spwhitton.name> writes:

> Hello,
>
> On Tue 03 Sep 2024 at 04:32pm GMT, Philip Kaludercic wrote:
>
>>
>> +(defcustom kill-region-dwim nil
>> +  "Behaviour when `kill-region' is invoked without an active region.
>> +If set to nil (default), then an error occurs and nothing is killed.  If
>> +set to `emacs-word', then kill a the last word as defined by the current
>> +major mode.  If set to `unix-word', then kill the last word in the style
>> +of a shell like Bash, disregarding the major mode."
>> +  :type '(choice (const :tag "Kill a word like `backward-kill-word'" 
>> emacs-word)
>> +                 (const :tag "Kill a word like Bash would" unix-word)
>> +                 (const :tag "Do not kill anything" nil))
>> +  :group 'killing)
>
> I think I'm missing something here.  When it's nil and there is no
> *active* region, but there is a region, it should kill that, surely?
> With or without TMM.
> I very regularly kill inactive regions (e.g. after M->).

That is not an inherent problem, we can adjust the patch by

diff --git a/lisp/simple.el b/lisp/simple.el
index 3b4453c7a8f..9d4d5bcd10c 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -5865,11 +5865,11 @@ kill-region
                  (let ((beg (mark))
                        (end (point)))
                    (cond
-                    ((and beg end (use-region-p))
-                     (list beg end 'region))
-                    (kill-region-dwim
+                    ((and kill-region-dwim (not (use-region-p)))
                      (list beg end kill-region-dwim))
-                    ((user-error "The mark is not set now, so there is no 
region"))))))
+                    ((not (or beg end))
+                     (user-error "The mark is not set now, so there is no 
region"))
+                    ((list beg end 'region))))))
 
   (condition-case nil
       (let ((string (cond
to fix that issue.

>> +                     ((eq region 'unix-word)
>> +                      (let ((end (point)))
>> +                        (save-excursion
>> +                          (skip-chars-backward "[:space:]")
>> +                          (skip-chars-backward "^[:space:]")
>> +                          (filter-buffer-substring
>> +                           (if (get-char-property (point) 'read-only)
>> +                               (next-single-char-property-change
>> +                                (point) 'read-only nil end)
>> +                             (point))
>> +                           end 'delete))))
>> +                     (region
>> +                      (funcall region-extract-function 'delete))
>> +                     ((filter-buffer-substring beg end 'delete)))))
>
> Shall I rather commit this as an independent unix-word-rubout?
>
> Improves attribution, and it's independently useful.

As a standalone command?

Eli Zaretskii <e...@gnu.org> writes:

>> From: Sean Whitton <spwhit...@spwhitton.name>
>> Cc: Eli Zaretskii <e...@gnu.org>,  stefankan...@gmail.com,
>>   acora...@gnu.org,  j...@linkov.net,  r...@gnu.org,  69...@debbugs.gnu.org
>> Date: Wed, 04 Sep 2024 15:07:08 +0100
>> 
>> > +(defcustom kill-region-dwim nil
>> > +  "Behaviour when `kill-region' is invoked without an active region.
>> > +If set to nil (default), then an error occurs and nothing is killed.  If
>> > +set to `emacs-word', then kill a the last word as defined by the current
>> > +major mode.  If set to `unix-word', then kill the last word in the style
>> > +of a shell like Bash, disregarding the major mode."
>> > +  :type '(choice (const :tag "Kill a word like `backward-kill-word'" 
>> > emacs-word)
>> > +                 (const :tag "Kill a word like Bash would" unix-word)
>> > +                 (const :tag "Do not kill anything" nil))
>> > +  :group 'killing)
>> 
>> I think I'm missing something here.  When it's nil and there is no
>> *active* region, but there is a region, it should kill that, surely?
>> With or without TMM.
>
> Yes, you are right.  It sounds like we made wrong assumptions about
> what happens in that case, and should rethink this.
>
> C-w signals an error only if there's no mark in the buffer.
>
> So I guess we need a new command after all.

Not necessarily (unless I am mistaken above), but I am not opposed to it either.

-- 
        Philip Kaludercic on siskin

Reply via email to