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.