[bug?][ob-core] using remove-if

[bug?][ob-core] using remove-if

[Rasmus]

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!!!

Re: [bug?][ob-core] using remove-if

[Eric Schulte]

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

Re: [bug?][ob-core] using remove-if

[Rasmus]

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. . .

Re: [bug?][ob-core] using remove-if

[Aaron Ecay]

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

Re: using cl-lib Was: [bug?][ob-core] using remove-if

[Eric Schulte]

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