Tuesday, February 21, 2017

Vim perl support

Lot's of questions about the packaged vim support for perl :-)

For context, doing ilist or dlist against a perl file brings my vim to a standstill. This seems mostly due to attempts to comb through lot's of perl library code. On my system
find /usr/lib/perl5/*_perl -type f -name '*.pm' | wc -l
yields about 8K files. And many of those files "use" other files. Searching that takes a long time.

Trying to work out a better use case for me leads me to a lot of questions/observations.

1) default includeexpr breaks an important use case, including a local library (AKA require('path/to/library'). The attempt to mangle an system path breaks this. Surely this can't be intended. In particular my work pattern is to build a test harness using local includes, something I suspect is common practice.

2) using "use" in include seems to have real issues. Perl has a lot of meta directives, warn, strict etc. that almost *every* module includes. Thus include will try to form a file and search, adding more burden to an already overburdened search path.

3) define seems overly broad, it matches any alpha plus underscore. I'm guessing this was an attempt to catch an edge case, but I'd rather have that not work that way.

4) Both include and define don't account for commented out code. FWIW, this ends up being an issue when I'm doing a little "printf" style debugging, as I have a snippet/macro that inserts a
use Data::Dumper; print Dumper $x;
That I usually comment out.

5) path seems a little weird. I trimmed down path to '.' and attempted to build out a smarter includeexpr and noticed that somehow vim was getting full paths. I'm not sure what was going on here, some candidates that made sense to me:
a) vim was getting this from the +perl support
b) Somehow the path info was being communicated earlier before the ftplugin modifications I made (I have these in 'after/ftplugin')

6) It would be nice to have some way to tell perl "don't go further here" with the include. I tried to do this via the includeexpr (and a long list of meta use directives to just return "" on, "warn" for example). It was unclear to me that this made a difference. If there was some sort of "only search so many levels" or "ignore include under these conditions" it seems to me that vim could have access to all those perl modules without having to search all the modules.

I'm trying to understand how to make my use case better (and have some thoughts) but I'm also trying to understand how the settings were made to be used. In particular I'm not clear as to why I might want completion, or definitions from any nested module inclusion. I can see searching any module that has been called by "use" something that seems quite useful. But for the most part I'd never want it to go any farther then that.

Ah well. Any tips/thoughts would be appreciated.
FWIW I'm currently
1) Disabling includeexpr
2) limiting include to just require
3) setting define to only match sub and my

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

No comments:

Post a Comment