bug#39902: 28.0.50; Marking in dired with active region

bug#39902: 28.0.50; Marking in dired with active region

[Michael Heerdegen]

Hello,

(1) Docstring of `dired-mark' says

  "If the region is active, mark all files in the region."

However, the file in the last line of the region is never marked, even
if the region spans the whole line of this file.  I find that behavior
wrong and contradicting the docstring.  But it seems it has been like
that for a long time (forever?).  Nevertheless, I'm always confused by
that behavior.

(2) Most of the time I rather want `dired-mark-files-regexp' to respect
an active region - but that isn't implemented (though it would not be
hard to do).  I think that would be useful.

(3) I didn't check if more dired (un)marking commands should be treated
or could be enhanced.  How the region is interpreted (see (1)) should be
kept consistent.


Thanks in advance,

Michael.


In GNU Emacs 28.0.50 (build 40, x86_64-pc-linux-gnu, GTK+ Version 3.24.13, cairo version 1.16.0)
 of 2020-03-04 built on drachen
Repository revision: d79e2a99f105970f7e1e229a8243bf23b9caf615
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12007000
System Description: Debian GNU/Linux bullseye/sid

bug#39902: 28.0.50; Marking in dired with active region

[Drew Adams]

> (1) Docstring of `dired-mark' says
>   "If the region is active, mark all files in the region."
> 
> However, the file in the last line of the region is never marked, even
> if the region spans the whole line of this file.

The problem seems to be that movement doesn't
put the cursor where you (and `dired-mark')
expect - the full lines are not selected.

If you do, say, `C-SPC', then `p p p', `then C-a',
then `m' (`dired-mark') then the full 3 lines are
selected and they get marked.  Similarly, if you
select the lines with the mouse.

