D19637 doesn't actually improve this, but it brings us a step closer (since the logic is now in PHP and can be modified more easily to label symbols and add context).

The actual support issues were likely addressed or obsoleted by the above changes. The rest of this is still planned, probably won't move forward any time soon.

I think a reasonable path forward here is for Diviner to have a {symbol} sort of syntax which executes a symbol index query. The symbol index can already be configured to know how to offer links to external documentation.

See PHI185. This was fixed by D18753 but didn't get linked up.

Maybe this works now?

Per above, I think the pathway forward here is probably "tighter integration", not "merge/replace", i.e. tools for Diviner to automatically update Symbols, too. I'm just going to conceptually roll this up into T13047.

I think this probably isn't worth fixing in the upstream: different versions of PHP are mostly the same; there's usually a good argument for deploying the same version of PHP everywhere; and Phabricator supports both very old and very modern versions of PHP so it should usually be easy to run Phabricator on whatever version of PHP you're developing against.

I believe this is supported now (and for some time) in the general case in terms of Phabricator infrastructure. Actually getting it to work requires a very smart highlighter, and the upstream XHPAST highlighter is the only one in existence. But other tasks, like T3130, are better homes for parser/AST improvements to particular languages.

To reproduce:

I think this (and lint/coverage) should move to Conduit, yeah.

Thank you so much for giving me help here. Have a nice weekend. @avivey

It's based on git-grep. You can't give it any arguments.

Wow, that's great.

https://secure.phabricator.com/diffusion/P/browse/master/ - there's a Show Search button, that will let you search by filename or file contents.

Thank you so much for the help. Now it works.

Looking at the first image, it looks like the symbols are defined to be cpp symbols; That would fit your description of the behavior:
When searching from the search-field, the system ignores language of the symbols; When looking from a source file, it narrows down the search to files of the same language - in this case I think it should be swift.

I think this is reasonably supported now.

Haven't seen more issues here in several years.

I deployed rP4c1463eb to this server and the reproduction steps above now work correctly, so I think D14311 fixed things. Let us know if I missed anything.

Thanks, that's very helpful.

For example:

Do we actually have a reproduction case for this? I'm not sure where I'm supposed to click getLinterName to reproduce this.

https://secure.phabricator.com/diffusion/symbol/getLinterName/?lang=php&repositories=PHID-REPO-08d9fc47cf397db6ce83%2C[object%20Object]&jump=true

[object%20Object] should not be there. See (2).

Sorting out license signing. Will submit patch as soon as sort that out.

Note idea: very transparent grey color note to the top right corner of the first diff ' ctrl+click for lookup ' - short so not very annoying.

Additional memo: crtl+click doesn't work. One should press control first and move mouse outside/inside.

Discoverability is a problem now, and the best idea so far is add a note somewhere.

Memo to self: update docs.

Oh, sure, that makes sense. So maybe not "valuable indefinitely", just "valuable until Diviner can extract symbols from a bunch of languages".

Actually I fnd the "pipe CTAGS" use case odd. I think it would be more useful if you could just run diviner generate inside a directory and we automatically generate symbols and documentation (unless you disable one or the other perhaps). In particular, this could maybe let us generate documentation stubs for languages we don't know about.

I suspect it may not make sense to totally merge them -- particularly, I think the "pipe CTAGS into some script" sort of use case is valuable indefinitely.

PHP external symbols uses the PHP environment on the web server to detect what external symbols exist, which might be different from the what the users would want.
Consider using something like php_compat_info.json for better coverage.

Using command on Macs is fine.

ctrl is what every IDE I've ever used (Windows/Linux) uses, so I'm trying to keep this convention. It's probably the apple key on a mac?

We haven't tried this before, and it seems reasonable to me to try. A couple of thoughts: