Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number

Environments extended with embeded Perl: are they for real?

by stefp (Vicar)
on Mar 23, 2003 at 22:41 UTC ( #245324=perlmeditation: print w/replies, xml ) Need Help??

I just tried two environments (vim and emacs) extended with Perl and felt flat on my face. Clearly these extensions are not maintained/used. Why?

Side note: See below for a more detail story about my exeriences with emacs and vim Perl extensions

In these two cases, the explanation may be simple. Elisp is the accepted extension emacs language . Vim also comes with its own extension language even if it supports many other extension languages. Also you can do a lot by selecting a region and running it thru Perl so Perl as an extension language is unnecessary but for the more ambitious undertakings.

grinder was talking about using Perl and Postgres. Reading the pg doc, I see that Perl can be embedded in pg. Does anyone use it? What does it buy (say, compared to access pg with DBI)?

This led me to general thoughts about Perl as an extension language:

  • Is perl5 too complex as an extension language? May be when people learn a tool, they don't want to learn a too complex language to extend it. I am not talking of the complexity of XS here, but about what makes an extension language popular. late addition: Paul Prescod has a point in its otherwise very good page advocating against Perl. He says in substance that the power of a natural-like language is offset by the cost of learning it. I would add that a natural language comes with a nurturing environment (we speak of mother-tongue, do we?) while perl and most open-source languages don't. But IDEs can help here .
  • Is there some "physical" law here. Being a full fledged language, has Perl such a mass that it cannot be a satellite but has to be the object around which the satellites move (thanks to DBI, XML::Parser...)?
  • What do you think that parrot and Perl6 will change in these cosmologic landscape. May be that whole environments will be built around Perl6/parrot instead having it added as an afterthought or gluing to them?
  • BTW: What are the successful example of environments empowered by Perl5 as an extension language(gimp?).
For the curious, more about my experiences with Perl extensions of emacs and vim.

I switched a long time ago (circa 90) to emacs from vi because I could do everything in one emacs session (besides editing various files in different buffers, having different shell sessions, debugging using perldb or gdb...) but I always sincerely hate lisp syntax so I dislike very much to have to mess with emacs configuration files. Another PITA: emacs has been extended by so many people with extension following different conventions

Anyway, John Tobey wrote perlmacs so that emacs is extendable using Perl. But it does not work with recent version of emacs even if Mandrake dutifully distributes the emacs-EPL package.

I decided to look back at vi; or more precisely to its vim avatar. Except for the lack a of a decent pager and the ability to run shell or debugger. It seems pretty nifty.

Better, it supports many extensions languages including Perl. It is documented right in the nice hyperlinked system. So I tried it:

: perl  $main::curwin
This is supposed to access the variable for the current window. I got a segmentation fault.

-- stefp

Replies are listed 'Best First'.
Re: Environments extended with embeded Perl: are they for real?
by gmax (Abbot) on Mar 23, 2003 at 23:11 UTC

    I am currently using Vim's Perl extensions, and it is working just fine.

    Check a few practical examples for twisting your text with Perl from inside Vim at Editing features for advanced users under the title Wizardry: editing with Perl.

    Just a simple excerpt. You can sort your text using Perl's syntax, getting text from the editor's current buffer and writing back to it:

    :perl @lines = sort {$a <=> $b} $curbuf->Get(1 .. 15) :perl $curbuf->Set(1, @lines)

    update. I must mention that I re-compiled Vim to get that feature working correctly. Instruction for the task at the same node.

    _ _ _ _ (_|| | |(_|>< _|
      I am not so lucky. I am using vim 6.1 and perl 5.8.0 multithreaded (from Mandrake cooker). Thx for the pointers anyway.

      -- stefp

•Re: Environments extended with embeded Perl: are they for real?
by merlyn (Sage) on Mar 24, 2003 at 00:55 UTC
Re: Environments extended with embeded Perl: are they for real? (vim+debugger)
by Aristotle (Chancellor) on Mar 23, 2003 at 23:57 UTC
    Except for the lack a of a decent pager and the ability to run shell or debugger. It seems pretty nifty.

    vim is an editor, not an IDE. However, there's nothing stopping anyone from integrating vim into an IDE, and that's what Bram Moolenaar, vim's author, is currently doing by way of Agide. It only posesses vim and gdb right now, no Perl debugger support, but it's supposedly very easy to integrate new tools. I've idly considered attempting that, but as I almost never use an interactive debugger I haven't bothered.

    What do you mean by pager?

    Makeshifts last the longest.

      About IDEs

      First , an IDE does not to include a GUI contrary to Agide (which seems interesting anyway. thx for the ptr).

      Second, it takes so long to learn an environment that you want it to do a lot with it. A text editor that cannot act as an IDE is not of much interest to me. Too bad, vim fall very short of that. Also "real IDEs" have a way to force things on you (define file for projects and so on) so sometimes it is interesting to have a best that is half-way between a full-fledged IDE and an text editor.

      About the vim pager

      Sometimes you get to display stuff that you can't scroll back to when you have gone thru. I don't have a interesting example out of hand. Anyway, say, you want to list all the options:
      :se all
      There is more than one pageful so you get a pager. But you can't scroll back or make a editable buffer out of what you got. At least, the new vim user I am don't know how to do it.

      -- stefp

        Ah, that pager - yeah, it does suck. You can redirect messages to a register or file though it is cumbersome. See help :redir. vi does indeed take a long time to get into and find your way around, but I find that once you've gotten into its way of getting things done, you can work with very little distraction. When in doubt, reach for :help - there's copious documentation.

        Personally, I think an editor is just an editor - period. Of course, while I read my mail with mutt, I do edit it with vim.

        $ grep vim .muttrc
        set editor="vim -c 'set textwidth=60 | normal }j'"

        Same goes for my Usenet perusal with slrn. It's also the editor midnight commander is set up to use (on the rare occasion I reach for that). And so on. Tools should do one job, not attempt to be everything under the sun. Where the tasks overlap (like needing an editor when dealing with mails), the tools should let the user tell them what other tools they want to use instead of providing their own rendition of it. I'm still peeved that Mozilla provides no way to use vim or another editor for text input areas on webpages - pasting to gvim and back just doesn't cut it.

        As always, though, different strokes for different people. I do think that most folks don't give vi a fair enough shot, but if they truly don't like it, far be it from me to force anything onto anyone.

        Makeshifts last the longest.

Re: Environments extended with embeded Perl: are they for real?
by diotalevi (Canon) on Mar 23, 2003 at 22:57 UTC

    Perl in PostgreSQL is designed to allow you access to perl functions directly from SQL. While the SQL still looks like SQL, you can implement the function in Perl instead of say, PL/pgSQL. If you're smart about not crossing the RDBMS/DBI line too many times then this can be a definite boon - if you're not up on all the costs associated with moving things between your RDBMS and your external language then it may not look like its worth much.

    For myself, I've never tried the perl extension because PL/pgSQL comes pre-built and I can get my work done with that.

      I have tried the PostgreSQL perl extension. It is quite nifty for small tasks like some text transformations (where Perl is really great while PL style languages are a bit primitive), but the connectivity to the whole data is a bit restricted. PL/pgSQL can access all the tables in a quite natural manner - by name, Perl subroutines currently can act only as mathematical functions - transforming the parameters into the return value, they have not access to the database tables. This should change since there is an iniciative to build a DBD style library for plperl, but it seems that it still will not be as natural as for a PL style language. Another restriction is that perl subroutines cannot call PL/pgSQL.
Re: Environments extended with embeded Perl: are they for real?
by dga (Hermit) on Mar 23, 2003 at 23:42 UTC

    I have looked at the Perl in PostgreSQL and it works fine. I have not used it in production only because I didn't have a need for those type of imbedded procedures. Where it would be useful would be where you wanted to work with some data as a procedure within the database so that whatever its triggered it the code gets run. Where I see perl excelling is in reformatting some text, or do something which plays to perl's strengths.

    One Pg/SQL example I saw was changing some text, 'CONFIDENTIAL', into 'C O N F I D E N T I A L' and it was pretty cumbersome in Pg/SQL compared to a 1 liner in the embedded Perl so that's the type of place I see for the Perl interpreter inside PostgreSQL.

    #basically this type of effect my $var=join(' ',split('','CONFIDENTIAL'));

    I rebuilt Perl into a shared library version to link it into Pg.

tips for using vim as a perl editor
by markjugg (Curate) on Mar 24, 2003 at 15:07 UTC
    Here are some things to put in your .vimrc file to improve your perl editting experience:
    " With these, you can type "K" when you are over a perl term " in your code, and it will look it up with "perldoc -f $term" " what I would like to happen is this: perldoc -f term || perldoc term " So, it tries to look up the keyword as a perl function " and then it tries to look it up as a module name if that fails au BufRead,BufNewFile *.pm setlocal keywordprg=perldoc\ -f au BufRead,BufNewFile *.pl setlocal keywordprg=perldoc\ -f au BufRead,BufNewFile *.cgi setlocal keywordprg=perldoc\ -f " You'll have to check for the location of on your system " With this, you can use ":mak", and will run your script through " 'perl -cw' and allow you to easily edit the results set makeprg=/usr/local/share/vim/vim61/tools/\ -c\ %\ $* set errorformat=%f:%l:%m

    You may also be interested in My Life with Text Editors


Re: Environments extended with embeded Perl: are they for real?
by blm (Hermit) on Mar 24, 2003 at 01:28 UTC
    I decided to look back at vi; or more precisely to its vim avatar. Except for the lack a of a decent pager and the ability to run shell or debugger. It seems pretty nifty.

    Do you mean by this that you think vim lacks the ability to run a shell? My vim lets me do this! Just prefix the command with :!.

    :!/bin/sh [No write since last change] sh-2.05b$
    Maybe you have rvim a restricted vim that doesn't let you do this? Or maybe I am misunderstanding?

      Do you mean by this that you think vim lacks the ability to run a shell? My vim lets me do this! Just prefix the command with :!.

      That's not what I meant. Please, excuse my vagueness and let me reformulate.

      My grief against vim is that one can't run a process (like a shell) and interact with it within a vim buffer so that you can (for example) record the session. Such feature is available with emacs. See its shell-mode for example.

      Simply starting a shell from vim has the additional inconvenience that you can easily stack a vim on top a shell on top a vim... I know that some shells have environment variables like SHLVL that you can manage to display as part of the prompt so that you can see when you stack stuff like that. But that is not addressing the real problem: the shell session should be available as a vim buffer.

      -- stefp

        vim is an editor ;), not a terminal emulator. You can use screen(1) to log interactive (and non.) sessions to a file, scroll the buffer, copypaste on the screen within the session and so on.

        This is generally where vim's mindset differs from emacs' - it doesn't try to do everything under the sun (and on the Sun) on its own, but usually easily integrates with something that does what you want.

        screen understands the vi movement keys in scroll mode, so one can get used to it quite quickly if one knows vim well.

        Makeshifts last the longest.

Re: Environments extended with embeded Perl: are they for real?
by jdporter (Chancellor) on Mar 24, 2003 at 04:46 UTC
    Except for the lack a of a decent pager...
    Not sure what you want, but when I do (e.g.)
    it pages the output (through more or something like it. (Tried it on Windows.))

    I got a segmentation fault.
    Are you sure your vim was compiled with perl support on? And that it's picking up the same perl as was detected/specified at compile time?

    The 6th Rule of Perl Club is -- There is no Rule #6.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://245324]
Approved by diotalevi
Front-paged by data64
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (4)
As of 2023-01-29 09:03 GMT
Find Nodes?
    Voting Booth?

    No recent polls found