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.

Making Emacs popular again with a video

[Nathan Colinet]

Hello,

I read on the mailing list that you're looking for a way to make Emacs 
popular again. I thought I could share my idea.

I started using emacs a year ago and when I started everything was 
really confusing, what is a frame, what is a buffer, how to install 
packages, what are major and minor modes, etc.. I wanted to give up but 
then I saw a 1 hour talk about Emacs that shows how powerful it is. Then 
I was hooked. Unfortunately the sound was no good at all and it was way 
too long. I think it could be really benefic for emacs to have a 5-10 
minutes video that would present Emacs not as an old obscure porgram but 
as an amazing fresh looking tool that drastically improves efficiency. I 
think people nowadays need an out-of-the-box experience, that's why 
promoting doom-emacs or spacemacs might be better than the default Emacs.

I think if the video is well realised it could really be a huge win.

Stay safe and well,

Nathan Colinet

Re: Making Emacs popular again with a video

[Nathan Colinet]

Hi,

I agree that's too advanced for a beginner user.

On 2020-05-09 09:50, Andreas Röhler wrote:
>
>
> Am 08.05.20 um 10:26 schrieb Nathan Colinet:
>> Hello,
>>
>> I read on the mailing list that you're looking for a way to make 
>> Emacs popular again. I thought I could share my idea.
>>
>> I started using emacs a year ago and when I started everything was 
>> really confusing, what is a frame, what is a buffer, how to install 
>> packages, what are major and minor modes, etc.. I wanted to give up 
>> but then I saw a 1 hour talk about Emacs that shows how powerful it 
>> is. Then I was hooked. Unfortunately the sound was no good at all and 
>> it was way too long. I think it could be really benefic for emacs to 
>> have a 5-10 minutes video that would present Emacs not as an old 
>> obscure porgram but as an amazing fresh looking tool that drastically 
>> improves efficiency. I think people nowadays need an out-of-the-box 
>> experience, that's why promoting doom-emacs or spacemacs might be 
>> better than the default Emacs.
>>
>> I think if the video is well realised it could really be a huge win.
>>
>> Stay safe and well,
>>
>> Nathan Colinet
>>
>>
>>
>
> Hi,
>
> thanks bringing that up. Agree such a video might be helpful. The 
> reasons however, why Emacs is a kind of niche nowadays are multiple 
> and complex. Leaving apart all items Emacs itself can't change, there 
> is something which can be done IMO: making Emacs ready for a beginner 
> in programming resp. for non-programmers. Make Emacs appear mannerly 
> as just an editor first. Which also means: at the beginning leave 
> apart all complex stuff useful for advanced programmers only.
>
> For instance at "Introduction" fairly everything in first paragraphs 
> IMHO may be dropped resp. should be moved at later sections. Copy 
> stuff below for the convenience of the reader here.
>
> All the day enjoying Emacs,
> Andreas
>
> Copy:
>
> Introduction
> ************
>
> You are reading about GNU Emacs, the GNU incarnation of the advanced,
> self-documenting, customizable, extensible editor Emacs.  (The ‘G’ in
> GNU (GNU’s Not Unix) is not silent.)
>
>    We call Emacs “advanced” because it can do much more than simple
> insertion and deletion of text.  It can control subprocesses, indent
> programs automatically, show multiple files at once, edit remote files
> like they were local files, and more.  Emacs editing commands operate in
> terms of characters, words, lines, sentences, paragraphs, and pages, as
> well as expressions and comments in various programming languages.
>
>    “Self-documenting” means that at any time you can use special
> commands, known as “help commands”, to find out what your options are,
> or to find out what any command does, or to find all the commands that
> pertain to a given topic.  *Note Help::.
>
>    “Customizable” means that you can easily alter the behavior of Emacs
> commands in simple ways.  For instance, if you use a programming
> language in which comments start with ‘<**’ and end with ‘**>’, you can
> tell the Emacs comment manipulation commands to use those strings (*note
> Comments::).  To take another example, you can rebind the basic cursor
> motion commands (up, down, left and right) to any keys on the keyboard
> that you find comfortable.  *Note Customization::.
>

Re: Making Emacs popular again with a video

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > For instance at "Introduction" fairly everything in first paragraphs 
  > > IMHO may be dropped resp. should be moved at later sections. Copy 
  > > stuff below for the convenience of the reader here.

Perhaps there is no longer a need to inform the public of those
three basic capabilities of Emacs.

Do Emacs's current competitors have the same capabilities?

    > You are reading about GNU Emacs, the GNU incarnation of the advanced,
    > self-documenting, customizable, extensible editor Emacs. 
-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

GNU Emacs raison d'etre

[excalamus--- via Emacs development discussions.]

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

May 11, 2020, 23:12 by rms@gnu.org:

> Perhaps there is no longer a need to inform the public of those
> three basic capabilities of Emacs.
>
> Do Emacs's current competitors have the same capabilities?
>
> > You are reading about GNU Emacs, the GNU incarnation of the advanced,
> > self-documenting, customizable, extensible editor Emacs. 
>
What are we competing for?  I feel that while other threads are examining "missing features", it would be helpful to examine what GNU Emacs does offer.  Not only in software features, but maybe also in philosophy, community, or tradition.

What is it about GNU Emacs that makes this mailing list bustle with enthusiasm?  Other editors use GPL, provide source code, have documentation, are customizable, and extendable.  There's something in how GNU Emacs implements these that is different.  I feel like there are taters to find if we dig a little.

Is it because Emacs Lisp is unique to Emacs that Emacs teaches as well as documents?
Is it that by being a pseudo-Lisp machine, Emacs puts users in the zone of proximal development?
Is GNU Emacs the best embodiment of the GNU philosophy?  


