all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Juri Linkov <juri@linkov.net>
Cc: Michael Heerdegen <michael_heerdegen@web.de>, 39902@debbugs.gnu.org
Subject: bug#39902: 28.0.50; Marking in dired with active region
Date: Sun, 15 Mar 2020 13:50:51 -0700 (PDT)	[thread overview]
Message-ID: <0066d43a-5f97-4c9d-a4b7-84c6b0ecf356@default> (raw)
In-Reply-To: <87bloybivx.fsf@mail.linkov.net>

> >> 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?





  parent reply	other threads:[~2020-03-15 20:50 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-04 14:29 bug#39902: 28.0.50; Marking in dired with active region Michael Heerdegen
2020-03-04 15:41 ` Drew Adams
2020-03-04 16:04   ` Stephen Berman
2020-03-04 21:07     ` Drew Adams
2020-03-04 23:46 ` Juri Linkov
2020-03-05  1:11   ` Drew Adams
2020-03-05 13:58   ` Michael Heerdegen
2020-03-05 23:42     ` Juri Linkov
2020-03-06  2:30       ` Drew Adams
2020-03-07  0:07       ` Michael Heerdegen
2020-03-08  0:38         ` Juri Linkov
2020-03-08 14:00           ` Michael Heerdegen
2020-03-08 17:04             ` Drew Adams
2020-03-08 23:56               ` Juri Linkov
2020-03-09  0:37                 ` Drew Adams
2020-03-09 14:53                   ` Michael Heerdegen
2020-03-09 22:28                   ` Juri Linkov
2020-03-10  0:41                     ` Drew Adams
2020-03-10 23:24                       ` Juri Linkov
2020-03-10 23:49                         ` Stephen Berman
2020-03-10 23:56                           ` Juri Linkov
2020-03-11  0:24                         ` Drew Adams
2020-03-10 23:55                     ` Michael Heerdegen
2020-03-11  0:08                       ` Juri Linkov
2020-03-11  0:18                         ` Juri Linkov
2020-03-11  0:29                           ` Drew Adams
2020-03-11  1:21                             ` Michael Heerdegen
2020-03-12  0:43                             ` Juri Linkov
2020-03-12  1:13                               ` Drew Adams
2020-03-13  0:39                                 ` Juri Linkov
2020-03-13  8:31                                   ` Pieter van Oostrum
2020-03-13 22:30                                     ` Michael Heerdegen
2020-03-14 18:03                                       ` Drew Adams
2020-03-14 17:56                                   ` Drew Adams
2020-03-14 23:45                                     ` Juri Linkov
2020-03-15  2:46                                       ` Michael Heerdegen
2020-03-15 20:52                                         ` Drew Adams
2020-03-15 20:50                                       ` Drew Adams [this message]
2020-03-15 23:41                                         ` Juri Linkov
2020-03-16  1:46                                           ` Drew Adams
2020-03-17  0:51                                             ` Michael Heerdegen
2020-03-18 23:51                                               ` Juri Linkov
2020-03-19 23:54                                                 ` Juri Linkov
2020-03-22  2:48                                                   ` Michael Heerdegen
2020-03-22 23:33                                                     ` Drew Adams
2020-03-23  0:43                                                       ` Juri Linkov
2020-03-23 15:09                                                         ` Drew Adams
2020-03-24 21:58                                                           ` Juri Linkov
2020-03-24 22:14                                                             ` Drew Adams
2020-03-23  0:35                                                     ` Juri Linkov
2020-03-23 15:20                                                       ` Drew Adams
2020-03-24 21:58                                                         ` Juri Linkov
2020-03-24 22:13                                                           ` Drew Adams
2020-03-16 15:21                             ` Drew Adams
2020-03-09 14:52                 ` Michael Heerdegen
2020-03-09 14:50               ` Michael Heerdegen
2020-03-09 15:22                 ` Drew Adams
2020-03-10 16:04                   ` Michael Heerdegen
2020-03-10 16:33                     ` Drew Adams
2020-03-09  9:04         ` martin rudalics
2020-03-09 15:02           ` Michael Heerdegen
2020-03-09 15:39             ` Drew Adams
2020-03-10 16:08               ` Michael Heerdegen
2020-03-09 17:12             ` martin rudalics
2020-03-10 15:52               ` Michael Heerdegen
  -- strict thread matches above, loose matches on Subject: below --
2020-05-08  8:26 Making Emacs popular again with a video Nathan Colinet
2020-05-10 20:57 ` Nathan Colinet
2020-05-12  3:12   ` Richard Stallman
2020-05-12 12:57     ` GNU Emacs raison d'etre excalamus--- via Emacs development discussions.
2020-05-13 16:18       ` Karl Fogel
2020-05-13 19:39         ` Andreas Röhler
2020-05-13 20:05           ` Karl Fogel
2020-05-13 20:52             ` Dmitry Gutov
2020-05-13 22:04               ` Karl Fogel
2020-05-13 22:55                 ` Dmitry Gutov
2020-05-14  4:56                   ` Karl Fogel
2020-05-17  1:28                     ` Dmitry Gutov
2020-05-17  1:59                       ` Jean-Christophe Helary
2020-05-18  3:43                         ` transient Richard Stallman
2020-05-18  6:58                           ` transient Joost Kremers
2020-05-18 18:41                             ` transient Howard Melman
2020-05-19  5:38                               ` transient Drew Adams
2020-05-19 14:00                                 ` transient Arthur Miller
2020-05-20  3:14                                   ` transient Michael Heerdegen
     [not found]                                     ` <87tuztngxr.fsf@mail.linkov.net>
2020-06-03  4:32                                       ` bug#39902: transient Michael Heerdegen
2020-06-03 22:49                                         ` bug#39902: 28.0.50; Marking in dired with active region Juri Linkov
2020-06-04 12:31                                           ` Michael Heerdegen
2020-06-04 22:18                                             ` Juri Linkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0066d43a-5f97-4c9d-a4b7-84c6b0ecf356@default \
    --to=drew.adams@oracle.com \
    --cc=39902@debbugs.gnu.org \
    --cc=juri@linkov.net \
    --cc=michael_heerdegen@web.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.