From: Eli Zaretskii <eliz@gnu.org>
To: Kelly Dean <kelly@prtime.org>
Cc: emacs-devel@gnu.org
Subject: Re: kill-region in 24.4 shouldn't require BEG and END
Date: Sat, 15 Nov 2014 10:38:05 +0200 [thread overview]
Message-ID: <834mu0hn9u.fsf@gnu.org> (raw)
In-Reply-To: <emacs-mail-is-unusable-1@[87.69.4.28]>
> From: Kelly Dean <kelly@prtime.org>
> Date: Sat, 15 Nov 2014 06:55:38 +0000
>
> If the REGION argument is non-nil, then BEG and END shouldn't be required, since they're unused (except in one place where they aren't needed). So the test
> ⌜unless (and beg end)⌝
> in kill-region should be
> ⌜unless (or region (and beg end))⌝
> and the docstring should point out that if REGION is non-nil, then BEG and END are unused and might as well be nil.
First, please in the future report bugs with "M-x report-emacs-bug",
which will direct the report to the bug tracker, and will also collect
and report the details about your Emacs version and setup that might
be required for analyzing the report.
> The one place in kill-region where BEG and END are unnecessarily used if REGION is non-nil is the line
> ⌜(kill-append string (< end beg))⌝
> which should be something like
> ⌜(kill-append string (if region
> (< (point) (mark))
> (< end beg)))⌝
> and similarly for copy-region-as-kill.
>
> Without these changes, both kill-region and its docstring are confusing.
I don't see how the doc string is confusing. Your observations might
be correct, but they are based on reading the source code of the
implementation of the function. I submit that what you saw there are
internal implementation details subject to change without notice, and
that therefore the doc string deliberately refrains from saying what
you want it to say. IOW, if the implementation is changed some day
such that BEG and END _are_ used even when REGION is given, the
current doc string will still be correct.
Implementation details aside, I've re-read the doc string and found
nothing confusing in it. If I were to use this function, I understand
from the doc string that I need to provide BEG and END, and also
provide REGION of BEG and END delineated the current region. This
sounds pretty clear to me.
> Also, it would be clearer to have different names for the region between the cursor (er. point) and mark vs. a region between two specified positions; maybe call the latter a ‟range”, and have a cut-range function that takes BEG and END and have a cut-region function that takes no arguments, have both call kill-region, rename the latter to ‟cut-range-or-region”, and provide ‟kill-region” as an alias to the latter and mark it as deprecated, but I guess we'd have to wait 20 years before that alias could be safely removed. To go along with that, rename the kill-ring to ‟clip-ring” (not ‟cut-ring” since it holds not just cut things, but also copied things) to be memorable as a ring of clippings since everybody knows what a clipboard is, and rename all the associated functions.
IMO, this would be unnecessary complexity. We already have all those
use cases covered in that single API.
Thanks.
next parent reply other threads:[~2014-11-15 8:38 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <emacs-mail-is-unusable-1@[87.69.4.28]>
2014-11-15 8:38 ` Eli Zaretskii [this message]
[not found] <emacs-mail-is-unusable-1>
2014-11-15 15:22 ` kill-region in 24.4 shouldn't require BEG and END Stefan Monnier
2014-11-15 6:55 Kelly Dean
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=834mu0hn9u.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=kelly@prtime.org \
/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.