Semantic Integration

[ejmr]

This is a long-term goal, but I would like to integrate Semantic support for PHP by Andrea Turso, @trashofmasters. I have spoken with him and we agreed that first the functionality should be tested by publishing it as a separate package. But once everyone feels that it is stable then I would like to merge it into PHP Mode, because I believe it will bring a lot of useful functionality, such as Intellisense-ish features for PHP programming. This issue is for discussing the pros and cons of integrating the Semantic PHP code and anything we need to keep an eye on down the road for that merge in the future---assuming it is feature that we want to merge into PHP Mode.

[periklis]

I would love to see semantic support for php. I'd a look on the grammar for @trashofmasters and it seems to be a bunch of good work done. However, i am not sure how aware you are about he efforts of Steven Remot with the official cedet crew support to make semantic and cedet work with php projects. Have a look on the grammar work done here: Cedet/Semantic PHP support

[ejmr]

Actually Andrea and Steven have been in contact with each other (as far as I know), so I'm hoping we can eventually integrate the combined efforts of both.

[periklis]

:thumbsup:

[calbrecht]

:thumbsup:

[metaturso]

You have rightly pointed out that Steven Remót has also been busy introducing PHP support to Semantic. Truth to be told, his work is far superior to mine.

I haven't yet familiarised myself with his codebase, but from what I could see he has extended the PHP grammar from the CEDET contrib packages to support the latest language features, added Composer project support to Ede, added automatic class imports, and a few other things that I've certainly missed.

This goes a long way to enabling Intellisense capabilities for PHP into Emacs. Kudos to him for the work done thus far :+1:

Please be aware that when it comes to writing eLisp code and Emacs packages I'm the new kid on the block.

As far as I am concerned, my work thus far has consisted of lurking the CEDET mailing lists and accurately studying the documentation of Semantic, Wisent and their surrounding CEDET subsystems.

Throughout the first period of my learning experience my focus is the production of a brand-new tag extraction parser that works with PHP-only files.

Furthermore I will keep reasearching the documentation of various other projects to maximise the support and utilities to editing PHP code in Emacs, such as autocompleting path and file names with Company mode, which is already possible in other modes, so it is only a matter of finding enabling correct option.

Taking into account the fact I generally work in elisp only during weekends -- which mostly involves RTFM -- you are looking at a time scale of about 6-8 months.

In terms of approaching Semantic integration with php-mode, like @ejmr pointed out the current feeling is to keep the projects separated.

When the maintainers and ultimately the users of php-mode are be happy and ready to have some Semantic PHP capabilities directly into php-mode, we will collaborate to port them over.

I believe that once we reach a reasonable set of usable features it would be natural to proceed with the development of a coordinated minor-mode, which can be installed separately, to provide php-mode buffers with the IDE goodness we've all been longing for.

Currently all the integration I have done is very much tied into my personal Emacs configuration, it is far from a portable solution.

I encourage anyone who feels like contributing to do so in any form they can think of; negative feedback is welcome.

Forgot to mention that while the code of CEDET components is very well documented, the documentation is very fragmented and it's not always immediately obvious what version it applies to, so it requires some reconciliation before it can be put into actual use.

Fortunately Steven has already been in touch with the CEDET dev team, who have expressed their intention to improving the documentation based on feedback from him and other language implementers.

[jorissteyn]

I encourage anyone who feels like contributing to do so in any form they can think of

Now I must respond. First, this thread is great!

I started experimenting with semantic a while back. Seeing all this renewed effort prompted me to stop playing around and just publish what I have done so far. I'll just give a quick summary of the components.

The sources can be found in two separate repositories. EDEP [1] contains the actual semantic integration and PHPTAGS [2] is a rudimentary tagging tool. Here I go.

edep-mode is a minor mode to make it everything more or less zero-config. It provides some functionality bypassing semantic, has a separate keymap and some customization settings to configure phptags.