[-- Attachment #2: Type: text/html, Size: 1642 bytes --]

Re: GNU Emacs raison d'etre

[Karl Fogel]

On 12 May 2020, excalamus--- via "Emacs development discussions." wrote:
>May 11, 2020, 23:12 by rms@gnu.org:
>What are we competing for?  I feel that while other threads are
>examining "missing features", it would be helpful to examine what GNU
>Emacs does offer.  Not only in software features, but maybe also in
>philosophy, community, or tradition.
>
>What is it about GNU Emacs that makes this mailing list bustle with
>enthusiasm?  Other editors use GPL, provide source code, have
>documentation, are customizable, and extendable.  There's something
>in how GNU Emacs implements these that is different.  I feel like
>there are taters to find if we dig a little.
>
>Is it because Emacs Lisp is unique to Emacs that Emacs teaches as
>well as documents?
>Is it that by being a pseudo-Lisp machine, Emacs puts users in the
>zone of proximal development?
>Is GNU Emacs the best embodiment of the GNU philosophy? 

Sure, I'll take the bait:

To the best of my knowledge, no other editing environment rewards sustained user investment so well.

With Emacs, if you keep investing -- i.e., acquiring knowledge and skill by reading documentation, writing customizations, and exploring others' customizations -- Emacs keeps rewarding you with a better and better editing experience.  The degree to which it does this seems normal to many of us here, because we've been used to it for many years.  I think we sometimes fail to appreciate the degree to which non-users, potential ("Emacs-curious") users, and even many actual new users are *not* aware of it: they don't realize how enormous the reward can be, and how broad its scope.

This should probably affect how we think about promoting Emacs.  Emacs shouldn't necessarily try to attract everyone who needs to edit text [1].  Many people who edit text nonetheless don't view text editing as a primary activity worthy of investment.  Those users are not good candidates for Emacs.

Emacs's best prospects are with the sorts of people who *do* see -- or who can be persuaded to see -- text editing as worthy of investment.  There's a loose correlation in which good programmers tend to be those sorts of people, because good programmers are usually willing to invest in learning their tools in general.  E.g., they'll learn their text editor the same way they'll learn their debugger, their programming framework, etc.  But the set isn't limited to just programmers.  For example, scientists and other academics who edit LaTeX documents are often good candidates for Emacs usage, because by both temperament and life situation they are well-positioned to understand how sustained investment in learning their editing environment could pay off in the long term.

So I suggest that GNU Emacs's raison d'être is to be the text editor that best rewards sustained user investment.

I think Emacs actually does so right now, too, and that we just haven't always communicated this fact clearly enough.

Thus, instead of focusing on making Emacs easier for new users, it would be better to focus on smoothing out discontinuities in Emacs' investment-reward curve.  The long-term health of Emacs as a project will not come from a large number of lightly committed users who don't appreciate what makes Emacs unique, but rather from a smaller number of users for whom Emacs is important and irreplaceable.

I'm not suggesting that we shouldn't improve the new-user experience in Emacs, of course.  We should make it as easy as possible for newcomers *while still prioritizing invested users*.   In user experience design, there are frequently tradeoffs between making things easy for newcomers and making them rewarding for experts.  Unfortunately, too often in design discussions, the new user experience automatically wins out -- it's like some kind of magic card that people play (even sometimes unconsciously) in UI/UX discussions.  For Emacs, this would be a mistake.  Emacs's great strength will never be in its new-user experience, and this is in some ways a necessary consequence of Emacs being so great for highly invested long-term users.

This also suggests that the sorts of features that highly-invested users tend to want -- for example, LSP-based features -- should be more important to us than how square the menus are or what menu items are shown in a default startup configuration.  When we make decisions that disappoint the core user base, we endanger the project much more than when we make decisions that disappoint users (or potential users) who weren't likely to become highly invested anyway.

(The fact that Emacs promotes free software by being a good GPL'd program is nice too, and is important to many of us, but it's not unique to Emacs.)

Best regards,
-Karl

Re: GNU Emacs raison d'etre

[Andreas Röhler]

On 13.05.20 18:18, Karl Fogel wrote:
> On 12 May 2020, excalamus--- via "Emacs development discussions." wrote:
>> May 11, 2020, 23:12 by rms@gnu.org:
>> What are we competing for?  I feel that while other threads are
>> examining "missing features", it would be helpful to examine what GNU
>> Emacs does offer.  Not only in software features, but maybe also in
>> philosophy, community, or tradition.
>>
>> What is it about GNU Emacs that makes this mailing list bustle with
>> enthusiasm?  Other editors use GPL, provide source code, have
>> documentation, are customizable, and extendable.  There's something
>> in how GNU Emacs implements these that is different.  I feel like
>> there are taters to find if we dig a little.
>>
>> Is it because Emacs Lisp is unique to Emacs that Emacs teaches as
>> well as documents?
>> Is it that by being a pseudo-Lisp machine, Emacs puts users in the
>> zone of proximal development?
>> Is GNU Emacs the best embodiment of the GNU philosophy?
> Sure, I'll take the bait:
>
> To the best of my knowledge, no other editing environment rewards sustained user investment so well.
>
> With Emacs, if you keep investing -- i.e., acquiring knowledge and skill by reading documentation, writing customizations, and exploring others' customizations -- Emacs keeps rewarding you with a better and better editing experience.  The degree to which it does this seems normal to many of us here, because we've been used to it for many years.  I think we sometimes fail to appreciate the degree to which non-users, potential ("Emacs-curious") users, and even many actual new users are *not* aware of it: they don't realize how enormous the reward can be, and how broad its scope.
>
> This should probably affect how we think about promoting Emacs.  Emacs shouldn't necessarily try to attract everyone who needs to edit text [1].  Many people who edit text nonetheless don't view text editing as a primary activity worthy of investment.  Those users are not good candidates for Emacs.
>
> Emacs's best prospects are with the sorts of people who *do* see -- or who can be persuaded to see -- text editing as worthy of investment.  There's a loose correlation in which good programmers tend to be those sorts of people, because good programmers are usually willing to invest in learning their tools in general.  E.g., they'll learn their text editor the same way they'll learn their debugger, their programming framework, etc.  But the set isn't limited to just programmers.  For example, scientists and other academics who edit LaTeX documents are often good candidates for Emacs usage, because by both temperament and life situation they are well-positioned to understand how sustained investment in learning their editing environment could pay off in the long term.
>
> So I suggest that GNU Emacs's raison d'être is to be the text editor that best rewards sustained user investment.
>
> I think Emacs actually does so right now, too, and that we just haven't always communicated this fact clearly enough.
>
> Thus, instead of focusing on making Emacs easier for new users, it would be better to focus on smoothing out discontinuities in Emacs' investment-reward curve.  The long-term health of Emacs as a project will not come from a large number of lightly committed users who don't appreciate what makes Emacs unique, but rather from a smaller number of users for whom Emacs is important and irreplaceable.
>
> I'm not suggesting that we shouldn't improve the new-user experience in Emacs, of course.  We should make it as easy as possible for newcomers *while still prioritizing invested users*.   In user experience design, there are frequently tradeoffs between making things easy for newcomers and making them rewarding for experts.  Unfortunately, too often in design discussions, the new user experience automatically wins out -- it's like some kind of magic card that people play (even sometimes unconsciously) in UI/UX discussions.  For Emacs, this would be a mistake.  Emacs's great strength will never be in its new-user experience, and this is in some ways a necessary consequence of Emacs being so great for highly invested long-term users.

Agree with everything beside two last paragraphs. Enjoying the 
possibilities to extend and assisting new users being productive seems 
no contradiction. May you give an example where an smooth entrance 
hinders the power of more complex functionality?

Sure, as it was mentioned in other post, writing an introduction for 
beginners is difficult, it is an art of its own.


>
> This also suggests that the sorts of features that highly-invested users tend to want -- for example, LSP-based features -- should be more important to us than how square the menus are or what menu items are shown in a default startup configuration.  When we make decisions that disappoint the core user base, we endanger the project much more than when we make decisions that disappoint users (or potential users) who weren't likely to become highly invested anyway.
>
> (The fact that Emacs promotes free software by being a good GPL'd program is nice too, and is important to many of us, but it's not unique to Emacs.)
>
> Best regards,
> -Karl
>

Re: GNU Emacs raison d'etre

[Karl Fogel]

On 13 May 2020, Andreas Röhler wrote:
>Agree with everything beside two last paragraphs. Enjoying the
>possibilities to extend and assisting new users being productive seems 
>no contradiction. May you give an example where an smooth entrance
>hinders the power of more complex functionality?

The newcomer-vs-expert tradeoff is real, and it's pervasive throughout UI and UX design.

One example is button-based functionality.  For both experts and newcomers, those buttons/icons take away screen real estate -- but for newcomers they make features easier to find, so it's worth it.  For experts, they *just* take away screen real estate, while providing little or no benefit.

Use of small symbols to indicate state in the modeline is another area.  Experienced users know what "**" in the mode line means, what "%" means, etc.  Newcomers are frequently confused by the mode line; it is noise to them, until they know how to interpret it -- but that takes a bit of investment.  Now, we could provide bigger, more verbose signs of current state -- but then we'd be taking away screen real estate again.

Another area is the keybinding space and the minibuffer.  Just about every time I have watched a new user use Emacs, I have noticed how frequently they accidentally hit some key combination or sequence and wind up in some weird state that they never meant to be in -- and don't know how to get out of.  Often they have minibuffer prompts sitting around all the time, and are unaware that Emacs is asking them for some piece of information (after all, the user didn't mean to put Emacs into that state and has no idea she did so).  But having those keybindings available is *good* for experts, as we know from personal experience.

