Re: kill-region in 24.4 shouldn't require BEG and END

[Eli Zaretskii]

> From: Kelly Dean <address@hidden>
> 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.