Answers under asks ;)
On 9 May 2020 at 05:45:39, Basil Mohamed Gohar (basilgo...@fastmail.com) wrote: Dawid, This is a lot to take in and as someone not very familiar with the inner workings of Eclipse as it relates to PDT (or much else), so I am not sure how valuable my input could be in light of that. Nonetheless, I'll reply inline below (sorry for top-posting!). On Fri, May 8, 2020 at 3:59 pm, Dawid Pakuła <zu...@w3des.net> wrote: Hi, Despite to GitHub move I have couple plan for future releases. Since couple releases, thanks to hard teamwork, PDT is finally fast enough to consume a lot of large projects in one single workspace. But in meantime we started to spinning around, new features often require lot’s of workaround, bypass DLTK/WTP, etc.. It’s not direct problem of DLTK, but PHP evolve a lot since 5.4 and they haven’t plan to stop (PHP 8.0 will have attributes!!! :P). So, I think it’s time to start dropping DLTK as language support skeleton. How can someone who is not familiar with DLTK understand what DLTK brings to the table and what the ramifications of this would be? How much would you have to implement yourself to cover the gaps left by leaving DLTK? A list of pros- and cons- may be helpful to understand this if it's not too arduous. DLTK give us: 1. Indexing (I made small revolution for 2020-06 in this area) 2. Basic AST model 3. TypeInference (resolving code variable/call type using AST Tree) 4. Some UI elements like Search By Type 5. General Search infrastructure 6. SourceModel (namespace/class/method/field). This is main limitation here. We can’t register interfaces, class aliases, traits usage, imports per namespace and more.. I would like to have 2 kind of PHP projects: 1. Strict structure, fully controlled by composer (or anything else) and it’s configuration, where PDT will be able to correctly validate files, or react for file move 2. Weak structure, where everything is indexed, class path validation even if exists, it can be only on selected folders. Is it fair to say 1 is akin to PSR-based rules, while 2 is older-style, legacy PHP applications where you have to implicitly follow PHP's logic to know what is included where, etc.? If so, that kind of makes sense, but how is this better (from a user's perspective) than something that "just works" like what we have now, for the most part? After create project PDT should scan ALL files, and give you posibility to navigation, code assist end more. In general even on non-php project you should have full access to PHP classes code assists. Aside from some of Laravel's Facades, most of my projects seem to be more-or-less understood well by PDT and I can hope between references and definitions and get the code suggestions I'm looking for. I wonder if I'm missing the point of what you're saying here... Current way have to work correctly as before. But if you have for example composer class path registered, PDT should be able to validate class name, inform you about mistake in class (MyClass rather than my class). In current state it’s also hard, without destroying performance give you quick outline with methods from traits. In both cases we need much simpler model without garbage from Java models container, class folders, external containers etc.. This sounds good. Also completely independed to indexing and searching. I don't understand if this is good or bad. Doesn't some searching work across classes, functions, and so on? For now search is completely centralised and based on buildpath/sourcepath. We to provide mentioned validation we have to untick it from class pathes. Also we need ability to reindex/revalidate if something in hierarchy change. For example you will add method to MyServerInterface. After save all sub-classes should be marked as errored because they didn’t implement new method. In theory DLTK have some basic infrastructure but I couldn't get her to work without a ton of cache in the RAM. PHP model should be based on handly with ability to register alias, traits and others. This later allow us to simplify project import/creation, and later maybe ability to prepare PDT-LS for VSCode fans ;) What is PDT-LS? Should be same as JDT-LS - Java Development Tools Language Server. Some basic PDT features, like validation, indexing, code assist could be used in other editors that are able to consume Language Servers. For example VS Code or neovim. It’s long term goal. Without this we will fall, even on GitHub :P Off course some DLTK elements will be still valuable like Type Inference, Low-level indexing etc… During this process I plan to re-implement Twig/Doctrine/Symfony support (this projects are maintained by me only) and add to PDT Core as example how PDT should/could be extended. If we find volunteer, maybe other popular projects will add out-of-box support to PDT. I think this all sounds great. Greater framework support would be very welcome. I'd love to have Laravel Blade template support as well as better understanding of Facades. For blade I want implement at least basic syntax highlighting for SMARTY, TWIG and BLADE. With Eclipse TM4E project it will be relatively easy. Later we could investigate possibility to re-use existing language servers for them if they will be good enough. Maybe later we will try to untick from WTP (CSS/HTML code assist in php file) but for me is not priority now. Can you clarify a little more on this? PHP Editor is based on Eclipse Web Tools Project. We using HTML and CSS code assist from them. But they have problem with updating into newest technology. Since 2020-06 Eclipse PHP Package (downloads.eclipse.org) will be delivered with WildWebDeveloper. Project that trying to package and deliver as eclipse plugin existing popular and strong language server for newest technology. It currently have built-in support for: 1. HTML, CSS, SASS, LESS, SCSS 2. JavaScript / TypeScript 3. JSON/YAML/XML 4. Angular / React / ES Lint 5. And more, for example soon should have built-in support for VueJS Any thoughts? I'm happy to be part of the discussion and hope I can help more in the future. Thanks! _______________________________________________ pdt-dev mailing list pdt-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/pdt-dev
_______________________________________________ pdt-dev mailing list pdt-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/pdt-dev
