* bug#21782: 25.0.50; New functions nfront/front
@ 2015-10-29 9:57 Tino Calancha
2015-10-29 15:25 ` Artur Malabarba
` (3 more replies)
0 siblings, 4 replies; 16+ messages in thread
From: Tino Calancha @ 2015-10-29 9:57 UTC (permalink / raw)
To: 21782
[-- Attachment #1: Type: text/plain, Size: 616 bytes --]
In GNU Emacs 25.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.23)
of 2015-10-29
Repository revision: 07830c3d5c801d7d55622215b46ba692c6afa1d2
I found very useful to define one function returning:
(nreverse (last (nreverse list) N))
(for a given list and integer N)
Maybe its already defined somewhere, but i cannot find it.
Examples of the new function:
(let ((ltest '( 1 2 3 4 5 6)))
(nfront ltest 3))
(1 2 3)
(let ((ltest '( 1 2 3 4 5 6)))
(nfront ltest 1))
(1)
(let ((ltest '( 1 2 3 4 5 6)))
(nfront ltest 20))
(1 2 3 4 5 6)
(let ((ltest '( 1 2 3 4 5 6)))
(nfront ltest))
(1 2 3 4 5 6)
[-- Attachment #2: Type: text/plain, Size: 840 bytes --]
diff --git a/lisp/subr.el b/lisp/subr.el
index ea926ae..976e4fd 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -405,6 +405,19 @@ nbutlast
(if (> n 0) (setcdr (nthcdr (- (1- m) n) list) nil))
list))))
+(defun front(list &optional n)
+ "Return a copy of LIST with just the first N elements.
+If N is omitted or nil the full list is copied."
+(let ((m (length list)))
+ (if (and n (<= n 0)) list
+ (nfront (copy-sequence list) n))))
+
+(defun nfront(list &optional n)
+ "Modified LIST to remove all elements but the first N.
+If N is omitted or nil the full list is copied."
+ (if (or (null n) (and n (<= n 0))) list
+ (nreverse (last (nreverse list) n))))
+
(defun zerop (number)
"Return t if NUMBER is zero."
;; Used to be in C, but it's pointless since (= 0 n) is faster anyway because
^ permalink raw reply related [flat|nested] 16+ messages in thread
* bug#21782: 25.0.50; New functions nfront/front
2015-10-29 9:57 bug#21782: 25.0.50; New functions nfront/front Tino Calancha
@ 2015-10-29 15:25 ` Artur Malabarba
2015-10-30 1:25 ` Tino Calancha
2015-10-30 2:10 ` Tino Calancha
2015-10-30 1:33 ` Richard Stallman
` (2 subsequent siblings)
3 siblings, 2 replies; 16+ messages in thread
From: Artur Malabarba @ 2015-10-29 15:25 UTC (permalink / raw)
To: Tino Calancha; +Cc: 21782
[-- Attachment #1: Type: text/plain, Size: 114 bytes --]
Hi Tino, thanks for the submission.
I think this is already available in core as seq-take, from the seq
package.
[-- Attachment #2: Type: text/html, Size: 149 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#21782: 25.0.50; New functions nfront/front
2015-10-29 15:25 ` Artur Malabarba
@ 2015-10-30 1:25 ` Tino Calancha
2015-10-30 2:38 ` Michael Heerdegen
2015-10-30 2:10 ` Tino Calancha
1 sibling, 1 reply; 16+ messages in thread
From: Tino Calancha @ 2015-10-30 1:25 UTC (permalink / raw)
To: 21782; +Cc: Artur Malabarba
[-- Attachment #1: Type: text/plain, Size: 1670 bytes --]
> I think this is already available in core as seq-take, from the seq package.
Thank you, you are right. Indeed, I found seq-take very nice:
its more general because apply to sequences.
There is one small difference: seq-take has no optional arguments.
In addition, seq.el need to be loaded by the user. Yeah, not a big
deal, but IMO such fundamental operation on a list as nfront
implement, deserve to be available at the starting of the session.
Putting a dedicated function in subr.el we save to load many stuff from
seq.el that maybe we dont need.
I would like nfront/front would behave as nbutlast/butlast concerning
the N argument:
*) N nil giving same output as N = 1.
*) N <= 0 return the full list.
(I choose the name of the function to somehow reflect such symmetry).
I have modified my patch to accomplish such behaviour.
With the new patch
(let ((ltest '(1 2 3 4 5 6)))
(nbutlast ltest nil))
(1 2 3 4 5)
(let ((ltest '(1 2 3 4 5 6)))
(nfront ltest nil))
(1)
(require 'seq)
(let ((ltest '(1 2 3 4 5 6)))
(seq-take ltest nil)); error: second argument is not optional
(let ((ltest '(1 2 3 4 5 6)))
(nbutlast ltest 0))
(1 2 3 4 5 6)
(let ((ltest '(1 2 3 4 5 6)))
(nfront ltest 0))
(1 2 3 4 5 6)
(let ((ltest '(1 2 3 4 5 6)))
(seq-take ltest 0))
nil
(let ((ltest '(1 2 3 4 5 6)))
(nbutlast ltest -1))
(1 2 3 4 5 6)
(let ((ltest '(1 2 3 4 5 6)))
(nfront ltest -1))
(1 2 3 4 5 6)
(let ((ltest '(1 2 3 4 5 6)))
(seq-take ltest -1))
nil
(let ((ltest '(1 2 3 4 5 6)))
(nbutlast ltest 20))
nil
(let ((ltest '(1 2 3 4 5 6)))
(nfront ltest 20))
(1 2 3 4 5 6)
(let ((ltest '(1 2 3 4 5 6)))
(seq-take ltest 20))
(1 2 3 4 5 6)
[-- Attachment #2: Type: text/plain, Size: 1534 bytes --]
diff --git a/lisp/subr.el b/lisp/subr.el
index ea926ae..ef705eb 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -391,13 +391,15 @@ last
(defun butlast (list &optional n)
"Return a copy of LIST with the last N elements removed.
If N is omitted or nil, the last element is removed from the
-copy."
+copy.
+When N is <= 0 LIST is returned."
(if (and n (<= n 0)) list
(nbutlast (copy-sequence list) n)))
(defun nbutlast (list &optional n)
"Modifies LIST to remove the last N elements.
-If N is omitted or nil, remove the last element."
+If N is omitted or nil, remove the last element.
+When N is <= 0 LIST is returned unmodified."
(let ((m (length list)))
(or n (setq n 1))
(and (< n m)
@@ -405,6 +407,21 @@ nbutlast
(if (> n 0) (setcdr (nthcdr (- (1- m) n) list) nil))
list))))
+(defun front(list &optional n)
+ "Return a copy of LIST with just the first N elements.
+If is omitted or nil copy just the first element
+When N is <= 0 the full list is copied."
+ (if (and n (<= n 0)) list
+ (nfront (copy-sequence list) n)))
+
+(defun nfront(list &optional n)
+ "Modified LIST to remove all elements but the first N.
+If N is omitted or nil remove all but the first element
+When N is <= 0 LIST is returned unmodified."
+ (or n (setq n 1))
+ (if (<= n 0) list
+ (nreverse (last (nreverse list) n))))
+
(defun zerop (number)
"Return t if NUMBER is zero."
;; Used to be in C, but it's pointless since (= 0 n) is faster anyway because
^ permalink raw reply related [flat|nested] 16+ messages in thread
* bug#21782: 25.0.50; New functions nfront/front
2015-10-29 9:57 bug#21782: 25.0.50; New functions nfront/front Tino Calancha
2015-10-29 15:25 ` Artur Malabarba
@ 2015-10-30 1:33 ` Richard Stallman
2015-10-30 1:41 ` Constantino Calancha
[not found] ` <mailman.1293.1446168906.7904.bug-gnu-emacs@gnu.org>
2017-05-18 4:08 ` Tino Calancha
3 siblings, 1 reply; 16+ messages in thread
From: Richard Stallman @ 2015-10-30 1:33 UTC (permalink / raw)
To: Tino Calancha; +Cc: 21782
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
ISTR there are traditional names for those functions.
I don't remember what they were, but if we are going to add them,
we should use their traditional names.
--
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#21782: 25.0.50; New functions nfront/front
2015-10-30 1:33 ` Richard Stallman
@ 2015-10-30 1:41 ` Constantino Calancha
0 siblings, 0 replies; 16+ messages in thread
From: Constantino Calancha @ 2015-10-30 1:41 UTC (permalink / raw)
To: 21782; +Cc: rms
> ISTR there are traditional names for those functions.
> I don't remember what they were, but if we are going to add them,
> we should use their traditional names.
Sure, i also prefer keep their original names.
Considering my previous example: i disagree with myself about
nfront being consistent with nbutlast.
nfront should return nil when N<= 0 as seq-take does.
Only when N is nil is when we provide the sensible default N=1 as nbutlast.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#21782: 25.0.50; New functions nfront/front
2015-10-29 15:25 ` Artur Malabarba
2015-10-30 1:25 ` Tino Calancha
@ 2015-10-30 2:10 ` Tino Calancha
1 sibling, 0 replies; 16+ messages in thread
From: Tino Calancha @ 2015-10-30 2:10 UTC (permalink / raw)
To: 21782; +Cc: C. Calancha
[-- Attachment #1: Type: text/plain, Size: 456 bytes --]
The new patch has more sense to me.
I correct my previous wish about the func. behaviour with respect N:
*) N nil give same output as N = 1.
*) N <= 0 return nil.
(let ((ltest '(1 2 3 4 5 6)))
(nfront ltest 0))
nil
(let ((ltest '(1 2 3 4 5 6)))
(nfront ltest -1))
nil
(let ((ltest '(1 2 3 4 5 6)))
(nfront ltest 3))
(1 2 3)
(let ((ltest '(1 2 3 4 5 6)))
(nfront ltest))
(1)
(let ((ltest '(1 2 3 4 5 6)))
(nfront ltest 100))
(1 2 3 4 5 6)
[-- Attachment #2: Type: text/plain, Size: 1490 bytes --]
diff --git a/lisp/subr.el b/lisp/subr.el
index ea926ae..cde4006 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -391,13 +391,15 @@ last
(defun butlast (list &optional n)
"Return a copy of LIST with the last N elements removed.
If N is omitted or nil, the last element is removed from the
-copy."
+copy.
+When N is <= 0 LIST is returned."
(if (and n (<= n 0)) list
(nbutlast (copy-sequence list) n)))
(defun nbutlast (list &optional n)
"Modifies LIST to remove the last N elements.
-If N is omitted or nil, remove the last element."
+If N is omitted or nil, remove the last element.
+When N is <= 0 LIST is returned unmodified."
(let ((m (length list)))
(or n (setq n 1))
(and (< n m)
@@ -405,6 +407,20 @@ nbutlast
(if (> n 0) (setcdr (nthcdr (- (1- m) n) list) nil))
list))))
+(defun front(list &optional n)
+ "Return a copy of LIST with just the first N elements.
+If N is omitted or nil copy just the first element
+When N is <= 0 return nil."
+(if (or (null n) (> n 0))
+ (nfront (copy-sequence list) n)))
+
+(defun nfront(list &optional n)
+ "Modified LIST to remove all elements but the first N.
+If N is omitted or nil remove all but the first element
+When N is <= 0 return nil."
+ (or n (setq n 1))
+ (if (> n 0) (nreverse (last (nreverse list) n))))
+
(defun zerop (number)
"Return t if NUMBER is zero."
;; Used to be in C, but it's pointless since (= 0 n) is faster anyway because
^ permalink raw reply related [flat|nested] 16+ messages in thread
* bug#21782: 25.0.50; New functions nfront/front
2015-10-30 1:25 ` Tino Calancha
@ 2015-10-30 2:38 ` Michael Heerdegen
2015-10-30 2:53 ` Constantino Calancha
0 siblings, 1 reply; 16+ messages in thread
From: Michael Heerdegen @ 2015-10-30 2:38 UTC (permalink / raw)
To: Tino Calancha; +Cc: Artur Malabarba, 21782
Tino Calancha <f92capac@gmail.com> writes:
> + (nreverse (last (nreverse list) n))))
Isn't this horribly inefficient? It would be better to use `nthcdr' or
a simple loop.
Dunno if this should be in the core, I think having this functionality
in "seq.el" is a good place.
Michael.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#21782: 25.0.50; New functions nfront/front
2015-10-30 2:38 ` Michael Heerdegen
@ 2015-10-30 2:53 ` Constantino Calancha
2015-10-30 9:45 ` Artur Malabarba
` (2 more replies)
0 siblings, 3 replies; 16+ messages in thread
From: Constantino Calancha @ 2015-10-30 2:53 UTC (permalink / raw)
To: 21782@debbugs.gnu.org; +Cc: f92capac
Im sorry Michael, but i dont see your point: do you mean the fact to call
nreverse twice?
nreverse is in fact very efficient;
and last already use nthcdr in its implementation.
Please elaborate more.
As i mentioned, they are not exactly the same function as seq-take.
Why i need to pollute my global space with all seq.el just to use this
fundamental operation on a list?
I we want this in the core, we may also consider to implement such
functionality in
src/fns.c
Tino
On Fri, 30 Oct 2015 11:38:33 +0900, Michael Heerdegen
<michael_heerdegen@web.de> wrote:
> Tino Calancha <f92capac@gmail.com> writes:
>
>> + (nreverse (last (nreverse list) n))))
>
> Isn't this horribly inefficient? It would be better to use `nthcdr' or
> a simple loop.
>
> Dunno if this should be in the core, I think having this functionality
> in "seq.el" is a good place.
>
>
> Michael.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#21782: 25.0.50; New functions nfront/front
2015-10-30 2:53 ` Constantino Calancha
@ 2015-10-30 9:45 ` Artur Malabarba
2015-10-30 10:10 ` Tino Calancha
2015-10-30 10:03 ` Nicolas Petton
2015-10-30 14:09 ` Michael Heerdegen
2 siblings, 1 reply; 16+ messages in thread
From: Artur Malabarba @ 2015-10-30 9:45 UTC (permalink / raw)
To: Tino Calancha; +Cc: 21782
[-- Attachment #1: Type: text/plain, Size: 1163 bytes --]
On 30 Oct 2015 2:53 am, "Constantino Calancha" <f92capac@gmail.com> wrote:
> Why i need to pollute my global space with all seq.el just to use this
> fundamental operation on a list?
I think, overall, sticking to seq-take has a smaller cost/benefit ratio
than adding nfront. I state my logic below.
These points are all a little subjective. So if you disagree and think that
the slider falls closer to the other side, we can wait to hear more
opinions (though at least Michael seems to agree).
1. While nfront is not identical to seq-take, it's similar enough that this
would just be replicating functionality, which is ultimately a maintenance
burden.
2. Seq is not a huge lib, so you're not polluting that much. Furthermore,
all its functions are prefixed by "seq-", so you're polluting even less.
Lastly, seq was added to core specifically with the purpose of being the
goto sequences lib (and it's been doing that fine), so it wouldn't make
sense to circumvent it now.
3. I'm of the opinion that we should be adding namespace prefixes as much
as possible. Unprefixed names pollute much more and are harder to find.
In any case, thanks for the suggestion.
[-- Attachment #2: Type: text/html, Size: 1369 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#21782: 25.0.50; New functions nfront/front
2015-10-30 2:53 ` Constantino Calancha
2015-10-30 9:45 ` Artur Malabarba
@ 2015-10-30 10:03 ` Nicolas Petton
2015-10-30 10:11 ` Tino Calancha
2015-10-30 14:09 ` Michael Heerdegen
2 siblings, 1 reply; 16+ messages in thread
From: Nicolas Petton @ 2015-10-30 10:03 UTC (permalink / raw)
To: Constantino Calancha, 21782@debbugs.gnu.org; +Cc: f92capac
[-- Attachment #1: Type: text/plain, Size: 822 bytes --]
Constantino Calancha <f92capac@gmail.com> writes:
Hi,
> As i mentioned, they are not exactly the same function as seq-take.
I think adding these functions would mostly be code duplication. Please
bear in mind that seq.el was written to provide a good built-in sequence
library in Emacs. If seq-take doesn't provide exactly what you need,
you could propose a patch to improve it instead.
> Why i need to pollute my global space with all seq.el just to use this
> fundamental operation on a list?
All functions in seq.el are prefixed, so there's no global namespace
polluting, and I consider many functions provided by seq.el to be
fundamental operations on sequences.
Also, seq.el is not pre-loaded today because it's a new library, so it
is not widely used in Emacs yet, but that could change in the future.
Nico
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#21782: 25.0.50; New functions nfront/front
2015-10-30 9:45 ` Artur Malabarba
@ 2015-10-30 10:10 ` Tino Calancha
0 siblings, 0 replies; 16+ messages in thread
From: Tino Calancha @ 2015-10-30 10:10 UTC (permalink / raw)
To: 21782; +Cc: f92capac
Thank you.
I agree with your 3 points.
1) Clearly replicate functionality
2) Yes, the prefix prevent to pollute.
3) Agree.
My main concern is why seq-take is not auloaded at the start of the
session. Its natural to have loaded such function always.
Anyway thank you very much.
On Fri, 30 Oct 2015, Artur Malabarba wrote:
>
> On 30 Oct 2015 2:53 am, "Constantino Calancha" <f92capac@gmail.com> wrote:
> > Why i need to pollute my global space with all seq.el just to use this
> > fundamental operation on a list?
>
> I think, overall, sticking to seq-take has a smaller cost/benefit ratio than adding nfront. I state my logic below.
>
> These points are all a little subjective. So if you disagree and think that
the slider falls closer to the other side, we can wait to hear more opinions (though at least Michael seems to
> agree).
>
> 1. While nfront is not identical to seq-take, it's similar enough that this would just be replicating functionality, which is ultimately a maintenance burden.
> 2. Seq is not a huge lib, so you're not polluting that much. Furthermore, all its functions are prefixed by "seq-", so you're polluting even less. Lastly, seq was added to core
> specifically with the purpose of being the goto sequences lib (and it's been doing that fine), so it wouldn't make sense to circumvent it now.
> 3. I'm of the opinion that we should be adding namespace prefixes as much as possible. Unprefixed names pollute much more and are harder to find.
>
> In any case, thanks for the suggestion.
>
>
>
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#21782: 25.0.50; New functions nfront/front
2015-10-30 10:03 ` Nicolas Petton
@ 2015-10-30 10:11 ` Tino Calancha
0 siblings, 0 replies; 16+ messages in thread
From: Tino Calancha @ 2015-10-30 10:11 UTC (permalink / raw)
To: Nicolas Petton; +Cc: Constantino Calancha, 21782@debbugs.gnu.org
> Also, seq.el is not pre-loaded today because it's a new library, so it
> is not widely used in Emacs yet, but that could change in the future.
I see. I think is worth to give it a try to this lib.
Thank you.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#21782: 25.0.50; New functions nfront/front
2015-10-30 2:53 ` Constantino Calancha
2015-10-30 9:45 ` Artur Malabarba
2015-10-30 10:03 ` Nicolas Petton
@ 2015-10-30 14:09 ` Michael Heerdegen
2015-10-30 18:06 ` Tino Calancha
2 siblings, 1 reply; 16+ messages in thread
From: Michael Heerdegen @ 2015-10-30 14:09 UTC (permalink / raw)
To: Constantino Calancha; +Cc: 21782@debbugs.gnu.org
"Constantino Calancha" <f92capac@gmail.com> writes:
> Im sorry Michael, but i dont see your point: do you mean the fact to
> call nreverse twice? nreverse is in fact very efficient; and last
> already use nthcdr in its implementation.
`nreverse` efficiently does what is supposed to do, yes. But it is
O(l), where l is the length of the list arg.
In addition, the newly created `nreverse'd list must be garbage
collected.
The `copy-sequence' call in `front' is bad for the same reason.
OTOH nfront can be implemented in O(n), where n is the number argument
to nfront.
Michael.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#21782: 25.0.50; New functions nfront/front
2015-10-30 14:09 ` Michael Heerdegen
@ 2015-10-30 18:06 ` Tino Calancha
0 siblings, 0 replies; 16+ messages in thread
From: Tino Calancha @ 2015-10-30 18:06 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: Constantino Calancha, 21782@debbugs.gnu.org
>
> `nreverse` efficiently does what is supposed to do, yes. But it is
> O(l), where l is the length of the list arg.
>
> In addition, the newly created `nreverse'd list must be garbage
> collected.
>
> The `copy-sequence' call in `front' is bad for the same reason.
>
> OTOH nfront can be implemented in O(n), where n is the number argument
> to nfront.
Thank you Michael for the detail answer. I appreciate it a lot.
Now i see clearly what you mean.
For all the people:
Efficiency implementations are very important, almost as important as
have things available.
One emacs user starting one session has no available seq-take. That is
the first thing to care, efficiency comes later.
Many users learn the lenguage autocompleting in the minibuffer. If it is
not loaded the least people will realize such functions you are
developping do exists. We develop tools to be used, not ust to be nice.
IMOP, fundamental operations should be loaded by default. If this is not
the case, that means the function should not be located in its corrent
location: fair and simple.
Please, consider make this fundamental operation being loaded at the
beginning. Thanks.
I finish here because i start to repeat myself. Thank you for the very
nice chat; it has being very instructive for me and i enjoied very much.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#21782: 25.0.50; New functions nfront/front
[not found] ` <mailman.1293.1446168906.7904.bug-gnu-emacs@gnu.org>
@ 2015-10-31 22:44 ` Alan Mackenzie
0 siblings, 0 replies; 16+ messages in thread
From: Alan Mackenzie @ 2015-10-31 22:44 UTC (permalink / raw)
To: gnu-emacs-bug
Hello, Richard.
Richard Stallman <rms@gnu.org> wrote:
> [[[ To any NSA and FBI agents reading my email: please consider ]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> ISTR there are traditional names for those functions.
> I don't remember what they were, but if we are going to add them,
> we should use their traditional names.
How about `firstn':
"firstn n list
Returns a list of length _n_, whose elements are the first _n_ elements
of _list_. if _list_ is fewer than _n_ elements long, the remaining
elements of the list are ni."
[ Lisp Machine Manual, Sixth Edition, System Version 99, June 1984, by
Richard Stallman, Daniel Weinreb and David Moon ]
> --
> Dr Richard Stallman
> President, Free Software Foundation (gnu.org, fsf.org)
> Internet Hall-of-Famer (internethalloffame.org)
> Skype: No way! See stallman.org/skype.html.
--
Alan Mackenzie (Nuremberg, Germany).
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#21782: 25.0.50; New functions nfront/front
2015-10-29 9:57 bug#21782: 25.0.50; New functions nfront/front Tino Calancha
` (2 preceding siblings ...)
[not found] ` <mailman.1293.1446168906.7904.bug-gnu-emacs@gnu.org>
@ 2017-05-18 4:08 ` Tino Calancha
3 siblings, 0 replies; 16+ messages in thread
From: Tino Calancha @ 2017-05-18 4:08 UTC (permalink / raw)
To: 21782-done
Tino Calancha <f92capac@gmail.com> writes:
> I found very useful to define one function returning:
> (nreverse (last (nreverse list) N))
> (for a given list and integer N)
>
> Maybe its already defined somewhere, but i cannot find it.
seq-take does the same thing, so i am closing this report.
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2017-05-18 4:08 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-10-29 9:57 bug#21782: 25.0.50; New functions nfront/front Tino Calancha
2015-10-29 15:25 ` Artur Malabarba
2015-10-30 1:25 ` Tino Calancha
2015-10-30 2:38 ` Michael Heerdegen
2015-10-30 2:53 ` Constantino Calancha
2015-10-30 9:45 ` Artur Malabarba
2015-10-30 10:10 ` Tino Calancha
2015-10-30 10:03 ` Nicolas Petton
2015-10-30 10:11 ` Tino Calancha
2015-10-30 14:09 ` Michael Heerdegen
2015-10-30 18:06 ` Tino Calancha
2015-10-30 2:10 ` Tino Calancha
2015-10-30 1:33 ` Richard Stallman
2015-10-30 1:41 ` Constantino Calancha
[not found] ` <mailman.1293.1446168906.7904.bug-gnu-emacs@gnu.org>
2015-10-31 22:44 ` Alan Mackenzie
2017-05-18 4:08 ` Tino Calancha
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).