I could go on.  I've taught many newcomers to Emacs, and often the things that are hardest for them are exactly the things that are *good* for the experienced user.

These design tradeoffs cannot be avoided.  It would be a fallacy to think that it's always possible to be *both* maximally newcomer-friendly and investor-friendly.  

(The term "user-friendly" is itself misleading.  There is no such thing as "a user" in a way that makes the term "user-friendly" meaningful.  Better terms would at least attempt to make important distinctions -- "newcomer-friendly", "expert-friendly", "ADHD-friendly", "limited-movement-friendly", "visually-impaired-friendly", etc -- and would encourage designers to understand that being good in some categories means being bad in others.)

Best regards,
-Karl

Re: GNU Emacs raison d'etre

[Dmitry Gutov]

On 13.05.2020 23:05, Karl Fogel wrote:
> Use of small symbols to indicate state in the modeline is another area.  Experienced users know what "**" in the mode line means, what "%" means, etc.  Newcomers are frequently confused by the mode line; it is noise to them, until they know how to interpret it -- but that takes a bit of investment.  Now, we could provide bigger, more verbose signs of current state -- but then we'd be taking away screen real estate again.
> 
> Another area is the keybinding space and the minibuffer.  Just about every time I have watched a new user use Emacs, I have noticed how frequently they accidentally hit some key combination or sequence and wind up in some weird state that they never meant to be in -- and don't know how to get out of.  Often they have minibuffer prompts sitting around all the time, and are unaware that Emacs is asking them for some piece of information (after all, the user didn't mean to put Emacs into that state and has no idea she did so).  But having those keybindings available is*good*  for experts, as we know from personal experience.

I might with agree with you principle, but both examples seem suspect.

First, the "low investment" editors frequently have higher density of 
information in the UI elements that correspond to our mode-line and 
fringe, margins, etc. Largely thanks to their technical capabilities 
(various-sized fonts, graphics, being able to fit different kinds of 
indicators together on a "fringe"). So it appears at least in this area 
Emacs has been overtaken purely on technical grounds.

Regarding the key combinations and the minibuffer, there is no hard 
evidence that our current behavior is supremely optimal. In fact, I'm 
fairly sure that by being risk-averse and resistant to change, and by 
having no UX experts around, Emacs loses out on some possible 
advancements in usability. Even expert-friendly ones.

So I would recommend not becoming complacent, or becoming assured that 
workflows you have spent some time getting accustomed to, can't be improved.

> I could go on.  I've taught many newcomers to Emacs, and often the things that are hardest for them are exactly the things that are*good*  for the experienced user.
> 
> These design tradeoffs cannot be avoided.  It would be a fallacy to think that it's always possible to be*both*  maximally newcomer-friendly and investor-friendly.

The last sentence is sensible, but it's generally beside the point: I'm 
sure we still have a long way to go in both directions.

And unfortunately, in practice around here "prioritizing invested users" 
somehow turns out to mean "let's not make existing users uncomfortable". 
By changing defaults, introducing new workflows, or changing old ones. 
Which, in the long run, serves neither crowd.

Re: GNU Emacs raison d'etre

[Karl Fogel]

On 13 May 2020, Dmitry Gutov wrote:
>I might with agree with you principle, but both examples seem suspect.
>
>First, the "low investment" editors frequently have higher density of
>information in the UI elements that correspond to our mode-line and 
>fringe, margins, etc. Largely thanks to their technical capabilities
>(various-sized fonts, graphics, being able to fit different kinds of 
>indicators together on a "fringe"). So it appears at least in this
>area Emacs has been overtaken purely on technical grounds.