semantic-php is where the interesting stuff can be found. The file starts with what you'd expect; a setup function that installs the parser and changes some buffer settings to accomodate the lexer and configures the CEDET tools. Other things in there are some semantic overrides and a hack that makes semantic able to lookup the parents of types without actually having to properly implement it using an overloadable function. A lot more research and development is needed to make this part (name resolution / scope calculation) properly work with semantic.

the parser grammar can be found in edep:edep/wisent-php.wy, it's an almost literal port of the official grammar and compiles with two shift/reduce conflicts exactly like the bison grammar. I tried to keep it as close to the official grammar as possible to make it easier to adopt new features. All rules are there, plus some extra rules (suffixed with _paren_block or _brace_block) to allow iterative parsing instead of bison-style parsing. Yes, it's way over the top, we probably don't need all that information and I imagine stripping it down or skipping some rules in the future. I do like however that it imposes little constraints on the source code: conditional class or function declarations, declarations with open/close tags in between, closures inside expressions, it all just works. The grammar actions do need more work in order to fully leverage the re-parsing mechanism.

the lexer is contained within the .wy file. Like the grammar, it tries to stay close to official lexer. The token stream should be very similar to token_get_all. For example, it produces tokens for open/close tags and lexes heredocs so they can be parsed using the official grammar rules for heredocs. Another example is floating point literals, the regexp in current cedet was copied from the java lexer and didn't recognize all the possibilities of a floating point in PHP. Maybe those details shouldn't have been a priority, but I wanted it to be correct, and having fun was (and still is) my biggest concern.

phptags leverages the php-parser project. There's probably tons of similar tools already out there but I created this one to specifically accomodate EDEP. In a nutshell: it uses reflection to generate tags for all internal symbols and parses a source repository recursively to do the same for source files. It flattens all the tags into one big (but fast) sqlite table which can then be queried. It doesn't know about relations between tags or anything else required for smart editing features, it just knows where a given symbol can be found. As I envision it now, it should stay that way.

symref and semanticdb. There's a symref and a semanticdb backend for phptags. Trying it now makes it feel a bit broken but symref actually worked very well.

jump.el contains some utilities to navigate the project and completely bypasses semantics context analysis. It's just using phptags directly, which is useful especially with helm-mode or your preferred fuzzy-find library.

the tests use ert and most are testing the lexer and parser. I wrote one or two tests for the current implementation of semantic-analyze-current-context and scope calculation.

the makefile defines two interesting targets, parser-create can be used to generate the parser from batch mode, and parser-test can be used to see how the wisent parser behaves on large amounts of different source files.

That's it. Let me know what you think. If anyone wants to get in touch to discuss this in more detail, send me a message. I don't yet know what my next steps will be. I'll also keep an eye on Stevens cedet fork I'm now aware of. I find his approach interesting.

[1] https://github.com/jorissteyn/edep [2] https://github.com/jorissteyn/phptags

[ejmr]

Very awesome @jorissteyn

[stevenremot]

Hey, @jorissteyn

Thank you for publishing your work, I had a quick look at it and it seems to be an awesome piece of work, with a lot of comments! I will take a closer look at it this weekend.

Your grammar is far cleaner than the one in my fork. On which official grammar did you base your work on? This does not look like the one in the spec [1], so I suppose this is the one in the PHP source?

Anyway, your support seems much more advanced than what Andrea and I have done. The only thing of interestest I see in my work, comparatively to yours, is my class autoloading system based on the composer.json file, which could provide jump and intellisense without having to do any indexation on big projects. However I quickly came to the conclusion that being able to generate an index is very important for stuffs like refactoring.

Do you have any future plans for your work?

[1] https://github.com/php/php-langspec/blob/master/spec/19-grammar.md

[periklis]

Many thx to @jorissteyn and @stevenremot for there great work.

I am currently evaluating both grammars and utilities at Mayflower GmbH on an >400k loc PHP project. Both have for me a good enough PHP language support. I'll have to deep further in the symref and phptags support, since the missing support for this in default CEDET made me to bypass them until now. I think both projects try to cover several CEDET aspects beyond semantic and as far as i read and understood your code, there seem to be differences, too.

