Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Why not extend?
    • 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.
      • 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

        • 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.
          • 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 :)