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

classic Classic list List threaded Threaded
56 messages Options
123
Reply | Threaded
Open this post in threaded view
|

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



Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

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

Michael Heerdegen
In reply to this post by Michael Heerdegen
Juri Linkov <[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|

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

Juri Linkov-2
>> 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.



Reply | Threaded
Open this post in threaded view
|

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.



Reply | Threaded
Open this post in threaded view
|

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

Michael Heerdegen
In reply to this post by Juri Linkov-2
Juri Linkov <[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|

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

Juri Linkov-2
> 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:



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'.


caja.png (14K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Michael Heerdegen
Juri Linkov <[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|

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'.



Reply | Threaded
Open this post in threaded view
|

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

Juri Linkov-2
> 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.



Reply | Threaded
Open this post in threaded view
|

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.



Reply | Threaded
Open this post in threaded view
|

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

martin rudalics
In reply to this post by Michael Heerdegen
 > 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



Reply | Threaded
Open this post in threaded view
|

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

Michael Heerdegen
In reply to this post by Drew Adams
Drew Adams <[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|

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

Michael Heerdegen
In reply to this post by Juri Linkov-2
Juri Linkov <[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|

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

Michael Heerdegen
In reply to this post by Drew Adams
Drew Adams <[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|

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

Michael Heerdegen
In reply to this post by martin rudalics
martin rudalics <[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|

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

Drew Adams
In reply to this post by Michael Heerdegen
> > 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.



Reply | Threaded
Open this post in threaded view
|

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

Drew Adams
In reply to this post by Michael Heerdegen
> 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.)



Reply | Threaded
Open this post in threaded view
|

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

martin rudalics
In reply to this post by Michael Heerdegen
 >> 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



Reply | Threaded
Open this post in threaded view
|

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

Juri Linkov-2
In reply to this post by 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?



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.

dired-mark-3.png (8K) Download Attachment
123