From: Drew Adams <drew.adams@oracle.com>
To: Michael Heerdegen <michael_heerdegen@web.de>,
Juri Linkov <juri@linkov.net>
Cc: 39902@debbugs.gnu.org
Subject: bug#39902: 28.0.50; Marking in dired with active region
Date: Sun, 22 Mar 2020 16:33:56 -0700 (PDT) [thread overview]
Message-ID: <4dd30e49-9a6a-4962-a6f2-1a68a41ce5e2@default> (raw)
In-Reply-To: <875zexf6l3.fsf@web.de>
> > 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.)
next prev parent reply other threads:[~2020-03-22 23:33 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
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 [this message]
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=4dd30e49-9a6a-4962-a6f2-1a68a41ce5e2@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.