*nod*.  There might be room for improvement in how Emacs uses various visual areas, though, having watched many different programmers using many different kinds of editors, I think Emacs's mode line actually scores pretty well on the indicator front (once one learns how to interpret it).

But in any case, note that these other editors also face this same tradeoff.  You can see it in Microsoft Word, for example: in recent versions, its default startup control panel looks like the cockpit of Boeing 747.  Experienced users complain noisily about it (you can find various blog posts and other chatter about this on the Net), but this UI change was made so that *new* users could find a visual path to anything they might be looking for.

The tradeoff will always be there, even if sometimes there is room for Emacs to improve -- i.e., room for Emacs to "get to the tradeoff point", so to speak.

>Regarding the key combinations and the minibuffer, there is no hard
>evidence that our current behavior is supremely optimal. In fact, I'm 
>fairly sure that by being risk-averse and resistant to change, and by
>having no UX experts around, Emacs loses out on some possible 
>advancements in usability. Even expert-friendly ones.
>
>So I would recommend not becoming complacent, or becoming assured that
>workflows you have spent some time getting accustomed to, can't be
>improved.

Absolutely.

But the particular *way* in which we've crowded the keybinding space is independent of the fact that the space is crowded, and necessarily must be crowded if it is to offer experts the quick access to functionality that they want.  Crowding the keybinding space is good for high-investment users and bad for newcomers (that's why newcomers to Emacs so often trip accidentally over unexpectedly combustible key sequences).  That tradeoff will always be there, no matter what the particular mapping of key sequences to functionality is.

So I think my example there holds up pretty well.

>> I could go on.  I've taught many newcomers to Emacs, and often the things that are hardest for them are exactly the things that are*good*  for the experienced user.
>> These design tradeoffs cannot be avoided.  It would be a fallacy to
>> think that it's always possible to be*both*  maximally
>> newcomer-friendly and investor-friendly.
>
>The last sentence is sensible, but it's generally beside the point:
>I'm sure we still have a long way to go in both directions.

Very good point: there are some things we could that would get us closer to the point where tradeoff decisions are necessary.  But not everything we contemplate doing will be in that category.  Some of the things we want to do will already *be* at the tradeoff point, and then we will have a decision to make.

>> This also suggests that the sorts of features that highly-invested
>> users tend to want -- for example, LSP-based features
>
>LSP is a high-investment feature?
>
>Reminder: it came to us from VS Code, Microsoft's text editor for
>programmers.

Not quite.  What I wrote, exactly, is that it is the sort of feature that highly-invested users tend to want.  That is different in a subtle way.  By not supplying the sorts of things that LSP would enable, we signal to high-investment users that there is an entire area of improvement that Emacs is not going to explore.  So while lack of LSP hurts both newcomers and experts, it discourages the experts more, because they are looking for signals that continued investment will lead to increased reward.

Put another way: LSP is the sort of thing that enables highly-invested users -- the kinds of people who write or would consider writing Elisp -- to build new functionality into Emacs, perhaps even functionality we cannot predict today.  While LSP is a good thing for all users, newcomers and experts alike, it specifically *rewards* further investment by users who are motivated to make (and capable of making) investments based on LSP's availability.  It is an expertise amplifier.  When we fail to include an expertise amplifier like that, we "bend the curve" -- in the wrong direction.

Best regards,
-Karl

Re: GNU Emacs raison d'etre

[Dmitry Gutov]

On 14.05.2020 01:04, Karl Fogel wrote:
> On 13 May 2020, Dmitry Gutov wrote:
>> I might with agree with you principle, but both examples seem suspect.
>>
>> First, the "low investment" editors frequently have higher density of
>> information in the UI elements that correspond to our mode-line and
>> fringe, margins, etc. Largely thanks to their technical capabilities
>> (various-sized fonts, graphics, being able to fit different kinds of
>> indicators together on a "fringe"). So it appears at least in this
>> area Emacs has been overtaken purely on technical grounds.
> 
> *nod*.  There might be room for improvement in how Emacs uses various visual areas, though, having watched many different programmers using many different kinds of editors, I think Emacs's mode line actually scores pretty well on the indicator front (once one learns how to interpret it).

I think the mode-line is more or less average by today's standards. But 
of course it wins on customizability. The fringes a significantly less 
functional, though. :-(

> But in any case, note that these other editors also face this same tradeoff.  You can see it in Microsoft Word, for example: in recent versions, its default startup control panel looks like the cockpit of Boeing 747.  Experienced users complain noisily about it (you can find various blog posts and other chatter about this on the Net), but this UI change was made so that *new* users could find a visual path to anything they might be looking for.
> 
> The tradeoff will always be there, even if sometimes there is room for Emacs to improve -- i.e., room for Emacs to "get to the tradeoff point", so to speak.

Yes, the tradeoff is somewhere in there, but my problem with the 
conclusion is that it would be really easy to misapply your principle 
(e.g. by saying we don't need fancier buttons, even though we probably 
do, or that the Getting Started guide is good enough and doesn't need 
improvement, and someone should go work on specialized Org-mode docs 
instead).

Making good use of it seems difficult.

The kind of person who *could* make a better judgment in this area is 
someone who specializes on UX. And they are rare guests around here.

> But the particular *way* in which we've crowded the keybinding space is independent of the fact that the space is crowded, and necessarily must be crowded if it is to offer experts the quick access to functionality that they want.  Crowding the keybinding space is good for high-investment users and bad for newcomers (that's why newcomers to Emacs so often trip accidentally over unexpectedly combustible key sequences).  That tradeoff will always be there, no matter what the particular mapping of key sequences to functionality is.

Are you sure that this particular aspect is _bad_ for new users, though? 
Nobody likes to stretch they hand too far. But I'll grant you this 
point, that Emacs is *somewhat* on the side of high-investment here.

This part is expected of a professional tool, however, and the 
experience for newcomers could be improved without taking away much from 
the "oldies". See the 'transient' package, for example, recently 
proposed for inclusion on emacs-devel.