Should `dired-mark' mark all lines that have any
of their chars selected, instead of lines that
have _all_ of their chars selected?  Maybe so.

bug#39902: 28.0.50; Marking in dired with active region

[Stephen Berman]

On Wed, 4 Mar 2020 07:41:40 -0800 (PST) Drew Adams <drew.adams@oracle.com> wrote:

>> (1) Docstring of `dired-mark' says
>>   "If the region is active, mark all files in the region."
>>
>> However, the file in the last line of the region is never marked, even
>> if the region spans the whole line of this file.
>
> The problem seems to be that movement doesn't
> put the cursor where you (and `dired-mark')
> expect - the full lines are not selected.

This is due to the following code in dired-mark:

	(dired-mark-files-in-region
	 (progn (goto-char beg) (line-beginning-position))
	 (progn (goto-char end) (line-beginning-position))))))

It may be that the second use of line-beginning-position is simply a
mistake, and should be line-end-position (CCing Juri Linkov, who wrote
that code).  That's what diredp-mark-region-files in the library
dired+.el (https://www.emacswiki.org/emacs/dired%2b.el) uses, which is
the inspiration for the dired-mark code (see bug#10624).

Steve Berman

bug#39902: 28.0.50; Marking in dired with active region

[Drew Adams]

> >> (1) Docstring of `dired-mark' says
> >>   "If the region is active, mark all files in the region."
> >>
> >> However, the file in the last line of the region is never marked, even
> >> if the region spans the whole line of this file.
> >
> > The problem seems to be that movement doesn't
> > put the cursor where you (and `dired-mark')
> > expect - the full lines are not selected.
> 
> This is due to the following code in dired-mark:
> 
> 	(dired-mark-files-in-region
> 	 (progn (goto-char beg) (line-beginning-position))
> 	 (progn (goto-char end) (line-beginning-position))))))
> 
> It may be that the second use of line-beginning-position is simply a
> mistake, and should be line-end-position (CCing Juri Linkov, who wrote
> that code).  That's what diredp-mark-region-files in the library
> dired+.el uses, which is the inspiration for the dired-mark code
> (see bug#10624).

Indeed.  I looked only at `dired-mark', and saw
that Dired+ doesn't substitute anything different
for that (`m' etc. are still bound to vanilla
`dired-mark').

I agree with you about the bug and proposed fix. 

bug#39902: 28.0.50; Marking in dired with active region

[Juri Linkov]

> (1) Docstring of `dired-mark' says
>
>   "If the region is active, mark all files in the region."
>
> However, the file in the last line of the region is never marked, even
> if the region spans the whole line of this file.  I find that behavior
> wrong and contradicting the docstring.  But it seems it has been like
> that for a long time (forever?).  Nevertheless, I'm always confused by
> that behavior.

The peculiarity of dired mode is that it puts point in front of file name.
So when the region doesn't cover the file name visually, it should not take
the file name outside the region into consideration for marking.

Exactly like kill-region should not kill text outside of the active region,
dired-mark should not mark files outside of the active region.

Especially more dangerous command dired-flag-file-deletion
should not delete files outside of the active region.

> (2) Most of the time I rather want `dired-mark-files-regexp' to respect
> an active region - but that isn't implemented (though it would not be
> hard to do).  I think that would be useful.

The problem is that this feature should be implemented in the macro
dired-mark-if, but then it will affect many other commands:

dired-mark-files-containing-regexp
dired-mark-symlinks
dired-mark-directories
dired-mark-executables
dired-flag-auto-save-files
dired-flag-backup-files
dired-compare-directories
dired-mark-unmarked-files
dired-mark-sexp
...

bug#39902: 28.0.50; Marking in dired with active region

[Drew Adams]

> The peculiarity of dired mode is that it puts point in front of file name.
> So when the region doesn't cover the file name visually, it should not take
> the file name outside the region into consideration for marking.

That's what I said.  It's the navigation keys,
which didn't select complete lines, which led
to the impression that not all files "in" the
region got marked.

It's about creation of the region.  You can
select complete lines, in which case `dired-mark'
does what is expected: marks all of the files
whose (full) lines are selected.

But it's also possible to have `dired-mark'
instead mark all of the files with ANY part of
their line (not ALL of their line) in the region.

> Exactly like kill-region should not kill text outside of the active region,
> dired-mark should not mark files outside of the active region.

Bad analogy.  Especially for purposes of marking or
acting on files "in the region", what's important is
that the region capture _some part_ of a file's line,
not necessarily all of it.

Marking is not, like `kill-region', an action on the
characters of text in the region.  It uses the region
only to indicate a sequence of files to act on.

This, or similar, is the behavior needed, as
Stephen Berman pointed out:

(defun diredp-mark-region-files (&optional unmark-p)
  "Mark all of the files in the current region (if it is active).
With non-nil prefix arg, unmark them instead."
  (interactive "P")
  (let ((beg  (min (point) (mark)))
        (end  (max (point) (mark)))
        (inhibit-field-text-motion  t)) ; Just in case.
    (setq beg  (save-excursion (goto-char beg)
                               (line-beginning-position))
          end  (save-excursion (goto-char end)
                               (line-end-position)))
    (let ((dired-marker-char  (if unmark-p
                                  ?\040
                                dired-marker-char)))
      (diredp-mark-if (and (<= (point) end)
                           (>= (point) beg)
                           (diredp-this-file-unmarked-p))
                      "region file"))))

> Especially more dangerous command dired-flag-file-deletion
> should not delete files outside of the active region.

Not at all.  The command simply marks; it does not
delete.  Subsequently using `x', to delete, prompts
you for confirmation, specifying the files to be
deleted.  I don't see any danger.

> > (2) Most of the time I rather want `dired-mark-files-regexp' to respect
> > an active region - but that isn't implemented (though it would not be
> > hard to do).  I think that would be useful.
> 
> The problem is that this feature should be implemented in the macro
> dired-mark-if, but then it will affect many other commands:
> 
> dired-mark-files-containing-regexp
> dired-mark-symlinks
> dired-mark-directories
> dired-mark-executables
> dired-flag-auto-save-files
> dired-flag-backup-files
> dired-compare-directories
> dired-mark-unmarked-files
> dired-mark-sexp
> ...

Those are all marking commands, so there's no problem.

That said, I'm not sure it would be a great idea to
have them (or have even just `dired-mark-files-regexp')
act on only the files in the active region.  Maybe,
maybe not.

It's certainly not hard, as a user, to narrow first
and then use such commands (but yes, in that case
you'll want to be sure to get the full lines in the
narrowing).

bug#39902: 28.0.50; Marking in dired with active region

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> The peculiarity of dired mode is that it puts point in front of file
> name.  So when the region doesn't cover the file name visually, it
> should not take the file name outside the region into consideration
> for marking.

But this does not describe what we currently have: you can mark N
complete lines, from the beginning to the end of the lines.  The file in
line N is always not marked.

> Exactly like kill-region should not kill text outside of the active
> region, dired-mark should not mark files outside of the active region.
>
> Especially more dangerous command dired-flag-file-deletion
> should not delete files outside of the active region.

This is a bit philosophical.  You can find an argument like this for any
behavior.  Personally, in my mind I identify the whole line as
associated to a certain file.  Whatever choice we take we should
document how an an active region is interpreted since different kinds of
behavior might be natural for different users.

> > (2) Most of the time I rather want `dired-mark-files-regexp' to respect
> > an active region - but that isn't implemented (though it would not be
> > hard to do).  I think that would be useful.
>
> The problem is that this feature should be implemented in the macro
> dired-mark-if, but then it will affect many other commands:
>
> dired-mark-files-containing-regexp
> dired-mark-symlinks
> dired-mark-directories
> dired-mark-executables
> dired-flag-auto-save-files
> dired-flag-backup-files
> dired-compare-directories
> dired-mark-unmarked-files
> dired-mark-sexp
> ...

Yes.  I think I would vote pro such a change.  It could also be made
optional by introducing a new user option.

Michael.

bug#39902: 28.0.50; Marking in dired with active region

[Juri Linkov]

>> The peculiarity of dired mode is that it puts point in front of file
>> name.  So when the region doesn't cover the file name visually, it
>> should not take the file name outside the region into consideration
>> for marking.
>
> But this does not describe what we currently have: you can mark N
> complete lines, from the beginning to the end of the lines.  The file in
> line N is always not marked.

Currently region-based marking works consistently with
argument-based marking, i.e. marking N files using an argument
marks the same number of files as marked by region, for example:

1. when you want to mark next 2 files, you can type:

   C-u 2 m

2. doing the same using the region, you can type the same argument number:

   C-SPC
   C-u 2 n
   m

Using the same number (2 in this case) marks the same number of files.

>> Exactly like kill-region should not kill text outside of the active
>> region, dired-mark should not mark files outside of the active region.
>>
>> Especially more dangerous command dired-flag-file-deletion
>> should not delete files outside of the active region.
>
> This is a bit philosophical.  You can find an argument like this for any
> behavior.  Personally, in my mind I identify the whole line as
> associated to a certain file.  Whatever choice we take we should
> document how an an active region is interpreted since different kinds of
> behavior might be natural for different users.

What do you think about marking the file on the current line
only when point is at the end of the line,
so the file name is completely inside the region?

>> > (2) Most of the time I rather want `dired-mark-files-regexp' to respect
>> > an active region - but that isn't implemented (though it would not be
>> > hard to do).  I think that would be useful.
>>
>> The problem is that this feature should be implemented in the macro
>> dired-mark-if, but then it will affect many other commands:
>>
>> dired-mark-files-containing-regexp
>> dired-mark-symlinks
>> dired-mark-directories
>> dired-mark-executables
>> dired-flag-auto-save-files
>> dired-flag-backup-files
>> dired-compare-directories
>> dired-mark-unmarked-files
>> dired-mark-sexp
>> ...
>
> Yes.  I think I would vote pro such a change.  It could also be made
> optional by introducing a new user option.

Perhaps no option needed because it's easy just to deactivate the region.
But what is important is to notify in the result message that the operation
was performed on the active region.

bug#39902: 28.0.50; Marking in dired with active region

[Drew Adams]

> What do you think about marking the file on the current line
> only when point is at the end of the line,
> so the file name is completely inside the region?

Please don't.  Marking a line should not care
where point is on the line.  That's always
been true.

bug#39902: 28.0.50; Marking in dired with active region

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> Currently region-based marking works consistently with argument-based
> marking, i.e. marking N files using an argument marks the same number
> of files as marked by region [...]

I don't know if users expect that these behave analogue.  I don't,
others surely will.

> What do you think about marking the file on the current line only when
> point is at the end of the line, so the file name is completely inside
> the region?

I think I would not like that more than what we currently have.

What I expect is a behavior analogue to "graphical" file browsers (with
icons and such - I don't use one, but anyway).  When you mark a region
there with the mouse, all files "touched" are in.  And it's enough when
the icon is included, i.e. the file is not identified with the
occurrence of the name on the screen but with the whole representation,
including the icon etc.  I guess that's where my way of thinking comes
from.

If expectations might be that different maybe the behavior should be
made controllable with a new user option?


Michael.

bug#39902: 28.0.50; Marking in dired with active region

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 752 bytes --]

> What I expect is a behavior analogue to "graphical" file browsers (with
> icons and such - I don't use one, but anyway).  When you mark a region
> there with the mouse, all files "touched" are in.  And it's enough when
> the icon is included, i.e. the file is not identified with the
> occurrence of the name on the screen but with the whole representation,
> including the icon etc.  I guess that's where my way of thinking comes
> from.

I tried in the default graphical file browser that I have available,
its name is Caja - the file manager for the MATE desktop,
and it works exactly like Emacs currently works:
it doesn't select files based on lines, but it selects only files
whose filenames are inside the selection.  Here is the screenshot:


[-- Attachment #2: caja.png --]
[-- Type: image/png, Size: 10910 bytes --]

[-- Attachment #3: Type: text/plain, Size: 670 bytes --]


But OTOH, it doesn't have the exact analogy with Emacs,
and I know no other files manager exactly like Dired.

> If expectations might be that different maybe the behavior should be
> made controllable with a new user option?

A new user option will help in any case.  But before adding it, maybe we
could try to improve the visual feedback of selection in Dired.  Would it
be possible to display the whole line (including file name) highlighted
with the 'region' face, even when point is still before the file name?

If this is not possbile to implement, then a new user option could have
a name 'dired-mark-non-selected-files' or 'dired-mark-files-on-current-line'.

bug#39902: 28.0.50; Marking in dired with active region

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> A new user option will help in any case.  But before adding it, maybe
> we could try to improve the visual feedback of selection in Dired.

I'd go the other way, because: When a user has set the new option to a
value that reflects his feeling of what is natural, he probably will not
have problems with the standard highlighting.

> Would it be possible to display the whole line (including file name)
> highlighted with the 'region' face, even when point is still before
> the file name?

AFAIU this would be easy - this is how `rectangle-mark-mode's
highlighting is implemented (rect.el):

(add-function :around redisplay-highlight-region-function
              #'rectangle--highlight-for-redisplay)
(add-function :around redisplay-unhighlight-region-function
              #'rectangle--unhighlight-for-redisplay)
(add-function :around region-extract-function
              #'rectangle--extract-region)
(add-function :around region-insert-function
              #'rectangle--insert-region)

I'm not sure if I would want this, though: marking is only thing that
uses the region.  Copying text is another one, for example.  Would the
changed region semantics have an impact on e.g. `kill-ring-save', etc.?


Michael.

bug#39902: 28.0.50; Marking in dired with active region

[Drew Adams]

Hi Michael,

Just so I can understand better, what's the 
reason you prefer to use the keyboard to
establish an active region that  selects the
lines you want to mark, and then invoke a
command to mark the lines captured by the
region, rather than just using `m' (e.g.
with a prefix arg)?

E.g., Rather than `C-SPC', navigate to the
desired region-end position, and then `m',
why not just use a prefix arg with `m'?

A guess is that you might use something like
`M->' to go to the region-end position.  But
even then, a large prefix arg should do the
job: `C-u 99999 m' versus `C-SPC M-> m'.

Could you give a recipe/example of your use
of keyboard keys for this, or otherwise
explain the rationale for it?

(NB: I'm not arguing that this bug should
not be fixed.  And as mentioned, the fix
should be trivial.)

In Dired+, though I define command
`diredp-mark-region-files' (which, as has
been pointed out, DTRT wrt this bug), I
don't bind it to a key, by default.

I haven't thought such a binding would be
very useful, which is why I ask for an
example use case.

Instead, I just provide mouse and menu
bindings for it when the region's active:
`S-mouse-1', `Mark Region' in a menu-bar
menu, and `Mark' in a `mouse-3' popup menu.

Similarly, for region commands to unmark,
flag, and toggle marks:
`diredp-unmark-region-files',
`diredp-flag-region-files-for-deletion',
`diredp-toggle-marks-in-region'.

bug#39902: 28.0.50; Marking in dired with active region

[Juri Linkov]

> In Dired+, though I define command
> `diredp-mark-region-files' (which, as has
> been pointed out, DTRT wrt this bug), I
> don't bind it to a key, by default.

IIUC, what Michael described is not like Dired+,
but more like another your library zones.el,
i.e. after activating the region, as you move point
in the Dired buffer, the region highlighting should
be updated to put region faces only on file names
using multiple regions, including the file name
of the current line, regardless of where point
is located on the current line: either before or
after the file name, the file name will be highlighted.

bug#39902: 28.0.50; Marking in dired with active region

[Drew Adams]

> > In Dired+, though I define command
> > `diredp-mark-region-files' (which, as has
> > been pointed out, DTRT wrt this bug), I
> > don't bind it to a key, by default.
> 
> IIUC, what Michael described is not like Dired+,
> but more like another your library zones.el,
> i.e. after activating the region, as you move point
> in the Dired buffer, the region highlighting should
> be updated to put region faces only on file names
> using multiple regions, including the file name
> of the current line, regardless of where point
> is located on the current line: either before or
> after the file name, the file name will be highlighted.

Sorry, I don't follow.

I didn't understand Michael's request to be
about multiple zones/regions (noncontiguous).

I think he's just saying what I was saying
earlier: to mark a "file in the region" it
should be sufficient that some part of the
file's line is in the region.  It should
not be a requirement that the full line -
all of its chars (including newline) be
within the region.

Yes, Michael did mention highlighting, but
I think what's important to him is perhaps
just that you can quickly and easily use
the region to specify a set of files to mark.

Whether the region highlight covers this or
that isn't very important, I think.  What's
surprising is that you (currently) have to
be sure to select every bit of a file's line,
for it to be marked.

Anyway, I'll stay out of this now, at least
until what Michael's asking for gets
clarified.

bug#39902: 28.0.50; Marking in dired with active region

[Michael Heerdegen]

Drew Adams <drew.adams@oracle.com> writes:


> I didn't understand Michael's request to be
> about multiple zones/regions (noncontiguous).
>
> I think he's just saying what I was saying
> earlier: to mark a "file in the region" it
> should be sufficient that some part of the
> file's line is in the region.  It should
> not be a requirement that the full line -
> all of its chars (including newline) be
> within the region.
>
> Yes, Michael did mention highlighting, but
> I think what's important to him is perhaps
> just that you can quickly and easily use
> the region to specify a set of files to mark.
>
> Whether the region highlight covers this or
> that isn't very important, I think.  What's
> surprising is that you (currently) have to
> be sure to select every bit of a file's line,
> for it to be marked.

Yes, a real good summary, thanks!

Michael.

bug#39902: 28.0.50; Marking in dired with active region

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 402 bytes --]

> I think he's just saying what I was saying
> earlier: to mark a "file in the region" it
> should be sufficient that some part of the
> file's line is in the region.  It should
> not be a requirement that the full line -
> all of its chars (including newline) be
> within the region.

Including newline?  Really?
This means that on the following screenshot
the file 'file3' should be marked as well?


[-- Attachment #2: dired-mark-3.png --]
[-- Type: image/png, Size: 6703 bytes --]

[-- Attachment #3: Type: text/plain, Size: 245 bytes --]


Here the beginning of the region is at the beginning of the line with 'file1',
and the end of the region is at the beginning of the line with 'file3'.
I can't believe that 'file3' should be marked only because its newline
is inside the region.

bug#39902: 28.0.50; Marking in dired with active region

[Drew Adams]

> > I think he's just saying what I was saying
> > earlier: to mark a "file in the region" it
> > should be sufficient that some part of the
> > file's line is in the region.  It should
> > not be a requirement that the full line -
> > all of its chars (including newline) be
> > within the region.
> 
> Including newline?  Really?
> This means that on the following screenshot
> the file 'file3' should be marked as well?

No.  That's not what I meant.

bug#39902: 28.0.50; Marking in dired with active region

[Juri Linkov]

>> Including newline?  Really?
>> This means that on the following screenshot
>> the file 'file3' should be marked as well?
>
> No.  That's not what I meant.

Then we agree that
(progn (goto-char end) (line-beginning-position))
should NOT be replaced with
(progn (goto-char end) (line-end-position))

bug#39902: 28.0.50; Marking in dired with active region

[Stephen Berman]

On Wed, 11 Mar 2020 01:24:20 +0200 Juri Linkov <juri@linkov.net> wrote:

>>> Including newline?  Really?
>>> This means that on the following screenshot
>>> the file 'file3' should be marked as well?
>>
>> No.  That's not what I meant.
>
> Then we agree that
> (progn (goto-char end) (line-beginning-position))
> should NOT be replaced with
> (progn (goto-char end) (line-end-position))

How about this:

 (progn (goto-char end) (line-end-position) (backward-char 1) (point))

Steve Berman

bug#39902: 28.0.50; Marking in dired with active region

[Juri Linkov]

>> Then we agree that
>> (progn (goto-char end) (line-beginning-position))
>> should NOT be replaced with
>> (progn (goto-char end) (line-end-position))
>
> How about this:
>
>  (progn (goto-char end) (line-end-position) (backward-char 1) (point))

Probably you meant

   (progn (goto-char end) (backward-char 1) (line-end-position) (point))

bug#39902: 28.0.50; Marking in dired with active region

[Drew Adams]

> (progn (goto-char end) (line-beginning-position))
> should NOT be replaced with
> (progn (goto-char end) (line-end-position))

I see.  Yes.  We can decide how to handle that
corner case.  If the region end is bolp then
`1-' it.  That's one possibility.

(progn (goto-char end)
	 (when (bolp) (backward-char))
	 (line-end-position))

This feature/problem is not a big deal, IMO.
I think what Michael is asking for is pretty
straightforward, as is the code needed.

bug#39902: 28.0.50; Marking in dired with active region

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> I can't believe that 'file3' should be marked only because its newline
> is inside the region.

OTOH, if point is at the end of the region (in contrast to your
screenshot), one could be surprised that the file line where the cursor
is displayed doesn't get marked.

This is a strange corner case.  I never used a region like that, I guess
because I felt that this case is dubious.

Michael.

bug#39902: 28.0.50; Marking in dired with active region

[Juri Linkov]

> OTOH, if point is at the end of the region (in contrast to your
> screenshot), one could be surprised that the file line where the cursor
> is displayed doesn't get marked.

Right, here is a complete patch that should do the right thing
depending on the new defcustom:

diff --git a/lisp/dired.el b/lisp/dired.el
index a4de51f609..486a8213c8 100644
--- a/lisp/dired.el
+++ b/lisp/dired.el
@@ -3578,6 +3578,12 @@ dired-mark-files-in-region
 	    (insert dired-marker-char)))
       (forward-line 1))))
 
