[implementations-list] GNU Emacs policy that says packages must not use cl.el at runtime (was: viper-in-more-modes still needs ...)
On Sun, Jan 3, 2010 at 9:58 PM, Stephen Bach <[email protected]> wrote:
On Sat, Jan 02, 2010 at 10:40:10PM -0500, Jason Spiro wrote:
3. GNU Emacs enforces the backward policy that packages must not use cl.el Common Lisp extensions at runtime. This kind of restriction is another enemy to development momentum; if it's expedient to Vegard or another developer to leverage a standard library, they should be empowered to do so.
But John J. Foerch said in his email of Wed, Oct 3, 2007 at 11:00 PM at http://my-trac.assembla.com/vimpulse/ticket/2 that there are cl.el macros that override core Emacs functions. Do you still stand by your assertion?
Yes. cl.el's version of push subsumes GNU Emacs' standard push - it's not dangerous. Almost anyone who uses Emacs extensively will load cl.el as part of their configuration. XEmacs loads it by default.
What reason does the GNU Emacs team give for this policy? If it turns out to be a flimsy reason, then perhaps you or Vegard could get the policy changed if you wanted to. :)
From: [email protected] Date: Tue, 9 Feb 2010 01:42:13 -0500
What reason does the GNU Emacs team give for this policy? If it turns out to be a flimsy reason, then perhaps you or Vegard could get the policy changed if you wanted to. :)
I can think of one serious reason: macros don't debug well. For example, evaluate the following old code in the *scratch* buffer: (require 'cl) (defun vimpulse-pm-is-real-match (pos1 pos2) (destructuring-bind ((class1 . match1) (class2 . match2)) (list (syntax-after pos1) (syntax-after pos2)) (or (eq match1 (char-after pos2)) (eq match2 (char-after pos1)) (eq match1 match2)))) Then move point inside the defun and hit C-u C-M-x, and you get the following error message: edebug-syntax-error: Invalid read syntax: "Failed matching", ([&optional "&environment" arg] ... There are rumors of moving some of cl.el's core into GNU Emacs, presumably rewritten in a way which doesn't have this problem. It would certainly be cool if standard Elisp became more CL-like. Heck, some non-lispy languages are more CL-like than Elisp these days. :/ The removal of cl.el forms didn't really make much of a difference to code size or readability, however. The function above was rewritten in changeset [38] to use a `let' form instead of `destructuring-bind', dismantling the arguments explicitly; it is one line longer than the original. The other frequent cl.el form was `case', whose `cond' replacement just does the comparison out in the open: (eq variable 'this), (eq variable 'that), and so on. Although verbose, it's usually the same number of lines, which is what I care about :) We are approaching release. Has anyone tried the latest revisions? Vegard _________________________________________________________________ Få nye Windows Live™ Messenger. http://download.live.com/messenger
On Tue, Feb 09, 2010 at 02:57:08PM +0000, Vegard Øye wrote:
We are approaching release. Has anyone tried the latest revisions?
Yeah, I just updated to the latest (special thanks for Emacs-compatible rectangles). Two minor nits I noticed (line numbers corresponding to vimpulse-big.el): l. 1686: ;; Eldoc compatibility (eval-after-load 'eldoc '(let (cmd) (dolist (cmd (append vimpulse-viper-movement-cmds vimpulse-core-movement-cmds)) (eldoc-add-command cmd)))) If you look at `eldoc-add-command', you see it takes (&rest cmds), so it does exactly what you need (i.e. simply something like (eldoc-add-command (append vimpulse-...)) would make more sense (I also don't see the point of wrapping `let' around `dolist', am I missing something?)). l. 1717: ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;;;;;;;;;;; VISUAL MODE BINDINGS ;;;;;;;;;;;;;;;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; (define-key viper-vi-basic-map "v" 'vimpulse-visual-mode) (define-key viper-vi-basic-map "V" 'vimpulse-visual-mode-linewise) This should be deleted, as you redefine "v" and "V" later anyway, and the following has nothing to do with Visual mode. Štěpán
On Fri, Feb 12, 2010 at 11:57:07AM +0100, Štěpán Němec wrote:
On Tue, Feb 09, 2010 at 02:57:08PM +0000, Vegard Øye wrote:
We are approaching release. Has anyone tried the latest revisions?
Yeah, I just updated to the latest (special thanks for Emacs-compatible rectangles).
Two minor nits I noticed (line numbers corresponding to vimpulse-big.el):
l. 1686:
;; Eldoc compatibility (eval-after-load 'eldoc '(let (cmd) (dolist (cmd (append vimpulse-viper-movement-cmds vimpulse-core-movement-cmds)) (eldoc-add-command cmd))))
If you look at `eldoc-add-command', you see it takes (&rest cmds), so it does exactly what you need (i.e. simply something like
(eldoc-add-command (append vimpulse-...)) Eh... that should be (apply eldoc-add-command ...)
Well, you get the point... :-P
On Fri, Feb 12, 2010 at 12:04:07PM +0100, Štěpán Němec wrote:
On Fri, Feb 12, 2010 at 11:57:07AM +0100, Štěpán Němec wrote: Eh... that should be (apply eldoc-add-command ...)
Bah... I'd better go back to lurking. Take it as pseudo-code...
On Fri, Feb 12, 2010 at 6:08 AM, Štěpán Němec <[email protected]> wrote:
On Fri, Feb 12, 2010 at 12:04:07PM +0100, Štěpán Němec wrote:
On Fri, Feb 12, 2010 at 11:57:07AM +0100, Štěpán Němec wrote: Eh... that should be (apply eldoc-add-command ...)
Bah...
I'd better go back to lurking. Take it as pseudo-code...
Don't worry about the small mistake in the suggestion you submitted. The important thing is that you made the suggestion: that you pointed out that eldoc-add-command exists at all. :) -- Jason Spiro: software/web developer, packager, trainer, IT consultant. I support Linux, UNIX, Windows, and more. Contact me to discuss your needs. +1 (416) 992-3445 / www.jspiro.com
On Fri, Feb 12, 2010 at 01:03:39PM -0500, Jason Spiro wrote:
On Fri, Feb 12, 2010 at 6:08 AM, Štěpán Němec <[email protected]> wrote:
On Fri, Feb 12, 2010 at 12:04:07PM +0100, Štěpán Němec wrote:
On Fri, Feb 12, 2010 at 11:57:07AM +0100, Štěpán Němec wrote: Eh... that should be (apply eldoc-add-command ...)
Bah...
I'd better go back to lurking. Take it as pseudo-code...
Don't worry about the small mistake in the suggestion you submitted. The important thing is that you made the suggestion: that you pointed out that eldoc-add-command exists at all. :)
Heh, this thread got somewhat grotesque :-D `eldoc-add-command' was there already, I just made three unsuccessful attempts at pointing out how it could (should) be used better -- the explicit `dolist' invocation is unnecessary, as that's exactly what `eldoc-add-command' does by itself. Štěpán P.S.: It should be (apply 'eldoc-add-command ...), thus "Bah..." and the third failed shot.
Date: Fri, 12 Feb 2010 11:57:07 +0100 From: [email protected]
We are approaching release. Has anyone tried the latest revisions?
Yeah, I just updated to the latest (special thanks for Emacs-compatible rectangles).
You're welcome. :)
If you look at `eldoc-add-command', you see it takes (&rest cmds), so it does exactly what you need (i.e. simply something like
(eldoc-add-command (append vimpulse-...))
Ah, I didn't think of using `apply'. Here's the new code from changeset [81]: (eval-after-load 'eldoc '(apply 'eldoc-add-command (append vimpulse-viper-movement-cmds vimpulse-core-movement-cmds))) Much cleaner and readable. :) (To those who don't use ElDoc, it works with Elisp and shows function arguments in the minibuffer (though it can also be extended to other languages). The code above tells ElDoc, if loaded, to refresh the minibuffer whenever a Viper command moves point.)
(I also don't see the point of wrapping `let' around `dolist', am I missing something?)
`dolist' needs a temporary variable to bind each list element to.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;;;;;;;;;;; VISUAL MODE BINDINGS ;;;;;;;;;;;;;;;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; (define-key viper-vi-basic-map "v" 'vimpulse-visual-mode) (define-key viper-vi-basic-map "V" 'vimpulse-visual-mode-linewise)
This should be deleted, as you redefine "v" and "V" later anyway, and the following has nothing to do with Visual mode.
Yes. Visual bindings don't belong in vimpulse-misc-keybindings.el at all. The file has turned into a "miscellaneous" section of sorts. I think it would be cleaner to have a vimpulse-keys.el file which merges vimpulse-modal.el with the keybinding stuff in vimpulse-misc-keybindings.el, while the rest could go in vimpulse-commands.el or some such. I also think the current file names are too long. The libraries bundled with either Emacs seldom use more than one hyphen in their file names. Viper, for instance, consists of viper.el, viper-cmd.el, viper-ex.el, viper-init.el, viper-keym.el, viper-macs.el, viper-mous.el and viper-util.el. Here's a renaming proposal: vimpulse-dependencies.el => vimpulse-depend.el vimpulse-misc-keybindings.el => vimpulse-keys.el vimpulse-paren-matching.el => vimpulse-paren.el vimpulse-text-object-system.el => vimpulse-text.el vimpulse-viper-function-redefinitions.el => vimpulse-viper.el vimpulse-visual-mode.el => vimpulse-visual.el What do you think? Vegard _________________________________________________________________ Windows Live™ Mail. Flere kontoer på ett sted. http://download.live.com/wlmail
On Fri, Feb 12, 2010 at 07:28:02PM +0000, Vegard Øye wrote:
(I also don't see the point of wrapping `let' around `dolist', am I missing something?)
`dolist' needs a temporary variable to bind each list element to.
Well, sure, but `dolist' does the binding for you: (let ((cool 8)) (dolist (cool '(1 2 3 4)) (prin1 cool)) (prin1 cool)) 123488 Even Emacs Lisp does not suck *that* bad.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;;;;;;;;;;; VISUAL MODE BINDINGS ;;;;;;;;;;;;;;;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; (define-key viper-vi-basic-map "v" 'vimpulse-visual-mode) (define-key viper-vi-basic-map "V" 'vimpulse-visual-mode-linewise)
This should be deleted, as you redefine "v" and "V" later anyway, and the following has nothing to do with Visual mode.
My point is that the above lines do not belong *anywhere*, they're just redundant; starting at l. 2994 of vimpulse-big.el, you have: ;;;;;;;;;;;;;;;;;;;; ;;; Key bindings ;;; ;;;;;;;;;;;;;;;;;;;; (define-key viper-vi-basic-map "v" 'vimpulse-visual-toggle-normal) (define-key viper-vi-basic-map "V" 'vimpulse-visual-toggle-line) ... so you're defining the keys again.
Yes. Visual bindings don't belong in vimpulse-misc-keybindings.el at all. The file has turned into a "miscellaneous" section of sorts. I think it would be cleaner to have a vimpulse-keys.el file which merges vimpulse-modal.el with the keybinding stuff in vimpulse-misc-keybindings.el, while the rest could go in vimpulse-commands.el or some such.
Maybe, yeah; that would likely prevent situations like the above, at least.
I also think the current file names are too long. The libraries bundled with either Emacs seldom use more than one hyphen in their file names. Viper, for instance, consists of viper.el, viper-cmd.el, viper-ex.el, viper-init.el, viper-keym.el, viper-macs.el, viper-mous.el and viper-util.el.
Here's a renaming proposal:
vimpulse-dependencies.el => vimpulse-depend.el vimpulse-misc-keybindings.el => vimpulse-keys.el vimpulse-paren-matching.el => vimpulse-paren.el vimpulse-text-object-system.el => vimpulse-text.el vimpulse-viper-function-redefinitions.el => vimpulse-viper.el vimpulse-visual-mode.el => vimpulse-visual.el
What do you think?
I don't think that is really necessary -- for one thing, the current file names describe their contents better than the shorter alternatives you propose, and besides that, it's all just kinda behind-the-scenes -- most users don't even know about the single files, they're using the concatenated vimpulse.el. Which makes more sense to me anyway -- I don't think even the splitting itself is necessary. 4000 lines might be a lot, but it's not too much IMO, also not in comparison with some files in Emacs core (like simple.el with 6655). I personally would just stick to a single file (and do so, as you see from the line counts I give, sorry for that ;)) -- it's simply more convenient. It's a PITA for me to look at ten files instead of one, esp. when some of them really only contain a few lines. Regards, Štěpán
Date: Fri, 12 Feb 2010 21:08:23 +0100 From: [email protected]
`dolist' needs a temporary variable to bind each list element to.
Well, sure, but `dolist' does the binding for you: [...]
Huh, I didn't know that. I've taken appropriate action and removed all such redundant `let' bindings in changeset [82].
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;;;;;;;;;;; VISUAL MODE BINDINGS ;;;;;;;;;;;;;;;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; (define-key viper-vi-basic-map "v" 'vimpulse-visual-mode) (define-key viper-vi-basic-map "V" 'vimpulse-visual-mode-linewise)
My point is that the above lines do not belong *anywhere*, they're just redundant; [...]
Yes, I removed them in changeset [81]. Sorry for being unclear. http://code.assembla.com/vimpulse/subversion/changesets/81
Here's a renaming proposal:
vimpulse-dependencies.el => vimpulse-depend.el vimpulse-misc-keybindings.el => vimpulse-keys.el vimpulse-paren-matching.el => vimpulse-paren.el vimpulse-text-object-system.el => vimpulse-text.el vimpulse-viper-function-redefinitions.el => vimpulse-viper.el vimpulse-visual-mode.el => vimpulse-visual.el
I don't think that is really necessary -- for one thing, the current file names describe their contents better than the shorter alternatives you propose, and besides that, it's all just kinda behind-the-scenes -- most users don't even know about the single files, they're using the concatenated vimpulse.el.
Yes, it doesn't make much difference as of currently, since Vimpulse is released as a single file on EmacsWiki. In the future, however, it may bundle some sort of Info manual. Maybe we will have two downloads then: a single big file on EmacsWiki, and a compressed archive containing the .el files (separately?), the manual, and some installation scripts. In that case, conventionally short names would be ... well, it would be conventional. :)
It's a PITA for me to look at ten files instead of one, esp. when some of them really only contain a few lines.
Yeah. It is sometimes useful for debugging, though. Vegard _________________________________________________________________ Windows Live™ Mail. Flere kontoer på ett sted. http://download.live.com/wlmail
On Tue, Feb 09, 2010 at 01:42:13AM -0500, Jason Spiro wrote:
On Sun, Jan 3, 2010 at 9:58 PM, Stephen Bach <[email protected]> wrote:
On Sat, Jan 02, 2010 at 10:40:10PM -0500, Jason Spiro wrote:
3. GNU Emacs enforces the backward policy that packages must not use cl.el Common Lisp extensions at runtime. This kind of restriction is another enemy to development momentum; if it's expedient to Vegard or another developer to leverage a standard library, they should be empowered to do so.
But John J. Foerch said in his email of Wed, Oct 3, 2007 at 11:00 PM at http://my-trac.assembla.com/vimpulse/ticket/2 that there are cl.el macros that override core Emacs functions. Do you still stand by your assertion?
Yes. cl.el's version of push subsumes GNU Emacs' standard push - it's not dangerous. Almost anyone who uses Emacs extensively will load cl.el as part of their configuration. XEmacs loads it by default.
What reason does the GNU Emacs team give for this policy? If it turns out to be a flimsy reason, then perhaps you or Vegard could get the policy changed if you wanted to. :)
Two cents: I think the cl.el policy is smart, actually. Common Lisp is a rather crufty language --- a design of "politics" rather than a design of "art" as the old cliché about CL vs. Scheme goes. For example, it would be hard to make the case that generalized variables belong in Elisp, as they are unnecessary, redundant, and complex. Don't get me wrong, I love Common Lisp for what it is, on its own terms, but I would not hold it up as some kind of ideal for the future improvement of Emacs Lisp. What I would advocate for (and have) is to add specific useful features to Elisp in the specific areas where Elisp is lacking. For a single example, Elisp has no fold or reduce, and I have found need to write it myself on more than on occasion. Anyway, my basic point is that if you want to see Elisp improved, there are more elegant languages than Common Lisp to use as your model. -- John Foerch
Date: Tue, 9 Feb 2010 11:54:28 -0500 From: [email protected]
Anyway, my basic point is that if you want to see Elisp improved, there are more elegant languages than Common Lisp to use as your model.
It's an interesting debate. What other languages do you have in mind? Vegard _________________________________________________________________ Windows 7: Se direkte-TV fra den bærbare PCen. Finn ut mer. http://windows.microsoft.com/windows-7
On Sat, Feb 13, 2010 at 02:04:42PM +0000, Vegard Øye wrote:
Date: Tue, 9 Feb 2010 11:54:28 -0500 From: [email protected]
Anyway, my basic point is that if you want to see Elisp improved, there are more elegant languages than Common Lisp to use as your model.
It's an interesting debate. What other languages do you have in mind?
Just drawing from my own experience, Scheme and Haskell. I think that Common Lisp is often harder to read than it needs to be because it often uses auxiliary information like keywords where alternative functions would be more appropriate. An example that always comes to mind is right reduction (folding): Common Lisp: (reduce #'func seq :from-end t :initial-value init) Scheme: (fold-right func init seq) Haskell: foldr func init seq The meaning of both the Scheme and Haskell versions is obvious, but the Common Lisp version makes the reader study extra information in order to get the meaning. The meaning of the program is a step removed from from its textual representation. Semantics can be a nuanced and subjective topic, but I hope that language designers (like those of Elisp) will always be mindful of semantics, because programs that are easier to read are easier to think about. I hope what I have said makes some sense. -- John Foerch
participants (4)
-
Jason Spiro -
John J. Foerch -
Vegard Øye -
Štěpán Němec