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?