+(defcustom dired-mark-inclusive nil
+  "Non-nil means `dired-mark' marks file on the region end."
+  :type 'boolean
+  :version "28.1"
+  :group 'dired)
+
 (defun dired-mark (arg &optional interactive)
   "Mark the file at point in the Dired buffer.
 If the region is active, mark all files in the region.
@@ -3597,7 +3603,11 @@ dired-mark
 	    (end (region-end)))
 	(dired-mark-files-in-region
 	 (progn (goto-char beg) (line-beginning-position))
-	 (progn (goto-char end) (line-beginning-position))))))
+	 (progn (goto-char end)
+                (if (and dired-mark-inclusive
+                         (get-text-property (point) 'dired-filename))
+                    (line-end-position)
+                  (line-beginning-position)))))))
    ;; Mark subdir files from the subdir headerline.
    ((dired-get-subdir)
     (save-excursion (dired-mark-subdir-files)))

bug#39902: 28.0.50; Marking in dired with active region

[Juri Linkov]

>> OTOH, if point is at the end of the region (in contrast to your
>> screenshot), one could be surprised that the file line where the cursor
>> is displayed doesn't get marked.
>
> Right, here is a complete patch that should do the right thing
> depending on the new defcustom:

Sorry, this patch was a response to another your comment:

>> This is a strange corner case.  I never used a region like that, I guess
>> because I felt that this case is dubious.

This means that the patch doesn't handle this strange corner case,
but it handles more usual case where point is on the file name:

diff --git a/lisp/dired.el b/lisp/dired.el
index a4de51f609..420938ef2e 100644
--- a/lisp/dired.el
+++ b/lisp/dired.el
@@ -3578,6 +3578,12 @@ dired-mark-files-in-region
 	    (insert dired-marker-char)))
       (forward-line 1))))
 
+(defcustom dired-mark-inclusive nil
+  "Non-nil means `dired-mark' marks file on the region end."
+  :type 'boolean
+  :version "28.1"
+  :group 'dired)
+
 (defun dired-mark (arg &optional interactive)
   "Mark the file at point in the Dired buffer.
 If the region is active, mark all files in the region.
@@ -3597,7 +3603,11 @@ dired-mark
 	    (end (region-end)))
 	(dired-mark-files-in-region
 	 (progn (goto-char beg) (line-beginning-position))
-	 (progn (goto-char end) (line-beginning-position))))))
+	 (progn (goto-char end)
+                (if (and dired-mark-inclusive
+                         (or (eolp) (get-text-property (point) 'dired-filename)))
+                    (line-end-position)
+                  (line-beginning-position)))))))
    ;; Mark subdir files from the subdir headerline.
    ((dired-get-subdir)
     (save-excursion (dired-mark-subdir-files)))

bug#39902: 28.0.50; Marking in dired with active region

[Drew Adams]

> +(defcustom dired-mark-inclusive nil
> +  "Non-nil means `dired-mark' marks file on the region end."
> +  :type 'boolean
> +  :version "28.1"
> +  :group 'dired)

> +	 (progn (goto-char end)
> +                (if (and dired-mark-inclusive
> +                         (or (eolp) (get-text-property (point) 'dired-
> filename)))
> +                    (line-end-position)
> +                  (line-beginning-position)))))))

I see no reason for such an option.  And no reason
for the broken default behavior that the original
complaint was about.

Is using `line-beginning-position' here really
something you think is useful?

My vote is to use what I suggested, or similar:

(progn (goto-char end)
	 (when (bolp) (backward-char))
	 (line-end-position))

bug#39902: 28.0.50; Marking in dired with active region

[Michael Heerdegen]

Drew Adams <drew.adams@oracle.com> writes:

> My vote is to use what I suggested, or similar:
>
> (progn (goto-char end)
> 	 (when (bolp) (backward-char))
> 	 (line-end-position))

Yes, I think this suits my expectations better than Juri's patch.

Michael.

bug#39902: 28.0.50; Marking in dired with active region

[Juri Linkov]

> I see no reason for such an option.  And no reason
> for the broken default behavior that the original
> complaint was about.

In 2012 you asked me to implement this feature, and after implementing it
you confirmed that it has the right implementation.  Changing its
long-standing default behavior now will cause backward-incompatibility
in users' habits.

bug#39902: 28.0.50; Marking in dired with active region

[Drew Adams]

> > I see no reason for such an option.  And no reason
> > for the broken default behavior that the original
> > complaint was about.
> 
> In 2012 you asked me to implement this feature, and after implementing it
> you confirmed that it has the right implementation.  Changing its
> long-standing default behavior now will cause backward-incompatibility
> in users' habits.

Really?  What feature is that?  Could you please
point me to my request for it?

Could you also please describe the user habit in
question, and the change that would break it?

bug#39902: 28.0.50; Marking in dired with active region

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 454 bytes --]

> Really?  What feature is that?  Could you please
> point me to my request for it?

bug#10624

> Could you also please describe the user habit in
> question, and the change that would break it?

The most obvious way for users to mark e.g. next 2 files
is to type S-down 2 times, then type 'm', especially
convenient when arrow keys are located near the 'm' key.

For example, here is the screenshot where you agreed
that only 2 files should be marked:


[-- Attachment #2: dired-mark-1.png --]
[-- Type: image/png, Size: 2197 bytes --]

[-- Attachment #3: Type: text/plain, Size: 102 bytes --]


But this is not much different from this screenshot
because 'file3' still is not inside the region:


[-- Attachment #4: dired-mark-2.png --]
[-- Type: image/png, Size: 2298 bytes --]

bug#39902: 28.0.50; Marking in dired with active region

[Pieter van Oostrum]

Juri Linkov <juri@linkov.net> writes:

>> Really?  What feature is that?  Could you please
>> point me to my request for it?
>
> bug#10624
>
>> Could you also please describe the user habit in
>> question, and the change that would break it?
>
> The most obvious way for users to mark e.g. next 2 files
> is to type S-down 2 times, then type 'm', especially
> convenient when arrow keys are located near the 'm' key.
>
> For example, here is the screenshot where you agreed
> that only 2 files should be marked:
>
(>
>
>
> But this is not much different from this screenshot
> because 'file3' still is not inside the region:
>
()Sorry, the images are not included in the followup)

What I see in this scenario (S-down twice), looks like the second image: cursor just before the first character of the third filename, the one that should not be included.
-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

bug#39902: 28.0.50; Marking in dired with active region

[Michael Heerdegen]

Pieter van Oostrum <pieter-l@vanoostrum.org> writes:

> What I see in this scenario (S-down twice), looks like the second
> image: cursor just before the first character of the third filename,
> the one that should not be included.

Not everybody will think like that (that it should not be included).

Maybe most people avoid that case anyway?  Would it then be appropriate
if the marking commands would just raise a `user-error' in this case/
such cases?