>>> I could go on.  I've taught many newcomers to Emacs, and often the things that are hardest for them are exactly the things that are*good*  for the experienced user.
>>> These design tradeoffs cannot be avoided.  It would be a fallacy to
>>> think that it's always possible to be*both*  maximally
>>> newcomer-friendly and investor-friendly.
>>
>> The last sentence is sensible, but it's generally beside the point:
>> I'm sure we still have a long way to go in both directions.
> 
> Very good point: there are some things we could that would get us closer to the point where tradeoff decisions are necessary.  But not everything we contemplate doing will be in that category.  Some of the things we want to do will already *be* at the tradeoff point, and then we will have a decision to make.

Some of them, probably. At this point, I think, there are still a lot of 
decisions that would bring us closer to newcomer-friendliness while 
keeping no worse high-investment compatibility.

>>> This also suggests that the sorts of features that highly-invested
>>> users tend to want -- for example, LSP-based features
>>
>> LSP is a high-investment feature?
>>
>> Reminder: it came to us from VS Code, Microsoft's text editor for
>> programmers.
> 
> Not quite.  What I wrote, exactly, is that it is the sort of feature that highly-invested users tend to want.  That is different in a subtle way.  By not supplying the sorts of things that LSP would enable, we signal to high-investment users that there is an entire area of improvement that Emacs is not going to explore.  So while lack of LSP hurts both newcomers and experts, it discourages the experts more, because they are looking for signals that continued investment will lead to increased reward.

I'm glad that we both like LSP, or at least the idea of it.

But it seems these days almost everybody wants it, except for MS Word 
and Notepad users.

> Put another way: LSP is the sort of thing that enables highly-invested users -- the kinds of people who write or would consider writing Elisp -- to build new functionality into Emacs, perhaps even functionality we cannot predict today.  While LSP is a good thing for all users, newcomers and experts alike, it specifically *rewards* further investment by users who are motivated to make (and capable of making) investments based on LSP's availability.  It is an expertise amplifier.  When we fail to include an expertise amplifier like that, we "bend the curve" -- in the wrong direction.

There are certain aspects where LSP is not exactly perfect: the 
functionality it allows is limited by the protocol, and by LSP servers 
available currently. It's an "ecosystem amplifier", or maybe an 
equalizer even.

I mean, it for sure is great, not to be lagging in language support for 
a whole number of languages where we did before. But there are different 
protocols that allow more powerful extensibility. nREPL, for example.

Re: GNU Emacs raison d'etre

[Karl Fogel]

On 14 May 2020, Dmitry Gutov wrote:
>Yes, the tradeoff is somewhere in there, but my problem with the
>conclusion is that it would be really easy to misapply your principle 
>(e.g. by saying we don't need fancier buttons, even though we probably
>do, or that the Getting Started guide is good enough and doesn't need 
>improvement, and someone should go work on specialized Org-mode docs
>instead).
>
>Making good use of it seems difficult.

Any guiding principle can be misused, but that doesn't make it useless.

The particular misuses you cite above are speculative -- no one's actually saying those things, as far as I'm aware.

In a reply to Christopher Lemmer Webber just now [1], I got a little bit more specific:

  > If we just say "Emacs should be easier for newcomers to learn",
  > that's not a useful rallying cry IMHO.  If we say instead "Emacs
  > should try to attract newcomers who have a higher-than-average
  > probability of becoming high-investment users, and should explain
  > early on to those newcomers what the road ahead looks like", *then*
  > we have a high-level guiding principle we can actually use.

So there's some concrete guidance about *how* we might seek to improve the Getting Started guide (and other things like the Emacs web site, starter videos, etc):

* Tell newcomers up front that Emacs really starts to be worth it after a few years, not a few weeks.  Set expectations right from the start.

* Show them some of the abilities they will eventually have, so that they can see why it's worth it to make the investment.

* Also tell them about the ways in which Emacs may frustrate them along the way, and explain that those frustrations are common and are sometimes inevitably entangled with the same things that make Emacs winning in the long term.

I find it fairly easy to come up with ways in which this principle would provide guidance in certain decisions.  I could try to list more of those ways, if it would be helpful, but I just don't want to get into a sub-discussion about each such example.  It's meant to be a high-level principle, after all.

Ultimately, I personally find it helpful in thinking about how to teach Emacs and how to write packages.  Here is the principle, reworded slightly after a suggestion from H. Dieter Wilhelm:

"GNU Emacs's raison d'être is to be the text manipulation environment that best rewards sustained user investment."

Apparently some other people here find it useful as well.   You might or might not be one of them, but I can at least promise you that I'll never use this principle to make bad suggestions about ways in which Emacs should be made unfriendly to newcomers :-).

>The kind of person who *could* make a better judgment in this area is
>someone who specializes on UX. And they are rare guests around here.

More UX expertise would always help, naturally, but those of us who are here are not wholly ignorant of the field either, nor of the questions and tradeoffs that need to be dealt with.

>Are you sure that this particular aspect is _bad_ for new users, though?

Yes.  I am sure.

I've taught Emacs to a lot of people -- scores of them, at least; I don't keep track, but the sample size is large enough to be beyond merely anecdotal at this point.  I've watched newcomers run into the same obstacles over and over, and this particular obstacle is always one of the first they encounter.

>Nobody likes to stretch they hand too far. But I'll grant you
>this point, that Emacs is *somewhat* on the side of high-investment
>here.
>
>This part is expected of a professional tool, however, and the
>experience for newcomers could be improved without taking away much
>from the "oldies". See the 'transient' package, for example, recently 
>proposed for inclusion on emacs-devel.

