ftplugin suggestions

[Josef Fortier]

Is this the maintenance channel?

(it seems so from the perl.vim ftplugin)

Two suggestions that seem a) easy enough to implement, b) strong enough and then a few questions

CHANGE PROPOSAL:

1) ignore comments in include (and define)

The change:

prepend ^\\s*[^#]*\\s* to the existing include and define options

This will let include ignore most commented out options

2) allow includeexpr to work with locally included files

Example

require('some/local/path.pl')

This fails currently, as the existing includeexpr attempts to construct a system level path

I'd suggest using a real as opposed to inline function.

a) It's easier to follow

b) it's hidden away in an ftplugin

c) It's a lot easier to build more complicated logic

In this case a simple branch on whether there is a double colon should suffice.

QUESTIONS:

1) Why is the define option so very broad?

I'd guess this is an effort to catch some odd edge case, but it seems problematic.

Is there a reason why it's not something like

setlocal define=^\\s*[^#]*\\s*\\(my\\s\\+\\\\|sub\\s\\+\\\\|constant\\s\\+\\)

2) Is there a way to work around the vast recursion that the existing include produce?

On my system checkpath on a perl file will lock up my computer for a minute or more.

This seems a combination of

a) a large number of files to check

b) No limits on recursion

c) Perl's overloading of "use" to include meta-directives (warn, strict etc) that are not relevant

d) Perls (strong) pattern of re-using as much as possible.

[Andy Lester]

> On Feb 22, 2017, at 4:58 PM, Josef Fortier <josef....@gmail.com> wrote:
>
> Is this the maintenance channel?

Yes, and I apologize for taking so long to approve your messages.

Ultimately these things will need to go into GitHub issues, but feel free to discuss here before doing that.

--
Andy Lester => www.petdance.com

[Josef Fortier]

Thanks :-) 

I apologize for posting twice (I talked myself into reposting on the fear that the original got lost somehow).

Some more thoughts after some reflection (posting is good for that).

On the first suggestion regarding adding comment filter on include and define:

The anchoring to start of line may well be not needed. I'd have to look in more depth for a scenario where perl might see a hash as a valid symbol and not a comment leader.
The anchored regex is at least safe and accounts for the (by far) most common sort of comment.

On the second regarding includeexpr:
It occurs to me there is a reason to use an inline function, name space "pollution".
It would be possible to put a ternary test for '::' but my original distaste still applies, it's pretty hard to follow.
This leads me to think that some sort of namespacing convention would be a good idea.

A common approach is to prefix with something like "VimPerl".
But, thinking about it, I believe the stronger approach is to use (abuse?) autoload style function calls.

That makes the name spacing explicit.
I have not tested it, but I know I've seen in-file autoload style function calls in Tim Popes fugitive plugin.
This would keep the function in one file (a very good idea I suspect).
There is another reason to make the function public, as opposed to inline.
It allows users to incorporate that function in their own personal includeexpr, i.e.:
1) set up a new function
2) Call the vim supplied function
3) perform additional proccessing.

4) change local includeexpr to this new function