another step further to wipe out emacs, vim and eclipse:
i'm very happy with the support adam gives me and with the developement today which gained some pace again. expext 0.3.1 these days.
Re:Wipe out?
sir_lichtkind on 2006-03-11T23:32:52
please what should i extend you mean this post? yeah im bit tired today also busy release 0.3.1 right now when itsout i will write a bit moreRe:Wipe out?
sir_lichtkind on 2006-03-11T23:39:57
ohh now i understood i was wrong first. i have clear vision of what i want to achieve and i do this not likely with the current codebase of vim or emacs. too much textbased, cannot grow good inough into areas of new crossplatform gui features. eclipse i the opposite of the architecture i want to build it would not be fun i would not do it likely voluntary. hope that answers your question.Re:Wipe out?
Phred on 2006-03-12T02:34:54
Sorry I was not more verbose in my reply. I don't have an understanding technically of how you are going to accomplish the refactoring editor but I was asking about the option of using a plugin to emacs or vim which might accomplish the same result. I've been spending a fair amount of time lately customizing both my vim and emacs installations with Perl development tools, and this popped into my mind as a great thing to have if it could be done also.
Emacs has a fairly advanced Lisp interface, Vim appears to have a shell based interface. I've been following a bit of the PPI work on the Perl Foundation blog but I need to set aside some time to read about it more. If the refactoring editor has a solid API then it should be possible to write plugins that call that api for Vim and Emacs. Do you think that is something that is possible given the tuits?
Re:Wipe out?
Alias on 2006-03-12T03:40:34
The underlying principle we are applying, in wanting to create a refactoring Perl editor, is based on an observation that the best software development tools are almost always written in the same language as what they target.
The truly standout Java editors are mostly written in Java, Python in Python, C++ in C++, Lisp in Lisp, and so on.
Writing the editor in the language means that your entire user community is capable of hacking on the editor, if you let them. And you get to leverage all the existing community infrastructure of that language.
As long as advanced functionality in emacs or vi or what have you isn't being written in Perl, what incentives are there for people to help out? You limit yourself to only the people that know both Lisp and Perl and greatly reduce your potential as a result.
You have to ask, why do we not have a really great Perl editor yet, given the incredible creativeness of the Perl community, and the productive made possible through the use of CPAN.
The concept for writing a truly great Perl editor would thus be to write an editor that is done as much as possible in Perl, and to provide an API for extending the editor that supports plugins and thus is friendly with the CPAN plugin development methodologies, and if at all possible where the refactoring functionality ITSELF is a CPAN module that you could embed into any other editor capable of hosting an instance of the refactoring engine.
So the same functionality from PCE could be used to create App::GUI::Notepad::Refactoring:)
Since PCE is itself already a working pure-Perl editor with pretty much all the basic editor functionality implemented, the idea is thus to make PCE CPAN-compatible, and then merge into it the capability of acting as a host for some notional Perl refactoring engine.
Creating a proof-of-concept for this idea is what the grant is for, to see whether or not the idea has real merit, and can be implemented.Re:Wipe out?
Phred on 2006-03-12T04:05:33
Thanks for the insight Alias, what you are saying makes a lot of sense. I've been extending Emacs and Vim lately to support Perl development, and it has been an interesting experience and less than straightforward. It would be nice to have an editor where I could say 'cpan -i App::GUI::Notepad::Refactoring::AutoComplete' and it Just Works
:)