I don't have any experience using 'transient', so I'd need more explanation from you to understand what you meant by that part.  (I tried to understand 'transient' from reading [2] and [3], but unfortunately -- and somewhat surprisingly! -- the documentation at those pages does not give a single concrete example of transient's use.)

However, your assertion that "the experience for newcomers could be improved without taking away much from the 'oldies'" is exactly what I'm arguing is not true.  I actually think we can't (much) improve this particular part of the experience for newcomers without taking away one of the things about Emacs that most rewards investment.

The newcomers who eventually *do* become experts do so in part by first stumbling across new commands accidentally (in that crowded keybinding space) and then using help tools like `C-h l' to see what they just did.  So one of the things we should prioritize is teaching newcomers how important those help facilities are and how to use them in a smart way.  I'm specifically saying that this is *more important for Emacs than it is for other editors*.  Sure, users of (say) the Atom editor should eventually know how to use the built-in help there too.  But it's a difference in prioritization: for Emacs users, using that built-in help is more important than it would be in other editors, and the methods and circumstances of using the help are different too.  So we should incorporate that fact into how we present Emacs to new users.

(Again, this is from at least some experience.  The users I've taught who have gone on to become proficient Emacs users are ones who invested very early in learning the various help facilities and when to use them.)

>Some of them, probably. At this point, I think, there are still a lot
>of decisions that would bring us closer to newcomer-friendliness while 
>keeping no worse high-investment compatibility.

That could be true, though I'm a bit more skeptical than you are.  In any case, it does not make the principle inoperative; it is consistent with the principle.

I believe we'll make better decisions if we keep in mind that "friendly to newcomers" is not, in itself, the primary goal.

>I'm glad that we both like LSP, or at least the idea of it.
>
>But it seems these days almost everybody wants it, except for MS Word
>and Notepad users.

Yes.  High-investment users, however, see more possibilities from LSP than low-investment users do -- they'll go farther with it.

>There are certain aspects where LSP is not exactly perfect: the
>functionality it allows is limited by the protocol, and by LSP servers 
>available currently. It's an "ecosystem amplifier", or maybe an
>equalizer even.
>
>I mean, it for sure is great, not to be lagging in language support
>for a whole number of languages where we did before. But there are
>different protocols that allow more powerful extensibility. nREPL, for
>example.

Ah, that's a technical question about the suitability of LSP for a particular problem space, and I'm not well-informed enough to have a useful opinion there.  If you say nREPL, I'm not going to argue! :-)

Best regards,
-Karl

[1] https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg01893.html

    From: Karl Fogel <kfogel@red-bean.com>
    To: Christopher Lemmer Webber <cwebber@dustycloud.org>
    Cc: ndame <ndame@protonmail.com>,  Emacs developers <emacs-devel@gnu.org>
    Subject: Re: What is the most useful potential feature which Emacs lacks?
    Date: Wed, 13 May 2020 23:08:04 -0500
    Message-ID: <87y2pvqhuj.fsf@red-bean.com>

[2] https://github.com/magit/transient/blob/master/lisp/transient.el

[3] https://emacsair.me/2019/02/14/transient-0.1/

Re: GNU Emacs raison d'etre

[Dmitry Gutov]

On 14.05.2020 07:56, Karl Fogel wrote:

 > Any guiding principle can be misused, but that doesn't make it useless.

 > The particular misuses you cite above are speculative -- no one's
 > actually saying those things, as far as I'm aware.

Actually, those examples are closer to the discussions I have taken 
part in (let's not change xxx because existing users will complain; and 
the newbies will just have to get in line, the entry barrier is high 
anyway, who cares if they have to learn one more thing to get started).

On the flip side, I don't remember anybody propose to make key bindings 
less "staggered".

> In a reply to Christopher Lemmer Webber just now [1], I got a little bit more specific:
> 
>    > If we just say "Emacs should be easier for newcomers to learn",
>    > that's not a useful rallying cry IMHO.  If we say instead "Emacs
>    > should try to attract newcomers who have a higher-than-average
>    > probability of becoming high-investment users, and should explain
>    > early on to those newcomers what the road ahead looks like", *then*
>    > we have a high-level guiding principle we can actually use.

I think we already do (the rest flocks to #1, #2 and #4 popular 
options). No need to try harder in that direction.

> So there's some concrete guidance about *how* we might seek to improve the Getting Started guide (and other things like the Emacs web site, starter videos, etc):
> 
> * Tell newcomers up front that Emacs really starts to be worth it after a few years, not a few weeks.  Set expectations right from the start.

That feels like giving up. And "worth it" depends on personal 
expectations. From reading comments on Reddit, converts from Vim, for 
instance, try Spacemacs or Doom Emacs, and seemingly become satisfied in 
a matter of days.

> * Show them some of the abilities they will eventually have, so that they can see why it's worth it to make the investment.

Not sure what you have in mind here. If it's a "here's not an Emacs 
would solve a problem", this could turn into a useful tutorial for 
journeyman emacsers.

> * Also tell them about the ways in which Emacs may frustrate them along the way, and explain that those frustrations are common and are sometimes inevitably entangled with the same things that make Emacs winning in the long term.

Not a bad advice, but deciding on such a list in official documentation 
might not be easy (people have opinions). Once we do decide, it would be 
better to try to improve these things first.

> Ultimately, I personally find it helpful in thinking about how to teach Emacs and how to write packages.  Here is the principle, reworded slightly after a suggestion from H. Dieter Wilhelm:
> 
> "GNU Emacs's raison d'être is to be the text manipulation environment that best rewards sustained user investment."

I still don't like it. It either means "you don't get much until you 
struggle for a while" (which just sounds discouraging) and/or "no other 
program comes even close at text manipulation", which is... pretty 
conceited and kind of limited at the same time. I mean, Emacs is great 
and all, but I don't have "text manipulation" as the #1 goal in my life. 
Or even among top 10 goals.

The higher-level things one can implement with Emacs Lisp are a lot more 
interesting.

>> Are you sure that this particular aspect is _bad_ for new users, though?
> 
> Yes.  I am sure.
> 
> I've taught Emacs to a lot of people -- scores of them, at least; I don't keep track, but the sample size is large enough to be beyond merely anecdotal at this point.  I've watched newcomers run into the same obstacles over and over, and this particular obstacle is always one of the first they encounter.

Okay, but is it still a problem after they've tried Emacs for a day, for 
instance? For a week?

These periods of time would of course suggest Emacs is not ideal for 
total newbies, but they're not the kind of "sustained investment" you 
described either.

>> This part is expected of a professional tool, however, and the
>> experience for newcomers could be improved without taking away much
>>from the "oldies". See the 'transient' package, for example, recently 
>> proposed for inclusion on emacs-devel.
> 
> I don't have any experience using 'transient', so I'd need more explanation from you to understand what you meant by that part.  (I tried to understand 'transient' from reading [2] and [3], but unfortunately -- and somewhat surprisingly! -- the documentation at those pages does not give a single concrete example of transient's use.)

You press 'C-x', wait a while - and it pops up a window with the 
descriptions of all commands whose bindings start with 'C-x'. Same for 
all other "incomplete" key sequences. Looks pretty handy for beginners.

> However, your assertion that "the experience for newcomers could be improved without taking away much from the 'oldies'" is exactly what I'm arguing is not true.  I actually think we can't (much) improve this particular part of the experience for newcomers without taking away one of the things about Emacs that most rewards investment.
> 
> The newcomers who eventually *do* become experts do so in part by first stumbling across new commands accidentally (in that crowded keybinding space) and then using help tools like `C-h l' to see what they just did.  So one of the things we should prioritize is teaching newcomers how important those help facilities are and how to use them in a smart way.  I'm specifically saying that this is *more important for Emacs than it is for other editors*.  Sure, users of (say) the Atom editor should eventually know how to use the built-in help there too.  But it's a difference in prioritization: for Emacs users, using that built-in help is more important than it would be in other editors, and the methods and circumstances of using the help are different too.  So we should incorporate that fact i
 nto how we present Emacs to new users.

Yes, ok. Maybe this one is harder to improve that some others.

>> Some of them, probably. At this point, I think, there are still a lot
>> of decisions that would bring us closer to newcomer-friendliness while
>> keeping no worse high-investment compatibility.
> 
> That could be true, though I'm a bit more skeptical than you are.  In any case, it does not make the principle inoperative; it is consistent with the principle.
> 
> I believe we'll make better decisions if we keep in mind that "friendly to newcomers" is not, in itself, the primary goal.

It's not like extreme user-friendliness was ever a guiding principle 
here. :-)

