emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* [bug?][ob-core] using remove-if
@ 2013-07-30  0:09 Rasmus
  2013-07-30  0:28 ` Eric Schulte
  0 siblings, 1 reply; 5+ messages in thread
From: Rasmus @ 2013-07-30  0:09 UTC (permalink / raw)
  To: emacs-orgmode

Hi,

Regarding this commit:

          commit 3142297d69f6063221215757a3ba9c74adcf3e43
          Author: Eric Schulte <schulte.eric@gmail.com>
          Date:   Fri Jul 26 11:48:51 2013 -0600.

remove-if is introduced in ob-core.el:

	    (setf (cdr (assoc param params))
		  (remove-if (lambda (pair) (equal (car pair) name))
			     (cdr (assoc param params))))
	    (setf params (remove-if (lambda (pair) (and (equal (car pair) param)
						   (null (cdr pair))))

I personally don't care too much if Org depends on cl, but it breaks
async export since cl is usually not loaded.

Thus, I guess it should (i) either be changed to org-remove-if or
there should be an autoload to remove-if.  I don't feel very
comfortable about messing with ob-core ob-core and I don't know if
org-remove-if is a drop-in replacement of remove-if so I havne't made
a patch.

–Rasmus

-- 
Don't panic!!!

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [bug?][ob-core] using remove-if
  2013-07-30  0:09 [bug?][ob-core] using remove-if Rasmus
@ 2013-07-30  0:28 ` Eric Schulte
  2013-07-30  0:56   ` Rasmus
  2013-07-30  1:02   ` Aaron Ecay
  0 siblings, 2 replies; 5+ messages in thread
From: Eric Schulte @ 2013-07-30  0:28 UTC (permalink / raw)
  To: Rasmus; +Cc: emacs-orgmode

Rasmus <rasmus@gmx.us> writes:

