bug#18253: 24.4.50; doc string of `remq': correct it per the doc of `remove'

[tsugutomo.enami@jp.sony.com]

Hi,

I guess the specification of Emacs's remove/remq should be clarified
first.

If current implementaion is correctly reflecting the specification, then
I hope it is documented that those function might not return a copy on
some case (in other words, document which can be read as if they always
return a copy is confusing).

If current implementaion is not correct, then they should be fixed (and
documentation is updated to reflect the specification, if necessary).

> > The point of remq/remove is non-destructive operation.  Whether it
> > returns a copy or not is not important.  This matches CL's `remove'
> > definition.
> 
> No, it does not.  From CLTL, section 14.3, "Modifying Sequences":
> 
>   The result is a sequence of the same kind as the argument SEQUENCE
>   that has the same elements except that those in the subsequence
>   delimited by :start and :end and satisfying the test (see above)
>   have been removed.  This is a non-destructive operation; the result
>   is a copy of the input SEQUENCE, save that some elements are not
>   ^^^^^^^^^
>   copied.  Elements not removed occur in the same order in the result
>   ^^^^^^
>   that they did in the argument.
> 
> That text was in the original edition of CTLT (1984), and it has not
> changed one bit in subsequent revisions.

Probably, I failed to pick up my word.  What I meant was that those
function might not return a copy and they doesn't modify its argument is
more important aspect.  Of course it is importatnt to copy cells when
necessary.

The `remove' might not return a copy is described in the last sentense
of the section (quoted from
https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node144.html):

  The result of remove may share with the argument sequence; a list
  result may share a tail with an input list, and the result may be eq
  to the input sequence if no elements need to be removed.

enami.