Michael.

bug#39902: 28.0.50; Marking in dired with active region

[Drew Adams]

> > What I see in this scenario (S-down twice), looks like the second
> > image: cursor just before the first character of the third filename,
> > the one that should not be included.
> 
> Not everybody will think like that (that it should not be included).
> 
> Maybe most people avoid that case anyway?  Would it then be appropriate
> if the marking commands would just raise a `user-error' in this case/
> such cases?

I've given my opinion in my reply to Juri:

  Act on each file when any non-empty part
  of its line is in the active region.

So far, the actions we're talking about are
only _marking_ actions (mark with * or some
other mark, flag with D, or unmark).

IMO there's no need for any kind of error,
warning, or confirmation requirement when
just (un)marking.

And for commands that _use_ marks, acting on
the marked or flagged files, we already do
require confirmation when it makes sense.

bug#39902: 28.0.50; Marking in dired with active region

[Drew Adams]

>>>> I see no reason for such an option.  And no reason
>>>> for the broken default behavior that the original
>>>> complaint was about.
>>>
>>> In 2012 you asked me to implement this feature,
>>> and after implementing it you confirmed that it has
>>> the right implementation.  Changing its long-standing
>>> default behavior now will cause backward-incompatibility
>>> in users' habits.
>>
>> Really?  What feature is that?  Could you please
>> point me to my request for it?
> 
> bug#10624

Sorry, I see nowhere at all in that (long) bug thread
where I asked you to implement such an option or the
broken behavior cited, or where confirmed that such
behavior is correct.

And if you find somewhere where I did say such things
then I'd say now that I was wrong then.  (My reading
of that thread doesn't find anything I disagree with
now or that contradicts what I've said here - but
that's not important.)

To me, that (open) enhancement request is anyway about
more important things than what you implemented or what
we're discussing now.

> > Could you also please describe the user habit in
> > question, and the change that would break it?
> 
> The most obvious way for users to mark e.g. next 2 files
> is to type S-down 2 times, then type 'm', especially
> convenient when arrow keys are located near the 'm' key.

I think that's what we're talking about.

I don't have a problem with users doing that.  What's the
problem with that?  What habit would be broken?

What we're talking about, I thought, is that, IF you use
`m' (or other mark-changing keys) AFTER you do that (or
after something else that selects parts of contiguous
file lines as the active region), THEN that marking
command acts on each file that has ANY part of its line
selected.  That's what the behavior should be, IMO.

You pointed out the corner case of a region that ends
at bol.  A fix for that corner case was provided.

> For example, here is the screenshot where you agreed
> that only 2 files should be marked:
>
> But this is not much different from this screenshot
> because 'file3' still is not inside the region:

That second image, where point is not at bol, _should_
result in the 3rd file being marked, IMO - and it does.
I don't see a problem with the bolp fix provided.

For me, it's about whether ANY (non-empty, hence the
bolp fix) part of a file's line is selected.  It's not
about whether the _file name_ is selected.  Actions in
Dired are generally (maybe even only) apply to a file
line, not to its file-name portion.

(An action, such as renaming, might affect only the
file-name portion as its _result_.  But it takes
effect on the file designated by that line.  And other
actions (e.g. chmod, touch) can affect other parts of
the line (e.g. permissions, date).

We've been around and around about the question now.
I think those who have spoken up in this thread,
including OP Michael - with you as the exception, feel
the same way: Act on each file when any non-empty part
of its line is in the active region.

bug#39902: 28.0.50; Marking in dired with active region

[Juri Linkov]

>> The most obvious way for users to mark e.g. next 2 files
>> is to type S-down 2 times, then type 'm', especially
>> convenient when arrow keys are located near the 'm' key.
>
> I don't have a problem with users doing that.  What's the
> problem with that?  What habit would be broken?

The habit of typing S-down twice to mark two files, not three.

> What we're talking about, I thought, is that, IF you use
> `m' (or other mark-changing keys) AFTER you do that (or
> after something else that selects parts of contiguous
> file lines as the active region), THEN that marking
> command acts on each file that has ANY part of its line
> selected.  That's what the behavior should be, IMO.

1.
> That second image, where point is not at bol, _should_
> result in the 3rd file being marked, IMO - and it does.

2.
> For me, it's about whether ANY (non-empty, hence the
> bolp fix) part of a file's line is selected.

Aren't the above two sentences contradicting?
Because on the second image there is only empty space
before the file name, so according to your second sentence,
the 3rd file should NOT be marked.

> (An action, such as renaming, might affect only the
> file-name portion as its _result_.  But it takes
> effect on the file designated by that line.  And other
> actions (e.g. chmod, touch) can affect other parts of
> the line (e.g. permissions, date).
>
> We've been around and around about the question now.
> I think those who have spoken up in this thread,
> including OP Michael - with you as the exception, feel
> the same way: Act on each file when any non-empty part
> of its line is in the active region.

Why non-empty part of the line?  It's more logical about
the non-empty part of the file name, because dired
commands don't act on lines, but on files.

bug#39902: 28.0.50; Marking in dired with active region

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> Why non-empty part of the line?  It's more logical about
> the non-empty part of the file name, because dired
> commands don't act on lines, but on files.

But also not on file names.  I suggest to stop discussing which
identification of a file vs. what appears in the dired buffer is more
logical.  I think it has become clear that we have different viewpoints
here.

Michael.

bug#39902: 28.0.50; Marking in dired with active region

[Drew Adams]

> > Why non-empty part of the line?  It's more logical about
> > the non-empty part of the file name, because dired
> > commands don't act on lines, but on files.
> 
> But also not on file names.  I suggest to stop discussing which
> identification of a file vs. what appears in the dired buffer is more
> logical.  I think it has become clear that we have different viewpoints
> here.

Yes.

RMS might say, "Take a user poll".  I doubt that
will happen.  If the price to pay, to get this
fixed, is for Juri to add an option that lets
users choose the behavior, so be it.

The bug is minor, IMHO.  And so is the fix.
And so is the disagreement about which behavior
is more natural or more useful.

bug#39902: 28.0.50; Marking in dired with active region

[Drew Adams]

> >> The most obvious way for users to mark e.g. next 2 files
> >> is to type S-down 2 times, then type 'm', especially
> >> convenient when arrow keys are located near the 'm' key.
> >
> > I don't have a problem with users doing that.  What's the
> > problem with that?  What habit would be broken?
> 
> The habit of typing S-down twice to mark two files, not three.

S-down doesn't mark anything.  `m' and other keys
mark files.

And the fact of `m' marking files in the region
is relatively recent.  And there are many ways
to define an active region, and for most of them
the corner case you cited would be very rare.

To me, this is a (minor) bug fix; nothing more.
You can proclaim it backward-incompatible in
terms of interactive behavior.  That doesn't
bother me.

And as someone else pointed out, we usually
don't cry "backward incompatible" when it comes
to changing use behavior; we typically use that
term for code changes.  Emacs developers change
behavior of user interactions fairly often (you
among them), with nary a blink - and especially
when it's about a bug fix.

But if you are truly worried about that, and you
honestly think that either (1) many users will
be shocked by such a behavior fix or (2) you
strongly hate the fix, then just add an option
to provide the old, broken behavior.  I'm not in
favor of such an option, but if that's the price
to pay to get this fixed, so be it.

> > What we're talking about, I thought, is that, IF you use
> > `m' (or other mark-changing keys) AFTER you do that (or
> > after something else that selects parts of contiguous
> > file lines as the active region), THEN that marking
> > command acts on each file that has ANY part of its line
> > selected.  That's what the behavior should be, IMO.
> 
> 1.
> > That second image, where point is not at bol, _should_
> > result in the 3rd file being marked, IMO - and it does.
> 
> 2.
> > For me, it's about whether ANY (non-empty, hence the
> > bolp fix) part of a file's line is selected.
> 
> Aren't the above two sentences contradicting?
> Because on the second image there is only empty space
> before the file name, so according to your second sentence,
> the 3rd file should NOT be marked.