> Hi,
>
> Regarding this commit:
>
>           commit 3142297d69f6063221215757a3ba9c74adcf3e43
>           Author: Eric Schulte <schulte.eric@gmail.com>
>           Date:   Fri Jul 26 11:48:51 2013 -0600.
>
> remove-if is introduced in ob-core.el:
>
> 	    (setf (cdr (assoc param params))
> 		  (remove-if (lambda (pair) (equal (car pair) name))
> 			     (cdr (assoc param params))))
> 	    (setf params (remove-if (lambda (pair) (and (equal (car pair) param)
> 						   (null (cdr pair))))
>
> I personally don't care too much if Org depends on cl, but it breaks
> async export since cl is usually not loaded.
>
> Thus, I guess it should (i) either be changed to org-remove-if or
> there should be an autoload to remove-if.  I don't feel very
> comfortable about messing with ob-core ob-core and I don't know if
> org-remove-if is a drop-in replacement of remove-if so I havne't made
> a patch.
>
> –Rasmus

Thanks for catching this, I've just pushed up a fix.

To complain to no-one in particular for a second...

  The exclusion of the cl functions from Emacs packages including both
  functions like `remove-if', and basic macros like `flet', has one of
  two possible consequences.  Either (1) authors work around the missing
  functionality by contorting the logic of their code so as to not need
  this functionality, or (2) the function is re-implemented with a
  package specific prefix and often slightly different semantics.  I
  know I've had to do both in my own Org-mode coding, and I believe most
  major packages do both of these [1].

Best,

Footnotes: 
[1]  ,----[M-x apropos remove-if RET]
     | Type RET on a type label to view its full documentation.
     | 
     | cl-remove-if
     |   Function: Remove all items satisfying PREDICATE in SEQ.
     |   Properties: autoload
     | cl-remove-if-not
     |   Function: Remove all items not satisfying PREDICATE in SEQ.
     |   Properties: autoload
     | ert--remove-if-not
     |   Function: A reimplementation of `remove-if-not'.
     | gnus-remove-if
     |   Function: Return a copy of SEQUENCE with all items satisfying
     |             PREDICATE removed.
     | gnus-remove-if-not
     |   Function: Return a copy of SEQUENCE with all items not satisfying
     |             PREDICATE removed.
     | org-remove-if
     |   Function: Remove everything from SEQ that fulfills PREDICATE.
     | org-remove-if-not
     |   Function: Remove everything from SEQ that does not fulfill
     |             PREDICATE.
     | recentf-remove-if-non-kept
     |   Function: Remove FILENAME from the recent list, if file is not kept.
     |   Properties: byte-optimizer
     | remove-if
     |   Function: Remove all items satisfying PREDICATE in SEQ.
     | remove-if-not
     |   Function: Remove all items not satisfying PREDICATE in SEQ.
     | widget-remove-if
     |   Function: (not documented)
     `----

-- 
Eric Schulte
http://cs.unm.edu/~eschulte
PGP fingerprint: FA8D C2C3 E8A0 A749 34CD  9DCF 3C1B 8581 614C A05D

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [bug?][ob-core] using remove-if
  2013-07-30  0:28 ` Eric Schulte
@ 2013-07-30  0:56   ` Rasmus
  2013-07-30  1:02   ` Aaron Ecay
  1 sibling, 0 replies; 5+ messages in thread
From: Rasmus @ 2013-07-30  0:56 UTC (permalink / raw)
  To: schulte.eric; +Cc: emacs-orgmode

Eric Schulte <schulte.eric@gmail.com> writes:

> Thanks for catching this, I've just pushed up a fix.

Thanks for the quick fix!  I'll go back to async export :)

> To complain to no-one in particular for a second...
>
>   The exclusion of the cl functions from Emacs packages including both
>   functions like `remove-if', and basic macros like `flet', has one of
>   two possible consequences.  Either (1) authors work around the missing
>   functionality by contorting the logic of their code so as to not need
>   this functionality, or (2) the function is re-implemented with a
>   package specific prefix and often slightly different semantics.  I
>   know I've had to do both in my own Org-mode coding, and I believe most
>   major packages do both of these [1].

It does seem a bit silly.  Wasn't work done on making cl-lib faster?
And would that get e.g. remove-if from cl-seq?

Cheers,
Rasmus

-- 
I hear there's rumors on the, uh, Internets. . .

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [bug?][ob-core] using remove-if
  2013-07-30  0:28 ` Eric Schulte
  2013-07-30  0:56   ` Rasmus
@ 2013-07-30  1:02   ` Aaron Ecay
  2013-07-31 15:37     ` using cl-lib Was: " Eric Schulte
  1 sibling, 1 reply; 5+ messages in thread
From: Aaron Ecay @ 2013-07-30  1:02 UTC (permalink / raw)
  To: Eric Schulte; +Cc: emacs-orgmode, Rasmus

There is light at the end of this tunnel: emacs 24.3 introduced the
cl-lib package, making cl functions canonically available with a ‘cl-’
prefix.  So once emacs 26 is out (and support for emacs 24.[12] is
dropped), org can use the cl- versions

cl-lib is also on GNU ELPA, so org could decide to start using it today
as long as that external dependency is properly handled.

-- 
Aaron Ecay

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: using cl-lib Was: [bug?][ob-core] using remove-if
  2013-07-30  1:02   ` Aaron Ecay
@ 2013-07-31 15:37     ` Eric Schulte
  0 siblings, 0 replies; 5+ messages in thread
From: Eric Schulte @ 2013-07-31 15:37 UTC (permalink / raw)
  To: Rasmus; +Cc: emacs-orgmode

Aaron Ecay <aaronecay@gmail.com> writes:

> There is light at the end of this tunnel: emacs 24.3 introduced the
> cl-lib package, making cl functions canonically available with a ‘cl-’
> prefix.  So once emacs 26 is out (and support for emacs 24.[12] is
> dropped), org can use the cl- versions
>

Great, so long term we will be able to drop all of the org-* versions of
cl-* functions.  I wasn't aware, thanks for sharing.

>
> cl-lib is also on GNU ELPA, so org could decide to start using it today
> as long as that external dependency is properly handled.

I personally find this very appealing.  I see the following benefits and
drawbacks.

Benefits:
1. we could use the full power of cl-* functions and macros

2. we could remove all of the org-* re-writes of cl-* functions reducing
   the amount of code we have to maintain, and

3. we will presumably be making this change anyway at some point down
   the line (whenever Emacs 26 is released)

Drawbacks:
1. it adds another step (installing cl-lib) to Org-mode installation on
   the great majority of systems

2. it adds a dependency for Org-mode instillation, also, if cl-lib
   doesn't support some of the targets currently supported by Org-mode
   (e.g., maybe Emacs23 or XEmacs)

3. if Org-mode is loaded in Emacs by default, then that would mean that
   cl-lib would also need to be loaded in Emacs by default, would that
   be okay with the Emacs maintainers?

I'm sure I'm missing other points.  I guess for now at least the
drawbacks probably out-weight the benefits, but I look forward to when
we do make this transition.

Cheers,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte
PGP: 0x614CA05D

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2013-07-31 15:40 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-07-30  0:09 [bug?][ob-core] using remove-if Rasmus
2013-07-30  0:28 ` Eric Schulte
2013-07-30  0:56   ` Rasmus
2013-07-30  1:02   ` Aaron Ecay
2013-07-31 15:37     ` using cl-lib Was: " Eric Schulte

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.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).