|
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.
_ _ _ _
(_|| | |(_|><
_|
| [reply]
[d/l]
[select] |
|
|
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
| [reply] |
•Re: Environments extended with embeded Perl: are they for real?
by merlyn (Sage) on Mar 24, 2003 at 00:55 UTC
|
| [reply] |
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.
| [reply] |
|
|
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
| [reply]
[d/l] |
|
|
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. | [reply] |
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.
| [reply] |
|
|
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.
| [reply] |
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.
| [reply]
[d/l] |
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 efm_perl.pl 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/efm_perl.pl\ -c\ %\ $*
set errorformat=%f:%l:%m
You may also be interested in My Life with Text Editors
-mark | [reply]
[d/l] |
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? | [reply]
[d/l] |
|
|
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
| [reply] |
|
|
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.
| [reply] |
Re: Environments extended with embeded Perl: are they for real?
by jdporter (Paladin) 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.)
:1,$p
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?
jdporter
The 6th Rule of Perl Club is -- There is no Rule #6. | [reply]
[d/l]
[select] |