[ANN] evil 1.0.0 Released
Hi Evil users, finally we managed to release version 1.0.0 of Evil. The stable version will be maintaned in the branch 'stable-1.0' in the git repository [1], the 'master' branch remains for future developments. Evil is also available as ELPA package from marmalade [2]. In fact, the reason that it took so long is that I've not been able to upload the package to marmalade -- I've even managed to crash the server two times (maybe to contents of the package was too Evil ...). So I tried for some weeks and finally succeeded today ;) May the future be Evil, Frank [1] https://gitorious.org/evil/ [2] http://marmalade-repo.org
On Tue, Feb 12 2013 (09:44), Frank Fischer <[email protected]> wrote:
Hi Evil users,
finally we managed to release version 1.0.0 of Evil.
Truly, these are evil times! :) Thank you for all the work you put into evil, of course the same goes to Vegard and all other contributors! Let's make the Future of Emacs a bit more Evil! Michael
Dear Evil developers, M-x congratulations RET Cheers, Christoph (raising his vi reference cup to evil; similar to this one: http://www.linux2go.de/images/products/tasse_vi1l.jpg) -- Christoph Lange, School of Computer Science, University of Birmingham http://cs.bham.ac.uk/~langec/, Skype duke4701 → SePublica Workshop @ ESWC 2013. Montpellier, France, 26-30 May. Deadline 4 Mar; http://sepublica.mywikipaper.org → Intelligent Computer Mathematics, 7–12 Jul, Bath, UK; Deadline 8 Mar http://cicm-conference.org/2013/ → Enabling Domain Experts to use Formalised Reasoning @ AISB 2013 3–5 April 2013, Exeter, UK. 3 Hands-on Tutorials on Economics http://cs.bham.ac.uk/research/projects/formare/events/aisb2013/
Christoph LANGE <[email protected]> writes:
Dear Evil developers,
M-x congratulations RET
Shouldn't this be : congratulations RET ;-) Anyway, I concur! Thanks to all involved. -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 + Ma Gnus v0.6 : BBDB version 3.02 ($Date: 2013/02/16 14:37:17 $)
2013-02-19 10:29 Eric S Fraga:
Christoph LANGE <[email protected]> writes:
Dear Evil developers,
M-x congratulations RET
Shouldn't this be
: congratulations RET
The latter is not yet implemented, so for now only the M-x variant works ;-) SCNR Christoph -- Christoph Lange, School of Computer Science, University of Birmingham http://cs.bham.ac.uk/~langec/, Skype duke4701 → SePublica Workshop @ ESWC 2013. Montpellier, France, 26-30 May. Deadline 4 Mar; http://sepublica.mywikipaper.org → Intelligent Computer Mathematics, 7–12 Jul, Bath, UK; Deadline 8 Mar http://cicm-conference.org/2013/ → Enabling Domain Experts to use Formalised Reasoning @ AISB 2013 3–5 April 2013, Exeter, UK. 3 Hands-on Tutorials on Economics http://cs.bham.ac.uk/research/projects/formare/events/aisb2013/
Easy to fix ;) (evil-define-operator evil-congratulations (begin end) (message "1.0 released! Enjoy...")) (evil-ex-define-cmd "congratulations" 'evil-congratulations) Regards, Sanel On Tue, Feb 19, 2013 at 10:50:44AM +0000, Christoph LANGE wrote:
2013-02-19 10:29 Eric S Fraga:
Christoph LANGE <[email protected]> writes:
Dear Evil developers,
M-x congratulations RET
Shouldn't this be
: congratulations RET
The latter is not yet implemented, so for now only the M-x variant works ;-)
SCNR
Christoph
-- Christoph Lange, School of Computer Science, University of Birmingham http://cs.bham.ac.uk/~langec/, Skype duke4701
Wonderful news; congratulations! Do you have any specific plan for marketing or we (rest of the folks on this list) could put this announce on various online media? Btw. I'm planning for some time to start working on ':set' implementation, where things could be configured as in Vi/Vim. What do you think about it; have you planned similar feature or, after all, are you interested in those patches? Regards, Sanel Frank Fischer <[email protected]> wrote:
Hi Evil users,
finally we managed to release version 1.0.0 of Evil. The stable version will be maintaned in the branch 'stable-1.0' in the git repository [1], the 'master' branch remains for future developments.
Evil is also available as ELPA package from marmalade [2].
In fact, the reason that it took so long is that I've not been able to upload the package to marmalade -- I've even managed to crash the server two times (maybe to contents of the package was too Evil ...). So I tried for some weeks and finally succeeded today ;)
May the future be Evil, Frank
[1] https://gitorious.org/evil/ [2] http://marmalade-repo.org
_______________________________________________ implementations-list mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
On 2013-02-12, Sanel Zukan <[email protected]> wrote:
Do you have any specific plan for marketing or we (rest of the folks on this list) could put this announce on various online media?
I've never thought about something like this. Feel free to announce whereever you think it's appropriate ;)
Btw. I'm planning for some time to start working on ':set' implementation, where things could be configured as in Vi/Vim. What do you think about it; have you planned similar feature
No.
or, after all, are you interested in those patches?
Sure. But I think it could be quite challenging depending on what you want to achieve. Simply make :set VAR=VALUE an alternative to (setq VAR VALUE) should not be too difficult. But this would only work for Emacs variables. If you want give appropriate mappings of Vim variable names to Emacs settings, then this is probably much more difficult. In particular, because not every Vim setting has a direct counterpart but may need several adjustments. But I think it would be a nice feature to have ... ;) Best regards Frank
On Tue, Feb 12, 2013 at 07:49:56PM +0000, Frank Fischer wrote:
I've never thought about something like this. Feel free to announce whereever you think it's appropriate ;)
Evil got slashdotted :D (http://developers.slashdot.org/story/13/02/16/0251239/evil-almost-full-vim-i...)
Sure. But I think it could be quite challenging depending on what you want to achieve. Simply make :set VAR=VALUE an alternative to (setq VAR VALUE) should not be too difficult. But this would only work for Emacs variables. If you want give appropriate mappings of Vim variable names to Emacs settings, then this is probably much more difficult. In particular, because not every Vim setting has a direct counterpart but may need several adjustments. But I think it would be a nice feature to have ... ;)
I'm planning at the beginning to implement simple mappings, (:set VAR=VALUE equivalents to (setq VAR VALUE)) and later will see how things will develop. Truth to be told I'm mainly using shiftwidth, tabstop, showmatch and textwidth and emacs equivalents aren't always obvious due quite non-uniform interface (vi did this right).
Best regards Frank
Regards, Sanel
Also being discussed on /r/vim: http://www.reddit.com/r/vim/comments/18mky1/evil_a_nearly_complete_vim_imple... martin On Sat, Feb 16, 2013 at 11:06 AM, Sanel Zukan <[email protected]> wrote:
On Tue, Feb 12, 2013 at 07:49:56PM +0000, Frank Fischer wrote:
I've never thought about something like this. Feel free to announce whereever you think it's appropriate ;)
Evil got slashdotted :D (http://developers.slashdot.org/story/13/02/16/0251239/evil-almost-full-vim-i...)
Sure. But I think it could be quite challenging depending on what you want to achieve. Simply make :set VAR=VALUE an alternative to (setq VAR VALUE) should not be too difficult. But this would only work for Emacs variables. If you want give appropriate mappings of Vim variable names to Emacs settings, then this is probably much more difficult. In particular, because not every Vim setting has a direct counterpart but may need several adjustments. But I think it would be a nice feature to have ... ;)
I'm planning at the beginning to implement simple mappings, (:set VAR=VALUE equivalents to (setq VAR VALUE)) and later will see how things will develop. Truth to be told I'm mainly using shiftwidth, tabstop, showmatch and textwidth and emacs equivalents aren't always obvious due quite non-uniform interface (vi did this right).
Best regards Frank
Regards, Sanel
_______________________________________________ implementations-list mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
participants (7)
-
Christoph LANGE -
Eric S Fraga -
Frank Fischer -
Martin DeMello -
Michael Markert -
Sanel Zukan -
Tom Short