What part of "ANY (non-empty...) part of a
file's line" is unclear?  I didn't say any
non-whitespace part.

> > (An action, such as renaming, might affect only the
> > file-name portion as its _result_.  But it takes
> > effect on the file designated by that line.  And other
> > actions (e.g. chmod, touch) can affect other parts of
> > the line (e.g. permissions, date).
> >
> > We've been around and around about the question now.
> > I think those who have spoken up in this thread,
> > including OP Michael - with you as the exception, feel
> > the same way: Act on each file when any non-empty part
> > of its line is in the active region.
> 
> Why non-empty part of the line?  It's more logical about
> the non-empty part of the file name, because dired
> commands don't act on lines, but on files.

Quite the contrary, as I and others have
explained several times now.  And in fact
that's one of the main points: that's how
Dired behaves.

As I said in the very same paragraph as
your cited #2, above:

  Actions in Dired are generally (maybe even
  only) apply to a file line, not to its
  file-name portion.

  (An action, such as renaming, might affect
  only the file-name portion as its _result_.
  But it takes effect on the file designated
  by that line.  And other actions (e.g. chmod,
  touch) can affect other parts of the line
  (e.g. permissions, date).)

Dired actions act directly on file/directory
lines.  Typically they do something to the
file or dir.  But in terms of the UI they act
on the line.  A mark on a line is, in UI or
behavior terms, a mark on the line.  It is
only actions that _use_ marks that then act
on the file/dir whose line is marked.  The act
of marking is not an action on the file/dir.

But I (and others) have said this more than
once.  You remain unconvinced.  And you are
the one, I guess, who will or won't fix this,
so you are the one who needs convincing.

In terms of arguing for/against this, I think
we're about done, no?

bug#39902: 28.0.50; Marking in dired with active region

[Juri Linkov]

>   Actions in Dired are generally (maybe even
>   only) apply to a file line, not to its
>   file-name portion.

When you are marking files, at what part of the Dired buffer
do you look?  I'm sure at file-names.  Therefore
actions in Dired apply to file-names.

> In terms of arguing for/against this, I think
> we're about done, no?

I already provided 2 strong arguments
that support the current implementation:

1. the number of repeated keystrokes is equal
to the number of selected files, e.g.
'm m' selects 2 files, 'C-SPC n n' selects 2 files,
'S-down S-down' selects 2 files, etc.

This is an important property of the current implementation.

2. consistent visual feedback, i.e. when the file name
is not inside the selected region, it should not be marked.

You provided only 1 argument for changes:

1. mark the file name when the end of the region is before
the file name but not on the beginning of the file line.

And I agreed that this makes sense as well.

Then I proposed to add a new option, but you disagreed.

bug#39902: 28.0.50; Marking in dired with active region

[Drew Adams]

> > Actions in Dired are generally (maybe even
> > only) apply to a file line, not to its
> > file-name portion.
> 
> When you are marking files, at what part of
> the Dired buffer do you look?  I'm sure at
> file-names.  Therefore actions in Dired apply
> to file-names.

No.

1. You may look at file names, file-name
   extensions, dates, permissions, sizes,
   symlink targets, marks, deletion flags,...
   - any and all of the info on a file line.

2. In particular, when multiple lines are
   marked you may well look at the marks.
   Or at the ranges of marks, when
   contiguous lines are marked.

3. Even if/when you do "look at file names"
   it does not follow ("therefore") that
   the UI actions you perform apply to file
   names.  As I said, they can apply to marks
   (change, add, remove), and they can apply
   to lines (omit, delete, insert).

And as I said, beyond UI actions, sure, many
of the Dired actions ultimately act on files.
Even in that case, they typically do not act
directly on files.  But only very few actions
(in particular, renaming) apply to file names
(as opposed to files).

> > In terms of arguing for/against this,
> > I think we're about done, no?
> 
> I already provided 2 strong arguments
> that support the current implementation:
> 
> 1. the number of repeated keystrokes is equal
> to the number of selected files, e.g.
> 'm m' selects 2 files, 'C-SPC n n' selects 2 files,
> 'S-down S-down' selects 2 files, etc.

So what?  The question before us has nothing
whatsoever to do with repeated `m'.  That's
no argument for supporting the current
behavior wrt using the region for marking.

This is about a completely different way of
marking a group of lines from using repeated
`m'.  The only things they have in common
are (1) in both cases the lines acted on are
consecutive, and (2) in both cases point is
on the first or last of those lines.

> This is an important property of the current
> implementation.

It's not at all a property of the behavior
of using a region to select.  Irrelevant.
Apples & oranges.

> 2. consistent visual feedback, i.e. when the
> file name is not inside the selected region,
> it should not be marked.

It's not about the file name.  As Michael
said, you have a different opinion about
that.

OK.  But that doesn't provide an argument
for the behavior.  That's just saying that
you prefer the current behavior.  Opinion
cannot be a _reason supporting_ itself.

> You provided only 1 argument for changes:
> 
> 1. mark the file name when the end of the
> region is before the file name but not on
> the beginning of the file line.

I said nothing about marking file names.
I don't believe that Dired marks are about
marking file names.

But yes, my opinion (not a reason for my
opinion) is that it's clearer to act on
each line that has some of it selected.

Why?

1. That's what, I think, users expect, and
   it's what (I think) they're used to in
   other, similar UIs.

2. It's consistent with what happens in
   the rest of Dired.  When you hit `m' -
   or perform nearly any other action -
   does it matter where point is on the
   line?  No, of course not.  Do we expect
   that point needs to be on the file name
   itself because that's where you should
   be looking?  No.

> And I agreed that this makes sense as well.

So we agree on the fix?  Any line, any
(non-empty) part of which is selected, gets
the mark action?

> Then I proposed to add a new option, but
> you disagreed.

Please, add any options you like, if the
default behavior is to fix this (minor) bug
as just mentioned.  That doesn't mean that
I agree that we need such an option, or that
it's a good idea to add it.  But (as I said
already) if that's the price for getting the
bug fixed, so be it.

bug#39902: 28.0.50; Marking in dired with active region

[Michael Heerdegen]

Drew Adams <drew.adams@oracle.com> writes:

> > This is an important property of the current
> > implementation.
>
> It's not at all a property of the behavior
> of using a region to select.  Irrelevant.
> Apples & oranges.

I think he thinks in terms of consistency.  But consistency depends on
the view point, so his consistency is of no value for people with a
different view point.  Too bad we only know about three opinions.

> Please, add any options you like, if the
> default behavior is to fix this (minor) bug
> as just mentioned.  That doesn't mean that
> I agree that we need such an option, or that
> it's a good idea to add it.  But (as I said
> already) if that's the price for getting the
> bug fixed, so be it.

I see our different views as of the same right and value.  And the use
case (who uses marking commands with an active region at all?) is a
corner case.  I don't mind about the default as long as there is a new
option.  I would rather want to discuss what else should be done
(behavior of other marking commands etc, should we change
`dired-mark-if', etc.

Michael.

bug#39902: 28.0.50; Marking in dired with active region

[Juri Linkov]

> I see our different views as of the same right and value.  And the use
> case (who uses marking commands with an active region at all?) is a
> corner case.  I don't mind about the default as long as there is a new
> option.

There is nothing new here.  Mathematicians have been fighting that battle
for centuries until invention of the special notation to differentiate
including and excluding endpoints using either a square bracket or
a reversed parenthesis to indicate inclusive/exclusive intervals:

https://en.wikipedia.org/wiki/Bracket_(mathematics)#Intervals
https://en.wikipedia.org/wiki/Interval_(mathematics)#Including_or_excluding_endpoints

The most recent development is still ongoing in new programming languages.
For example, in the initial versions of Rust there were only
exclusive ranges, so e.g.

  for i in 1..3

yields only 1 and 2, but not 3, like the region mark command in Dired now.

But later Rust versions added inclusive ranges as well with special syntax:

  for i in 1..=3

that yields 1, 2 and 3.

Please see more examples at
https://doc.rust-lang.org/edition-guide/rust-2018/data-types/inclusive-ranges.html

So Dired could do the same and support both range types using a new option
'dired-mark-inclusive'.

> I would rather want to discuss what else should be done
> (behavior of other marking commands etc, should we change
> `dired-mark-if', etc.

I think `dired-mark-if' should respect that option too.

bug#39902: 28.0.50; Marking in dired with active region

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 611 bytes --]

>> I see our different views as of the same right and value.  And the use
>> case (who uses marking commands with an active region at all?) is a
>> corner case.  I don't mind about the default as long as there is a new
>> option.
>
> So Dired could do the same and support both range types using a new option
> 'dired-mark-inclusive'.
>
>> I would rather want to discuss what else should be done
>> (behavior of other marking commands etc, should we change
>> `dired-mark-if', etc.
>
> I think `dired-mark-if' should respect that option too.

Here is a complete implementation, please try if it works for you:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: dired-mark-inclusive.patch --]
[-- Type: text/x-diff, Size: 2348 bytes --]

diff --git a/lisp/dired.el b/lisp/dired.el
index a4de51f609..6858245ab7 100644
--- a/lisp/dired.el
+++ b/lisp/dired.el
@@ -296,6 +296,12 @@ dired-always-read-filesystem
   :version "26.1"
   :group 'dired)
 
+(defcustom dired-mark-inclusive nil
+  "Non-nil means `dired-mark' is inclusive."
+  :type 'boolean
+  :version "28.1"
+  :group 'dired)
+
 ;; Internal variables
 
 (defvar dired-marker-char ?*		; the answer is 42
@@ -613,7 +619,21 @@ dired-mark-if
 MSG is a noun phrase for the type of files being marked.
 It should end with a noun that can be pluralized by adding `s'.
 Return value is the number of files marked, or nil if none were marked."
-  `(let ((inhibit-read-only t) count)
+  `(let ((inhibit-read-only t) count
+         (beg (if (use-region-p)
+                  (save-excursion
+                    (goto-char (region-beginning))
+                    (line-beginning-position))
+                (point-min)))
+         (end (if (use-region-p)
+                  (save-excursion
+                    (goto-char (region-end))
+                    (if (if dired-mark-inclusive
+                            (not (bolp))
+                          (get-text-property (1- (point)) 'dired-filename))
+                        (line-end-position)
+                      (line-beginning-position)))
+                (point-max))))
     (save-excursion
       (setq count 0)
       (when ,msg
@@ -626,8 +646,8 @@ dired-mark-if
 		 (if (eq dired-del-marker dired-marker-char)
 		     " for deletion"
 		   "")))
-      (goto-char (point-min))
-      (while (not (eobp))
+      (goto-char beg)
+      (while (< (point) end)
         (when ,predicate
           (unless (= (following-char) dired-marker-char)
             (delete-char 1)
@@ -3597,7 +3622,12 @@ dired-mark
 	    (end (region-end)))
 	(dired-mark-files-in-region
 	 (progn (goto-char beg) (line-beginning-position))
-	 (progn (goto-char end) (line-beginning-position))))))
+	 (progn (goto-char end)
+                (if (if dired-mark-inclusive
+                        (not (bolp))
+                      (get-text-property (1- (point)) 'dired-filename))
+                    (line-end-position)
+                  (line-beginning-position)))))))
    ;; Mark subdir files from the subdir headerline.
    ((dired-get-subdir)
     (save-excursion (dired-mark-subdir-files)))

bug#39902: 28.0.50; Marking in dired with active region

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> Here is a complete implementation, please try if it works for you:

Yes, works well, thank you very much.  Also other marking commands seem
to work well with the new option.

The docstring of `dired-mark-inclusive' should be enhanced a bit I
think.  You could add one sentence about what "inclusive" means, and
another saying that other (un-)marking commands are also covered.

Michael.

bug#39902: 28.0.50; Marking in dired with active region

[Drew Adams]

> > Here is a complete implementation, please try if it works for you:
> 
> Yes, works well, thank you very much.  Also other marking commands seem
> to work well with the new option.
> 
> The docstring of `dired-mark-inclusive' should be enhanced a bit I
> think.  You could add one sentence about what "inclusive" means, and
> another saying that other (un-)marking commands are also covered.

I took a quick look - didn't check much.  

Seems OK to me too (but I'd prefer a non-nil default
value for the option, as already mentioned).

---

However, I notice one thing that seems like a bug
(didn't notice it before) - and the bug is present even
without the patch:

If `use-empty-active-region' is non-nil, and the region
is empty, then `m' marks the current line only sometimes,
depending on where point is.  And the behavior differs,
depending on the value of option `dired-mark-inclusive':

`dired-mark-inclusive' = nil:

   marks line only if point is on the 2nd file-name
   char or any char after that (including eol, i.e.,
   _after_ the file name)

`dired-mark-inclusive' = t:

   marks only if point is not at bol

IMO, the behavior should be the same, regardless of
the cursor position on the line.  I think it should
mark the line:

* for any position, if `dired-mark-inclusive' = t
* for any position on the file name, otherwise

Juri, you decide the behavior for the nil case, but
I think it should be consistent.  Personally, I see
no reason that point on the first file-name char
would act differently from point on the second.  And
by the logic of non-inclusive I'd think that an empty
region _after_ the file name wouldn't mark the line
(no part of the file name is in the region).

For the non-nil case, I think it's important that the
line get marked even when point is at bol.

Why?  Consistency.  And it's easy to hit `C-SPC'
without realizing that you've done so - there's no
good visual signal (just the "Mark activated" msg).

In the non-nil case, especially, I really feel that
a user expects the line to be marked, even if the
region is empty (when `use-empty-active-region' is
non-nil).

---

As I said earlier, I really suspect that Emacs may
have lurking bugs because stuff that makes use of
`use-region-p' might not get tested with non-nil
`use-empty-active-region'.  And yet the reason for
creating that option was for the addition of that
function (or vice versa).

[Frankly, I think things were clearer in the code
before `use-region-p' and that option were added.
`region-active-p' was clear; `use-region-p' hides
use of an option, and I suspect that the non-nil
case doesn't get tested much.  When just
`region-active-p' was used, it kinda invited testing
whether the region was empty.]

(FWIW, I don't use non-nil `use-empty-active-region'.
But I imagine some people do.)

bug#39902: 28.0.50; Marking in dired with active region

[Juri Linkov]

> I took a quick look - didn't check much.  
>
> Seems OK to me too (but I'd prefer a non-nil default
> value for the option, as already mentioned).
>
> ---
>
> However, I notice one thing that seems like a bug
> (didn't notice it before) - and the bug is present even
> without the patch:
>
> If `use-empty-active-region' is non-nil, and the region
> is empty, then `m' marks the current line only sometimes,
> depending on where point is.  And the behavior differs,
> depending on the value of option `dired-mark-inclusive':
>
> `dired-mark-inclusive' = nil:
>
>    marks line only if point is on the 2nd file-name
>    char or any char after that (including eol, i.e.,
>    _after_ the file name)
>
> `dired-mark-inclusive' = t:
>
>    marks only if point is not at bol
>
> IMO, the behavior should be the same, regardless of
> the cursor position on the line.  I think it should
> mark the line:
>
> * for any position, if `dired-mark-inclusive' = t
> * for any position on the file name, otherwise
>
> Juri, you decide the behavior for the nil case, but
> I think it should be consistent.  Personally, I see
> no reason that point on the first file-name char
> would act differently from point on the second.  And
> by the logic of non-inclusive I'd think that an empty
> region _after_ the file name wouldn't mark the line
> (no part of the file name is in the region).
>
> For the non-nil case, I think it's important that the
> line get marked even when point is at bol.
>
> Why?  Consistency.  And it's easy to hit `C-SPC'
> without realizing that you've done so - there's no
> good visual signal (just the "Mark activated" msg).
>
> In the non-nil case, especially, I really feel that
> a user expects the line to be marked, even if the
> region is empty (when `use-empty-active-region' is
> non-nil).
>
> ---
>
> As I said earlier, I really suspect that Emacs may
> have lurking bugs because stuff that makes use of
> `use-region-p' might not get tested with non-nil
> `use-empty-active-region'.  And yet the reason for
> creating that option was for the addition of that
> function (or vice versa).
>
> [Frankly, I think things were clearer in the code
> before `use-region-p' and that option were added.
> `region-active-p' was clear; `use-region-p' hides
> use of an option, and I suspect that the non-nil
> case doesn't get tested much.  When just
> `region-active-p' was used, it kinda invited testing
> whether the region was empty.]
>
> (FWIW, I don't use non-nil `use-empty-active-region'.
> But I imagine some people do.)

Sorry, I received your message only after I pushed to master.
But nonetheless, your test cases should be handled carefully.
The simplest solution would be just to disallow the option
`use-empty-active-region' to use the empty region in Dired,
i.e. instead of

  (if (use-region-p)
  ... then mark files in the active region ...

to use

  (if (let ((use-empty-active-region nil)) (use-region-p))
  ... then mark files in the active region ...

bug#39902: 28.0.50; Marking in dired with active region

[Drew Adams]

> Sorry, I received your message only after I pushed to master.
> But nonetheless, your test cases should be handled carefully.
> The simplest solution would be just to disallow the option
> `use-empty-active-region' to use the empty region in Dired,
> i.e. instead of
> 
>   (if (use-region-p)
>   ... then mark files in the active region ...
> 
> to use
> 
>   (if (let ((use-empty-active-region nil)) (use-region-p))
>   ... then mark files in the active region ...

Yes, that's what I was hinting at: an empty
region should always be ignored, i.e., that case
should be treated as if the region were not
active.

A better way to do it than binding that variable
(even if it were _not_ a user option) is to just
do what one would have done before `use-region-p'
was defined:

(if (and (region-active-p)
         (> (region-end) (region-beginning)))
    ...

Really, `use-region-p', although convenient, is
error prone.  Few use cases really call for
being able to use an empty region (non-nil
`use-empty-active-region'), and code that deals
with the region is much clearer if it says
explicitly what it intends for an empty region.

bug#39902: 28.0.50; Marking in dired with active region

[Juri Linkov]

> And it's easy to hit `C-SPC' without realizing that you've done so -
> there's no good visual signal (just the "Mark activated" msg).

Typing `C-x SPC' shows an indication as a thin vertical bar highlighted
with the region face.  But `C-SPC' doesn't have the same subtle indication.

>> i.e. instead of
>> 
>>   (if (use-region-p)
>>   ... then mark files in the active region ...
>> 
>> to use
>> 
>>   (if (let ((use-empty-active-region nil)) (use-region-p))
>>   ... then mark files in the active region ...
>
> Yes, that's what I was hinting at: an empty
> region should always be ignored, i.e., that case
> should be treated as if the region were not
> active.
>
> A better way to do it than binding that variable
> (even if it were _not_ a user option) is to just
> do what one would have done before `use-region-p'
> was defined:
>
> (if (and (region-active-p)
>          (> (region-end) (region-beginning)))
>     ...
>
> Really, `use-region-p', although convenient, is
> error prone.  Few use cases really call for
> being able to use an empty region (non-nil
> `use-empty-active-region'), and code that deals
> with the region is much clearer if it says
> explicitly what it intends for an empty region.

Thanks for the suggestion, now changed in master.

bug#39902: 28.0.50; Marking in dired with active region

[Drew Adams]

> > And it's easy to hit `C-SPC' without realizing that you've done so -
> > there's no good visual signal (just the "Mark activated" msg).
> 
> Typing `C-x SPC' shows an indication as a thin vertical bar highlighted
> with the region face.  But `C-SPC' doesn't have the same subtle
> indication.

Yes, sorry, I meant `C-SPC'.

> > an empty region should always be ignored...
> > A better way to do it...:
> > (if (and (region-active-p)
> >          (> (region-end) (region-beginning)))
> 
> Thanks for the suggestion, now changed in master.

Glad we reached a conclusion.  Thanks to both of
you for working on this.

bug#39902: 28.0.50; Marking in dired with active region

[Juri Linkov]

tags 39902 fixed
close 39902 28.0.50
quit

>> Here is a complete implementation, please try if it works for you:
>
> Yes, works well, thank you very much.  Also other marking commands seem
> to work well with the new option.
>
> The docstring of `dired-mark-inclusive' should be enhanced a bit I
> think.  You could add one sentence about what "inclusive" means, and
> another saying that other (un-)marking commands are also covered.

I enhanced the docstring, renamed to `dired-mark-region',
and pushed to master.

The default behavior was unchanged since it's consistent with
marking without region. But this is not my personal preference.
I have dozens of customized options in my init file, even for features
that I implemented, my customization still differs from default values
that make sense for most users.  The default value of the new option
`dired-mark-region' could be changed too in case more people
will demand this.

bug#39902: 28.0.50; Marking in dired with active region

[Drew Adams]

> > The docstring of `dired-mark-inclusive' should be enhanced a bit I
> > think.  You could add one sentence about what "inclusive" means, and
> > another saying that other (un-)marking commands are also covered.
> 
> I enhanced the docstring, renamed to `dired-mark-region',
> and pushed to master.
> 
> The default behavior was unchanged since it's consistent with
> marking without region. But this is not my personal preference.
> I have dozens of customized options in my init file, even for features
> that I implemented, my customization still differs from default values
> that make sense for most users.  The default value of the new option
> `dired-mark-region' could be changed too in case more people
> will demand this.

Thank you for changing the name of the option.  I meant
to say something about that, but forgot.

I don't know what you have as the doc string (I don't
have the diff/patch), but here's my opinion about the
option description:

It's _not_ good to express it in the terms you described:
as being about including or excluding the limit at the
region end.  That's not it at all, IMO.

This should be expressed in terms of the behavior being
either line-oriented (as is nearly all of Dired) or
file-name oriented.

Put differently, the description should say that the
two choices are these:

1. Mark if _any_ part of the file's line is selected.
2. Mark if _all_ of the file name is selected.

(Where "selected" means "in the region".)

That's much clearer, I think.  It's expressed in terms
of what users do and see.  Either you need to select
some part of the line or you need to select all of the
file name.  What could be simpler?

(Anyway, I'm glad we've more or less reached agreement.)

bug#39902: 28.0.50; Marking in dired with active region

[Juri Linkov]

> It's _not_ good to express it in the terms you described:
> as being about including or excluding the limit at the
> region end.  That's not it at all, IMO.
>
> This should be expressed in terms of the behavior being
> either line-oriented (as is nearly all of Dired) or
> file-name oriented.
>
> Put differently, the description should say that the
> two choices are these:
>
> 1. Mark if _any_ part of the file's line is selected.
> 2. Mark if _all_ of the file name is selected.
>
> (Where "selected" means "in the region".)
>
> That's much clearer, I think.  It's expressed in terms
> of what users do and see.  Either you need to select
> some part of the line or you need to select all of the
> file name.  What could be simpler?
>
> (Anyway, I'm glad we've more or less reached agreement.)

Thanks, now the option is changed to provide two values to distinguish
line/file name based cases instead of exclusive/inclusive.

bug#39902: 28.0.50; Marking in dired with active region

[Drew Adams]

> > (Anyway, I'm glad we've more or less reached agreement.)
> 
> Thanks, now the option is changed to provide two values to distinguish
> line/file name based cases instead of exclusive/inclusive.

Sounds good.  Thx.

bug#39902: 28.0.50; Marking in dired with active region

[Drew Adams]

> My vote is to use what I suggested, or similar:
> 
> (progn (goto-char end)
> 	 (when (bolp) (backward-char))
> 	 (line-end-position))

This (and I guess the variants that others
proposed) has a bug when point is at bol, the
region is empty, and `use-empty-active-region'
is non-nil.  In that case it raises an error
saying that "start > end" (which is not a very
clear error message in general, BTW).

This code seems to DTRT:

(progn (goto-char end)
       (when (and (bolp) (> end beg))
         (backward-char))
       (line-end-position))

[Non-nil option `use-empty-active-region' is
a pesky use case.  A guess is that there are
other, similar bugs lurking in Emacs.  I
wonder how many times we actually test for
that use case when we use `use-region-p'.]

bug#39902: 28.0.50; Marking in dired with active region

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> > In Dired+, though I define command
> > `diredp-mark-region-files' (which, as has
> > been pointed out, DTRT wrt this bug), I
> > don't bind it to a key, by default.
>
> IIUC, what Michael described is not like Dired+,
> but more like another your library zones.el,
> i.e. after activating the region, as you move point
> in the Dired buffer, the region highlighting should
> be updated to put region faces only on file names
> using multiple regions, including the file name
> of the current line, regardless of where point
> is located on the current line: either before or
> after the file name, the file name will be highlighted.

I don't care that much what is highlighted.  I just care about how the
region, i.e. the current value of point and mark, are interpreted.

Michael.

bug#39902: 28.0.50; Marking in dired with active region

[Michael Heerdegen]

Drew Adams <drew.adams@oracle.com> writes:

> Could you give a recipe/example of your use of keyboard keys for this,
> or otherwise explain the rationale for it?

Say the files in the dired buffer are photos/songs or so.  I mark all of
them, or those of them I'm interested in.  I open the files with a
viewer or vlc or whatever.  There I have a look at them, in the same
order as they originally appeared in dired.  Now say I am interrupted,
and/or I have deleted some of the files, and want to resume with the
rest of the files, or some other subset.  I.e. I want to mark subsets
(of subsequent files) in a dired buffer to look at the files in this
order, and the most natural way for me to do this is to use the region
for marking.

Michael.

bug#39902: 28.0.50; Marking in dired with active region

[Drew Adams]

> > Could you give a recipe/example of your use of
> > keyboard keys for this, or otherwise explain
> > the rationale for it?
> 
> Say the files in the dired buffer are photos/songs or so.  I mark all of
> them, or those of them I'm interested in.  I open the files with a
> viewer or vlc or whatever.  There I have a look at them, in the same
> order as they originally appeared in dired.  Now say I am interrupted,
> and/or I have deleted some of the files, and want to resume with the
> rest of the files, or some other subset.  I.e. I want to mark subsets
> (of subsequent files) in a dired buffer to look at the files in this
> order, and the most natural way for me to do this is to use the region
> for marking.

I still don't understand well.

1. You mark some files in Dired, then open them in
some other app.  Those files are still marked in
Dired, I suppose.  Or do you unmark them?  Or
doesn't it matter?

2. In that app, you do something with the files,
viewing and manipulating them in the same order
they had in Dired.  You may even delete some or
add some new ones.

3. You're interrupted.  How so - is Emacs closed?
is the other app closed?  What's the significance
of the interruption?

4. Later (same Emacs session?) you want to resume
using the external app with some of the marked files
you haven't yet manipulated.

That much I get.  I don't understand the rest.

5. You want to mark, in Dired, some of the files
you haven't yet worked with in the app.  OK.

"to look at the files in this order"  In what order?
What's the importance of the order?

Can you describe what you want to do at this point?
In particular, what do you want to do wrt selecting
and then marking the selected files?

IOW, I still have the same question: What's your
expected use of keyboard keys for this, and why?

For example, why wouldn't you just use `g' (to
refresh the listing, to reflect deleted or added
files), then `C-u 99999 m' starting where you left
off?

To be clear, I'm not trying to say you should do
something different from what you're requesting.
I'm just trying to understand what you want to do
and why.

bug#39902: 28.0.50; Marking in dired with active region

[Michael Heerdegen]

Drew Adams <drew.adams@oracle.com> writes:

> I still don't understand well.

Oh dear...ok.

> 1. You mark some files in Dired, then open them in
> some other app.  Those files are still marked in
> Dired, I suppose.  Or do you unmark them?  Or
> doesn't it matter?

Typically they are still marked.

> 2. In that app, you do something with the files,
> viewing and manipulating them in the same order
> they had in Dired.  You may even delete some or
> add some new ones.

Yes.

> 3. You're interrupted.  How so - is Emacs closed?

No no.  But I didn't use Emacs in the meantime.  Doesn't that count as
interrupted?

> is the other app closed?

Typically, yes.

> What's the significance of the interruption?

That I'm typically done with a subset of the previously marked files,
and I want to restart the external app or whatever with the rest of the
files, or a subset of them.

> 4. Later (same Emacs session?)

Yes, same session.

> 5. You want to mark, in Dired, some of the files
> you haven't yet worked with in the app.  OK.
>
> "to look at the files in this order"  In what order?

The order the files appear in the dired buffer.

> What's the importance of the order?

If I did not have a look at all of the files in the external app, and
the external app would present the files to me in some different order,
it would be hard to mark "the rest" of the files in dired to continue.

> For example, why wouldn't you just use `g' (to
> refresh the listing, to reflect deleted or added files),

I do that of course.

> then `C-u 99999 m' starting where you left off?

I could do that.  I didn't use to use these keys because I just
... wanted to use the region.  Plus, maybe I don't want to continue with
all of the remaining files but only a subset?

> To be clear, I'm not trying to say you should do
> something different from what you're requesting.

Yeah, and I think this is only just one random personal use case of `m'
with active region, let's not overstate this case.  I expect marking in
dired with region active to always behave the same no matter why I do
it.

> I'm just trying to understand what you want to do and why.

If you didn't understand now I'm willing to pay a flight to Germany so I
can show you ;-)


Michael.

bug#39902: 28.0.50; Marking in dired with active region

[Drew Adams]

Thanks for the details.  Sorry about not getting it.

> > `C-u 99999 m' starting where you left off?
> 
> I could do that.  I didn't use to use these keys because I just
> ... wanted to use the region.  Plus, maybe I don't want to continue with
> all of the remaining files but only a subset?

OK.  Confirming:

1. You could use `C-u <some number> m', and it would
   be about as easy (number of keystrokes).  You
   might have to guess <some number>, if you wanted
   only some of the remaining files.

2. The point is that, regardless of _why_ you might
   want to mark the files in the region, doing that
   should just work, where "work" means that any file
   with any part of its line in the active region
   gets marked.  (Likewise, for unmarking, flagging,
   changing marks, etc.)

   As you put it:

   > I expect marking in dired with region active to
   > always behave the same no matter why I do it.

As I think I've indicated, I agree 100%.  And I think
the fix is trivial, and it has already been given in
this thread (more than once).  The bug, found by
Stephen Berman, was presumably just a typo in the
first place:

(progn (goto-char end) (line-beginning-position))
should be
(progn (goto-char end) (line-end-position))

Hopefully someone will apply that fix.

> If you didn't understand now I'm willing to pay a
> flight to Germany so I can show you ;-)

In a short while, flights will be almost free, in
money terms - unfortunately for world health. ;-)

bug#39902: 28.0.50; Marking in dired with active region

[martin rudalics]

 > What I expect is a behavior analogue to "graphical" file browsers (with
 > icons and such - I don't use one, but anyway).  When you mark a region
 > there with the mouse, all files "touched" are in.  And it's enough when
 > the icon is included, i.e. the file is not identified with the
 > occurrence of the name on the screen but with the whole representation,
 > including the icon etc.  I guess that's where my way of thinking comes
 > from.

Such "graphical" file browsers are line-based, they do not have a way to
specify a position within such a line unless you are in the (usually F2
invoked) rename mode which puts a mask on the file name whose contents
you can modify.

martin

bug#39902: 28.0.50; Marking in dired with active region

[Michael Heerdegen]

martin rudalics <rudalics@gmx.at> writes:

> Such "graphical" file browsers are line-based, they do not have a way
> to specify a position within such a line unless you are in the
> (usually F2 invoked) rename mode which puts a mask on the file name
> whose contents you can modify.

I don't get your argument.  FWIW, most of these browsers have different
kinds of "views", and I have in mind the view that is not line based but
uses a grid of icons with names under them.  Marking a region with the
mouse happens continuously.

What I want to say here is that the current behavior makes no sense to
me.  And I very much think that I'm not the only one.  I don't want to
justify why I have this expectation and be told that my mental model is
wrong.  There is no way to mathematically prove whose expectations are
right and whose are wrong.  These expectations are always subjective.
When some users are confused by the current behavior, it would be good
to improve Emacs when it's simple as it is here.

Michael.

bug#39902: 28.0.50; Marking in dired with active region

[Drew Adams]

> FWIW, most of these browsers have different
> kinds of "views", and I have in mind the view
> that is not line based but uses a grid of icons
> with names under them.  Marking a region with
> the mouse happens continuously.
> 
> What I want to say here is that the current
> behavior makes no sense to me.  And I very much
> think that I'm not the only one.  I don't want
> to justify why I have this expectation and be
> told that my mental model is wrong...
> When some users are confused by the current
> behavior, it would be good to improve Emacs when
> it's simple as it is here.

Ah, I think maybe I'm starting to understand.  (Maybe.)

In your external app you'll select some files, in
a particular order (e.g. as presented in that app).
You might do so using the mouse (in that app), but
that's not really important for the use of Emacs.

Then, you want that selection, made in that app, in
its particular order, to be reflected as a selection
in Dired.

Is that right, so far?

If so, what if the order is so different from the
sort order in Dired that the resulting "selection"
in Dired would be a noncontiguous region - multiple
zones, as Juri mentioned?  Is that a problem?

Assuming that's not a problem (e.g. Dired has the
same order, since the original order came from
Dired - but see below), how would you transfer a
selection in the external app to a selection
(region) in Emacs?

If that's not really needed, then why wouldn't
just `g' in Dired (to refresh the listing)
followed by, say, `C-u 9999 m' work?

I guess `g' might not do what you want if Dired's
sort order is by date/time, since the external app
could have updated some files, making them more
recent, so the order in Dired would change from
what it was originally, and the Dired selection
you would need might even be noncontiguous (?).

Dunno whether I'm on the right track in starting
to understand.  Let me know.

(I'm not trying to make you justify why you want
what you want.  I'm just trying to understand it
better.)

bug#39902: 28.0.50; Marking in dired with active region

[Michael Heerdegen]

Drew Adams <drew.adams@oracle.com> writes:

> If so, what if the order is so different from the sort order in Dired
> that the resulting "selection" in Dired would be a noncontiguous
> region - multiple zones, as Juri mentioned?  Is that a problem?

That would be a problem.  I just try to avoid this case.

> Assuming that's not a problem (e.g. Dired has the
> same order, since the original order came from
> Dired - but see below), how would you transfer a
> selection in the external app to a selection
> (region) in Emacs?

I'm using the name of the file at the "border" between files I had
looked at and those I didn't (typically the last file I handled in the
external app).

> I guess `g' might not do what you want if Dired's
> sort order is by date/time, since the external app
> could have updated some files, making them more
> recent, so the order in Dired would change from
> what it was originally, and the Dired selection
> you would need might even be noncontiguous (?).

As said, I just try to avoid that case.

Michael.

bug#39902: 28.0.50; Marking in dired with active region

[martin rudalics]

 >> Such "graphical" file browsers are line-based, they do not have a way
 >> to specify a position within such a line unless you are in the
 >> (usually F2 invoked) rename mode which puts a mask on the file name
 >> whose contents you can modify.
 >
 > I don't get your argument.  FWIW, most of these browsers have different
 > kinds of "views", and I have in mind the view that is not line based but
 > uses a grid of icons with names under them.  Marking a region with the
 > mouse happens continuously.

I used the line-based (aka "detailed view") paradigm because it's the
nearest equivalence to 'dired' those file browsers usually provide.  If
you prefer the "a grid of icons with names under them" paradigm, then
the difference is just as evident: You cannot, for example, mark only an
icon and not mark its name in such a view.

The point I want to make is that in file browsers and managers the thing
that stands for a file on the screen - text, icon or thumbnail - is an
atomic entity.  You cannot mark only part of it (apart from in-place
renaming).

 > What I want to say here is that the current behavior makes no sense to
 > me.  And I very much think that I'm not the only one.  I don't want to
 > justify why I have this expectation and be told that my mental model is
 > wrong.  There is no way to mathematically prove whose expectations are
 > right and whose are wrong.  These expectations are always subjective.
 > When some users are confused by the current behavior, it would be good
 > to improve Emacs when it's simple as it is here.

The only way to put this into work reliably is to provide a special mode
that restricts highlighting to whole lines.

martin

bug#39902: 28.0.50; Marking in dired with active region

[Michael Heerdegen]

martin rudalics <rudalics@gmx.at> writes:

> > When some users are confused by the current behavior, it would be good
> > to improve Emacs when it's simple as it is here.
>
> The only way to put this into work reliably is to provide a special
> mode that restricts highlighting to whole lines.

I don't see a reason for that claim.  We have one behavior now, and it
works reliably.  The behavior I expect would function with comparable
reliability.

Michael.

bug#39902: transient

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> Thanks for mentioning it.  Now toggling per region is implemented
> here:

Thanks.

Patch looks reasonable.  I tried it quickly.  It works - but the last
line covered by the region is never included in toggling, even when it
is completely inside the region.  I'm using dired-mark-region ->
inclusive.

Michael.

bug#39902: 28.0.50; Marking in dired with active region

[Juri Linkov]

>> Thanks for mentioning it.  Now toggling per region is implemented
>> here:
>
> Thanks.
>
> Patch looks reasonable.  I tried it quickly.  It works - but the last
> line covered by the region is never included in toggling, even when it
> is completely inside the region.  I'm using dired-mark-region ->
> inclusive.

Maybe it doesn't work because after Drew asked me to use better names,
I changed the option values from 'exclusive/inclusive' to 'file/line'.
So maybe the patch will work when using dired-mark-region -> line.

bug#39902: 28.0.50; Marking in dired with active region

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> So maybe the patch will work when using dired-mark-region -> line.

Yes, that was it, now it works as expected :-)

Thanks,

Michael.

bug#39902: 28.0.50; Marking in dired with active region

[Juri Linkov]

>> So maybe the patch will work when using dired-mark-region -> line.
>
> Yes, that was it, now it works as expected :-)

Thanks for checking, now pushed to master in commit 25390b28c4.

It seems there are no more Dired commands that could depend on region :-)