In this we're, again, similar to other professional software.

Re: GNU Emacs raison d'etre

[Jean-Christophe Helary]

> On May 17, 2020, at 10:28, Dmitry Gutov <dgutov@yandex.ru> wrote:
> 
>>> This part is expected of a professional tool, however, and the
>>> experience for newcomers could be improved without taking away much
>>> from the "oldies". See the 'transient' package, for example, recently proposed for inclusion on emacs-devel.
>> I don't have any experience using 'transient', so I'd need more explanation from you to understand what you meant by that part.  (I tried to understand 'transient' from reading [2] and [3], but unfortunately -- and somewhat surprisingly! -- the documentation at those pages does not give a single concrete example of transient's use.)
> 
> You press 'C-x', wait a while - and it pops up a window with the descriptions of all commands whose bindings start with 'C-x'. Same for all other "incomplete" key sequences. Looks pretty handy for beginners.

which-key seems to do something similar. I like it very much because it helps see the rationale behind keybinding. After a while you get to learn the bindings for the commands you use the most and you can easily explore new commands.


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

transient

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I like it very much because it helps see the rationale behind
  > keybinding. After a while you get to learn the bindings for the
  > commands you use the most and you can easily explore new commands.

For those that know Transient -- do you think it would provide that
benefit too?

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: transient

[Joost Kremers]

On Mon, May 18 2020, Richard Stallman wrote:
>   > I like it very much because it helps see the rationale 
>   > behind
>   > keybinding. After a while you get to learn the bindings for 
>   > the
>   > commands you use the most and you can easily explore new 
>   > commands.
>
> For those that know Transient -- do you think it would provide 
> that
> benefit too?

Well, which-key simply displays existing keybindings. A package 
author doesn't have to do anything, which-key just works.

Transient OTOH defines its own key sequences, so you can't use it 
to show users existing keybindings. If a package author wants 
their package to work with transient, they have to define 
transient menus for all functionality they want to expose.

Transient key bindings also work differently from standard Emacs 
key bindings. That's not a bad thing, because transient's main 
purpose is to provide an interface to external command line 
programs (such as git, as it was originally developed as part of 
magit) and it's well-suited for that.

It would be possible to use transient to provide an interface to 
Emacs packages, but the interface would be different from what is 
standard, so it's not a which-key replacement.


-- 
Joost Kremers
Life has its moments

Re: transient

[Howard Melman]

Joost Kremers <joostkremers@fastmail.fm> writes:

> On Mon, May 18 2020, Richard Stallman wrote:
>>   > I like it very much because it helps see the rationale behind
>>   > keybinding. After a while you get to learn the bindings for the
>>   > commands you use the most and you can easily explore
>>   > new commands.
>>
>> For those that know Transient -- do you think it would provide that
>> benefit too?
>
> Well, which-key simply displays existing keybindings. A package author
> doesn't have to do anything, which-key just works.
>
> Transient OTOH defines its own key sequences, so you can't use it to
> show users existing keybindings. If a package author wants their
> package to work with transient, they have to define transient menus
> for all functionality they want to expose.

Agreed. I've used both. which-key let's me explore existing
bindings with no effort.  Type C-x r and wait a second and
see all the rectangle and register commands. It was great
for learning the M-s and M-g keymaps when they were added.

which-key has been very helpful for learning bindings and I
think it would be great addition to core. Though for a busy
keymap it can take a second to read it to find what you
want. The C-h map is a perfect example. 

I've written a few transients that I've found useful,
including one for help and others for customize, ediff,
frame commands and one that toggles a ton of different minor
modes and visual features. Unlike which-key, transient
allows you to specify the order and groupings of bindings
when activated which can make scaning and learning them much
easier

hydra is a similar package to transient in that you can
define such temporary keymaps and customize a help display
that's shown while using it.  It has advantages and
disadvantages but so far I've prefered transient.

-- 

Howard

RE: transient

[Drew Adams]

> >>> I like it very much because it helps see the rationale behind
> >>> keybinding. After a while you get to learn the bindings for the
> >>> commands you use the most and you can easily explore
> >>> new commands.
> 
> ... which-key let's me explore existing bindings with
> no effort.  Type C-x r and wait a second and see all
> the rectangle and register commands. It was great for
> learning the M-s and M-g keymaps when they were added.
> which-key has been very helpful for learning bindings...

FWIW -

Icicles key completion is similar, but there are
notable differences:

1. You can use it on-demand (as well as just
   automatically) - complete only when you want
   to, and without a delay.

2. Because of that you can also use it at top
   level, not just after hitting a prefix key.
   Use it to see what key bindings are available
   in the current context (e.g. active modes).

3. Completion candidates have 2 parts: key and
   command name: `KEY  =  COMMAND'.  You can
   match either or both.  Prefix keys have `...'
   instead of `COMMAND: `PREFIX-KEY  =  ...'.

4. Choosing a candidate with a COMMAND invokes
   it.  Choosing a prefix-key candidate changes
   the set of candidates to its completions.
   E.g., choosing `C-h  =  ...' shows candidates
   such as `f  =  describe-function'.

5. You can filter the current matches, by typing
   input that matches key or command names, or
   both.  You can filter multiple times (multiple
   patterns).  Remove your current pattern from
   the minibuffer and type another one to see a
   different set of matches at the same level
   (same prefix key or top level).

6. When completing a prefix key, the first
   candidate shown is `..', which you can choose
   to go back up a level (completions above that
   prefix key).  Then you can go down another
   prefix key - explore the entire key-sequence
   forest.

7. That forest includes menus, as prefix-key
   candidates (`menu-bar  = ...').  So you can
   explore menus in the same way. [*]

8. You can sort candidates in these ways:

    * local bindings first, then non-local, each
      group in alphabetic order by key name
    * prefix keys first, then non-prefix, again,
      in key-name alphabetic order
    * alphabetic order by command name

   You can cycle among those sort orders anytime,
   using `C-,'.

9. Local bindings are highlighted differently
   from non-local - two faces.  Menus get two
   other faces (local, non-local).

10. You can show full help (`C-h f' help) for
    any candidate, anytime, without ending
    completion.  (Use `C-M-RET' on it.)

11. Being able to match minibuffer input against
   key and command names means that, unlike the
   approach of `which-key' and similar, when
   completing a prefix key you don't just hit
   keys that complete the key sequence, to
   invoke its command.  A workaround for that is
   to hit `M-q' and then hit a key, to insert
   its name in the minibuffer and then choose it.
   E.g., `M-q C-M-f' inserts the text `C-M-f' in
   the minibuffer.
_____

[*] Exploring menu-bar menus this way is one
    step (menu level) at a time, the same as
    exploring other key sequences.  A better way
    to explore menu-bar menus is to use library
    La Carte.  Then you can match menu items or
    submenus directly, at any level.  I.e., you
    can type a single pattern that dives down
    into the menu hierarchy - like file-name
    completion.  (But you can also navigate
    stepwise.)

Re: transient

[Arthur Miller]

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

>> >>> I like it very much because it helps see the rationale behind
>> >>> keybinding. After a while you get to learn the bindings for the
>> >>> commands you use the most and you can easily explore
>> >>> new commands.
>> 
>> ... which-key let's me explore existing bindings with
>> no effort.  Type C-x r and wait a second and see all
>> the rectangle and register commands. It was great for
>> learning the M-s and M-g keymaps when they were added.
>> which-key has been very helpful for learning bindings...
>
> FWIW -
>
> Icicles key completion is similar, but there are
> notable differences:
>
> 1. You can use it on-demand (as well as just
>    automatically) - complete only when you want
>    to, and without a delay.
>
> 2. Because of that you can also use it at top
>    level, not just after hitting a prefix key.
>    Use it to see what key bindings are available
>    in the current context (e.g. active modes).
>
> 3. Completion candidates have 2 parts: key and
>    command name: `KEY  =  COMMAND'.  You can
>    match either or both.  Prefix keys have `...'
>    instead of `COMMAND: `PREFIX-KEY  =  ...'.
>
> 4. Choosing a candidate with a COMMAND invokes
>    it.  Choosing a prefix-key candidate changes
>    the set of candidates to its completions.
>    E.g., choosing `C-h  =  ...' shows candidates
>    such as `f  =  describe-function'.
>
> 5. You can filter the current matches, by typing
>    input that matches key or command names, or
>    both.  You can filter multiple times (multiple
>    patterns).  Remove your current pattern from
>    the minibuffer and type another one to see a
>    different set of matches at the same level
>    (same prefix key or top level).
>
> 6. When completing a prefix key, the first
>    candidate shown is `..', which you can choose
>    to go back up a level (completions above that
>    prefix key).  Then you can go down another
>    prefix key - explore the entire key-sequence
>    forest.
>
> 7. That forest includes menus, as prefix-key
>    candidates (`menu-bar  = ...').  So you can
>    explore menus in the same way. [*]
>
> 8. You can sort candidates in these ways:
>
>     * local bindings first, then non-local, each
>       group in alphabetic order by key name
>     * prefix keys first, then non-prefix, again,
>       in key-name alphabetic order
>     * alphabetic order by command name
>
>    You can cycle among those sort orders anytime,
>    using `C-,'.
>
> 9. Local bindings are highlighted differently
>    from non-local - two faces.  Menus get two
>    other faces (local, non-local).
>
> 10. You can show full help (`C-h f' help) for
>     any candidate, anytime, without ending
>     completion.  (Use `C-M-RET' on it.)
>
> 11. Being able to match minibuffer input against
>    key and command names means that, unlike the
>    approach of `which-key' and similar, when
>    completing a prefix key you don't just hit
>    keys that complete the key sequence, to
>    invoke its command.  A workaround for that is
>    to hit `M-q' and then hit a key, to insert
>    its name in the minibuffer and then choose it.
>    E.g., `M-q C-M-f' inserts the text `C-M-f' in
>    the minibuffer.
> _____
>
> [*] Exploring menu-bar menus this way is one
>     step (menu level) at a time, the same as
>     exploring other key sequences.  A better way
>     to explore menu-bar menus is to use library
>     La Carte.  Then you can match menu items or
>     submenus directly, at any level.  I.e., you
>     can type a single pattern that dives down
>     into the menu hierarchy - like file-name
>     completion.  (But you can also navigate
>     stepwise.)
I haven't used Icicles yet, but seen this list, maybe I
should give it a try and see if I can use it instead of which-key. Can
Icicles be used without any additional learning and as easy as
which-key? Which-key is kind-of "just works", one installs it and it does
what it does without additional effort on user side. Is "automatic"
feature of Icicles in same manner?

Regression, but I have to say, I am impressed Drew. With how much you
have written. I went yesterday through your changelog for Dired+. Just
reading the changelog and thinking though the extra features you have
there took quite some time I have to say. What spontaneously to look
usefull is marking/toggeling/untoggling files per region only. That
seems like a usefull feature. Maybe you should try to get that part into
standard Dired?

Re: transient

[Michael Heerdegen]

Arthur Miller <arthur.miller@live.com> writes:

> usefull is marking/toggeling/untoggling files per region only. That
> seems like a usefull feature. Maybe you should try to get that part into
> standard Dired?

After Bug#39902 had been treated this has improved in vanilla Emacs.
Toggling was not changed, however.

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 :-)