However, what do you think of extracting the wisent grammar file from both projects and merge it according to the php-langspec project into a separate project? Maybe propose it to php-langspec? I think having wisent/bison grammar files separate would make other projects having a benefit, too?

Furthermore, as far as i am aware of @stevenremot had intensive contact with the cedet folks to bring the semantic support in CEDET. @stevenremot: Is the fsf-paperwork done for this? Or still blocked by the missing paperwork of the official contrib/php package in CEDET? Further plans? @jorissteyn: Any plans to merge the semantic support to CEDET?

[jorissteyn]

Hi Steven, thanks for your reply.

On which official grammar did you base your work on?

The answer is both. I used langspec as a reference while working on the lexer and the wisent grammar is a port of the bison grammar in php-src/Zend/language_parser.y in the master branch (so PHP7). So the rules and the names of (non)terminals between wisent-php.wy and zend_language_parser.y correspond very much. Wisent being a port of bison made it relatively straightforward. The end result would be the same no matter what starting point you take, because the syntactic grammar in langspec is a description of the bison grammar.

@periklis I hope this answers your question; I can't think of a benefit rewriting the grammar to look more like the grammar description in langspec. I wouldn't know what to propose to php-langspec, or is there a list of unofficial parsers somewhere? I'm very curious about your evaluation, let us know if it gives you new ideas or questions. Also, if you find any bug in phptags or EDEP, do file a bug on their github page. Especially if you find source code that makes the lexer or parser throw errors, I'd be very interested in knowing about that. Check out the parser-test make target as well (it doesn't do anything except test the parser with your code).

Regarding how to handle includes I came to same but reversed conclusion as @stevenremot: it's great having an external "omniscience" tag database but a lot better if it's optional and semantic can do most stuff without it. The omniscience solution should be complementary to your solution. So we're on the same page here.

I did consider the course of direction you're taking, but I felt it would in practice be very cumbersome. In order to make it work for a given project, you'd have to tell emacs all the PSR0 and PSR4 mappings of a project, which can be many, and then there's lots of code and popular frameworks using custom autoloader functions, PEAR naming (ok not in popular frameworks) or old-school include/require statements probably using expressions instead of string literals. And then there's frameworks like Drupal. Anyway, I was a bit too pessimistic about it perhaps, and if I understand correctly your EDE component figures out all the mappings from the composer file. So that solves the problem for projects using composer, that's valuable.

Do you have any future plans for your work?

Some things I want to do:

• make my semantic-php work without resolving fully qualified names in the hackish way it does now, I want it to work more like the c++ mode-local overrides.
• the parser does too much, it should skip the rules we don't need. If we keep using the parser for get-local-variables, we have to make it conditionally emit variable tags (I actually already did that once, it's easy).
• the grammar actions should work better with idle reparsing, this means using less EXPANDTAG macro's and more cooking inside the tag-expand function. I plan to in the future extend test/overlay.el to test the overlays of all tags, after we did research on how they should be.
• my semantic-php and wisent-php are not in the actual cedet repository, but technically it's no different from your (Stevens) wisent-php.el. I could move {semantic,wisent}-php out of the edep namespace to make it more clear it can be used without edep.
• we should also discuss how to progress on making the two works combined, maybe create a new repository and keep edep as a playground/incubator for cool features. Or just use edep where the usage of the minor mode is optional (that's more of a documentation change)
• I hope to be more active in materializing problems/solutions/questions in a well written way so Eric (Ludlam) / CEDET folks can be of more help. Steven is already doing that really well.

There's a lot more. I will think about this some more in the short-term, maybe create issues in github we can use to discuss stuff and be able to make it easier for people to chime in on the discussion or start working on an isolated part without people duplicating efforts on everything.

Any plans to merge the semantic support to CEDET?

Not specifically. But I think our shared goal is to create something that could go in there, making cedet contrib obsolete. Being part of the CEDET repository is no goal on its own, something separate that integrates well and can land in ELPA would be a great. Regarding copyright assignment, I hope all contributors are on the same page. Maybe in the not so far future we should formalize that.

Related to this, having 1st class smart editing support in emacs without a decent major mode shipped alongside it (that would have to be pulled from MELPA) is something that bothers me a little bit. RMS stated once he'd like to ship a PHP major-mode with emacs considering it's a widely used language. Lots of code was refactored out of php-mode last year and more can be rewritten, so the list of authors on php-mode did shrink a little bit which makes the prospect of contacting php-mode authors to reassign the copyright a little less grim (not saying it's feasible). I found the history of php-mode before ejmr's fork so I did look into that a while back. It would still involve lots of work contacting people and rewriting small parts. Maybe we should open a new issue on php-mode where we can discuss the future of the major mode.

I'll stop writing now with the closing remark that while I'm happy with the cc-mode refactorings last year, I'm not confident it's a solution we can keep up. If you think semantics internals are tough, take a look at cc-mode because that's a real monster (great piece of software nonetheless, but complex). I think someone should soon try to figure out to what extent the current cc/php-mode works well with PHP7 features, because if it breaks on typed functions, grouped include statements, and what else, I'm not sure how easy it would be to fix it properly. Maybe, and now I'm just dreaming, it's not that hard to create a new major-mode that uses SMIE. I also remember seeing messages on CEDETs mailing list about font-locking based on the wisent parser.

[ejmr]

…it's great having an external "omniscience" tag database but a lot better if it's optional and semantic can do most stuff without it.

It’s my understanding that Semantic creates a cache for such data, so I don’t think we need to rewrite that functionality unless there’s some unforeseen performance problem.

Lots of code was refactored out of php-mode last year and more can be rewritten, so the list of authors on php-mode did shrink a little bit which makes the prospect of contacting php-mode authors to reassign the copyright a little less grim (not saying it's feasible).

It’s effectively impossible, short of a rewrite. I had a conversation with Stefan Monnier years ago when I created my fork, asking about the chance to have PHP Mode come with Emacs itself. But to do so I’d have to convince everyone who has contributed to sign-off on the copyright, and for some people I have absolutely no way to contact them or determine which code is theirs (since we could remove and rewrite small pieces possibly).

But yeah, unfortunately this version of PHP Mode is never going to be built-in with Emacs. But with the growing prominence of package managers I’m personally ok with that.

[ejmr]

If you think semantics internals are tough, take a look at cc-mode because that's a real monster…

Understatement of the year, heh. If you’re comfortable with CC Mode then perhaps you could help me with #242.

[jorissteyn]

so I don’t think we need to rewrite that functionality

Agreed, I didn't mean to imply wanting re-inventing the wheel.

It’s effectively impossible, short of a rewrite.

I counted about 15 authors who worked on significant parts of the code base, so that probably is impossible. I'll give up on the thought. Your point on package managers is well taken.

About #242, that looks good. But is the heading Customizing Indentation Styles doesn't mention the variable php-lineup-cascaded-calls, which is the easier way to toggle the indention behaviour. Maybe we can find some more practical examples, I'll think about that.

[ejmr]

...doesn't mention the variable php-lineup-cascaded-calls...

Good point, thanks.

[periklis]

@periklis I hope this answers your question; I can't think of a benefit rewriting the grammar to look more like the grammar description in langspec. I wouldn't know what to propose to php-langspec, or is there a list of unofficial parsers somewhere?

@jorissteyn My intention was to have something conforming to the rules of php-langspec and/or zend_language_parser.y. That's what you did and i am fine with this. However, imho the grammar and semantic support belongs out of the EDEP package.

Furthermore, i was successful integrating EDEP with phptags and semenatic-php (db & symref) in my dot-emacs project. However, i noticed two issues:

1. PHPTags missing from packagist in order to use it in my global composer.json. I am using a composer based installation for php tooling like phpunit/php-refactor/etc. in my home directory.
2. Your semantic-php stuff has a missing dependency to the package cl-generic. Without this emacs produces a (void function cl-defmethod) error.

[jorissteyn]

However, imho the grammar and semantic support belongs out of the EDEP package.

I agree, I'm interested to know @stevenremot and @trashofmasters thoughts on how to progress on the pure semantic/wisent package.

Thanks for the issues, I created separate issues for them on my repositories. Will take a look at them later this week.

[stevenremot]

I agree, I'm interested to know @stevenremot and @trashofmasters thoughts on how to progress on the pure semantic/wisent package.

I totally agree with you on this point, basic semantic / wisent support should be independent from indexation / autoload emulation, potential refactoring tools, etc... So this would be nice to have a separate repository for it.

Regarding how to progress on it, your work seems a good starting point @jorissteyn because it seems quite complete and very clean (the grammar I'm working on is full of conflicts and supports only PHP up to 5.3). Then we could see what could be added in it (without complexifying it) to support the features we want to build on top of it.

Do you think it would be a good plan, or does someone have something better to propose?

@stevenremot: Is the fsf-paperwork done for this? Or still blocked by the missing paperwork of the official contrib/php package in CEDET? Further plans?

I already did the fsf paperwork for Emacs. However, the original author of wisent-php.wy and wisent-php.el didn't. This is why these files remain in CEDET/contrib directory.

Regarding my plans on my CEDET fork, they are actually changing now that I know I'm not working alone on it. Initially, I wanted to polish the features I added (fully-qualified name detection, autoloading and basic local context parsing) and then push it back to the original CEDET/contrib repository.

Now I think I should properly separate the features specific to my work (autoloading) from the generic semantic/wisent features so that I can make it a separate package compatible with the future pure semantic/wisent package.

In term of feature addition my plans remain the same though. I want people not to have to specifically create an ede-php-root project if they have a composer.json file, so that they can have autoloading without configuration. Then I would like to auto-detect and auto-configure more project types if possible, and even let people add their own autoloading rules.

[jorissteyn]

Hi Steven,

your last reply makes sense and I think we're both working on the right things. Having multiple standalone components that work with a pure semantic/wisent package is the way to go. I'm planning to move my semantic-php/wisent-php to a separate repository in the short future, and with that improve the semantic-php support routines to make more idiomatic use of semantic as a framework.

Altought slightly off-topic in that thread I wrote down a status update and some thoughts on EDE you might have some insights on here: https://github.com/jorissteyn/edep/issues/4.

I wont be much available upcoming two weeks so getting a response from me might take even longer than usual :)

[periklis]

@stevenremot & @jorissteyn : Any update on the status of an independent wisent-php grammar project? As far as i could register, @stevenremot dismissed his original work on his cedet fork, but brought us the excellent piece of work ede-php-autoload, which completes im my opinion a lot of what semantic stands for with completion pending to get merged. @jorissteyn proposed in the first place the split out.

Since both projects namely edep by @jorissteyn and cedet by @stevenremot are hosted on different places, it is not easy to track the feature completeness/missings of the current wisent parsers for php. Would you mind to give us a comparison of your parser implementations and any hint if this work could be merged or somehow incorporated to a single wisent-php repository on github?

I think having ede-php-autoload and a dedicated php-parser project would be enough for a kickoff making semantic permantly work for php projects, according to my tests with larger codebases @mayflower.

[jorissteyn]

Hi @periklis, @stevenremot, @trashofmasters and @kostajh

Any update on the status of an independent wisent-php grammar project?

I have not pushed anything past few weeks, but have been working on splitting 'semantic-php' into a separate repository as we discussed in other threads. So I'm still working in that direction.

I think my priorities have been wrong. So I'll make one promise: whether it is close to, or far from something useful, I'll push the repository this week and consolidate all the feature requests and TODO's in its issue tracker. I hope that will make it easier for Steven and me to coordinate. And easier for anyone to keep track on progress or find some task to work on, try something out or start a discussion. Because I agree that doesn't work very well currently.

[metaturso]

Hello all,

Firstly, sorry for my long absence from this thread but I haven't been able to spend much time on this because of work, hence @periklis I'm afraid to inform you that I didn't get much done on the ex-novo tagging parser.

However, I have been using ede-php-autoload consistently, and both Joris and Steven's PHP parser implementations on-and-off. Once we agree about where we should discuss this in more details, I'll collate and report my findings.

This should help @periklis and other users to form an idea of what the two parsers perform and how do they compare.

[jorissteyn]

So I'll make one promise

FYI, it's not coming today but it's coming. Still polishing things up.

[stevenremot]

Hey everyone,

You are right @periklis , I stopped working on my fork and I plan to contribute to @jorissteyn 's upcoming "semantic-php" project. I extracted the interesting part of my project, the autoloading emulation, in the project ede-php-autoload.

Since both projects namely edep by @jorissteyn and cedet by @stevenremot are hosted on different places, it is not easy to track the feature completeness/missings of the current wisent parsers for php. Would you mind to give us a comparison of your parser implementations and any hint if this work could be merged or somehow incorporated to a single wisent-php repository on github?

For a quick comparison, I built my fork on top of what has been implementing for PHP in CEDET. It supported PHP 4 so I updated it to PHP 5.3. I tried to integrate the support as deeply as possible in CEDET (it means I tried to override the base functions of CEDET so that it can immediately provide auto-completion, jumping, and basic documentation browsing features). However the cross-file completion and jumping are far from perfect, and I think I may not have choose the best method to do it.

@jorissteyn 's work provides an indexing system similar to a ctags for PHP code, and created a semantic support from scratch that's a bit tuned to worked with EDEP. When I tried EDEP it seemed to me that jumping should be much better than on my project, but that no auto-completion was provided. He seemed to have overriden CEDET behaviour at a higher layer than me, so you don't get all the features automatically. He is working to solve that, as far as I know. His code is also much cleaner than mine, maybe because I worked on top of someone else's work, and also because mine became a kind of battlefield at one point, maybe because of my several experiments :-D .

I don't intend to merge my fork's code into @jorissteyn the next "semantic-php" project, because I think its quality is not satisfying enough to keep it. However I may have achieved some stuffs @jorissteyn is trying to achieve as I have already worked on overriden CEDET's "core" behaviour, so I hope I can help on these subjects.

[phil-s]

Big thanks to everyone involved for working on this!

I'm not familiar with CEDET, and I'm curious about the likely capabilities of the tag-like functionality; especially with respect to name-spaced and/or object-oriented code.

Regular TAGS files work perfectly with (single name-space) procedural code, but they become far less usable when you have many (maybe dozens) of classes defining the method name you're trying to visit. I presume that name spaces must break things altogether.

I can envisage the name space issue being solvable, as I presume those could be resolved by Semantic within the current file.

The OOP issue seems to me as if it might require some fancy static analysis of the code base to achieve good results in general?? (Although I think there would be definite improvements to be gained from relatively simple forms of analysis as well.)

What sort of functionality could we expect from this aspect of the work?

[ejmr]

What sort of functionality could we expect from this aspect of the work?

If you look for articles or YouTube videos you can find those demonstrating CEDET in conjunction with C++ programming, and you will see useful tools like Imenu and auto-completion being aware of the methods available for a given object. That's an example of the high-level, "actually understands PHP's semantics" functionality that I think we all want from this endeavor and want to have in PHP Mode someday.

[metaturso]

@phil-s as Exactly, there are many limitations to using tags when working with modularised code, where it's common to see functions with similar names in different namespaces.

This is because the tags are searched purely based on their name, and no heuristic is used to restrict the set of valid candidates.

I think I wouldn't be wrong to say that what we are trying to achieve here is to find simple heuristics, preferably leveraging existing Emacs components, to make Emacs more aware of the context in your PHP buffers.

For example, if you happen to have imported the user model with use My\Application\Models\User; at the top of your file, it's safe to assume that when you search for store you probably want the definition on the user model first.

Steven's php-ede-autoload package for example cleverly instructs the EDE project manager how to resolve PHP class names — using a PSR 0 and 4 compatible autoloader — which comes pretty handy to map fully qualified names to file names.

@stevenremot what would be needed to enable php-ede-autoload to treat all instances of the imported symbols as a FQN to make it work in the following examples?

use My\Application;
use My\Application\Services\FooService;

$user = new Models\User(); // {My\Application -> src/} => src/Models/User.php
$service = new FooService(); // {My\Application -> src/} => src/Services/FooService.php 

Would this be something within the responsibilities of your code, or do you think it's functionality that should be built on top?

[stevenremot]

Hey @trashofmasters ,

I don't think mapping all use statements and aliases to a fully qualified name should be the responsibility of ede-php-autoload. It is good at mapping FQN to files, which is already a non-trivial work, and I want this package to be only good at this.

Basically, in a day-to-day PHP development workflow, I want one to be able to replace ede-php-autoload with, for example @jorissteyn 's phptags just by disabling one and enabling the other. I don't mind at all adding some more features related to file <-> fqn mapping like https://github.com/stevenremot/ede-php-autoload/issues/7, but I expect more complex features to be built on top of ede-php-autoload instead of inside it.

I hope this answer does not disappoint you ;-)

[jimmy-biznessapps]

Hello, there.

I just wanted to say that this was a great addition to my PHP workflow even in its current state -- however, with the release of Emacs 26, it no longer functions at all. I'm disappointed because, even as it was, it was much better than what you got without it.

[zonuexe]

@jimmy-biznessapps What do you mean "it" and "you"? I do not yet understand the context of this issue, but if something's broken, I would like to fix it and reconfigure it.

[metaturso]

I believe he means that he liked Steven's autoloader integration with EDE and composer, which gave him a bare bone ability to locate class names/files by import (e.g. use Foo\Bar).

All of this in spite of the fact we basically put the Semantic+php collaboration in the back-burner.

[metaturso]

@jimmy-biznessapps if you're experiencing problems with the php-ede-autoloader on Emacs 26 you should file a bug at https://github.com/stevenremot/ede-php-autoload.

[ejmr]

Perhaps we should extend an invitation to have ede-php-autoload under the @emacs-php umbrella where it may be more likely to receive contributions, bug-fixes, etc.

[stevenremot]

I'm okay with it @ejmr , as I don't use this package anymore and stopped working on it for a long time. I recently replaced it with lsp-php which is fine for my occasionnal devs in PHP.

[jimmy-biznessapps]

It's actually semantic-php that has the stuff I really want -- and is completely busted on Emacs 26. I use ECB on top of CEDET, and it's super-useful having a C++-style class browser in that little ECB window.

@stevenremot , if you've abandoned this work for lsp-php, then maybe you could put a little blurb up on those projects "This is what I'm using now, go support those?" That's probably more useful than a bug report.

Anyone who does try to do this work in the future will note that it's not working in Emacs 26 pretty much immediately -- I literally can't even edit a file with it installed, because I keep getting idle-timer warnings popping up every 2 seconds.

Anyhow, I'm switching jobs in a few weeks to a job where nothing is written in PHP and it's unlikely we'll ever use it, so this is an academic question for me, now. And it may be entirely academic, since I might very well be the last person still using semantic-php, since it's not in ELPA/MELPA and doesn't work with Emacs 26 at all... :)

[zonuexe]

@jorissteyn @stevenremot If you are no longer interested, can you transfer the repository to @emacs-php? I can not promise to develop it with top priority, but it can be maintained by multiple members.

[stevenremot]

Thanks for the invite, I created an issue on ede-php-autoload to track the ownership transferring!

@stevenremot , if you've abandoned this work for lsp-php, then maybe you could put a little blurb up on those projects "This is what I'm using now, go support those?" That's probably more useful than a bug report.

Looks like it won't be necessary anymore, but yeah, this kind of notice could have been interesting, thanks for the suggestion.

[ejmr]

Thank you @stevenremot