Developing a PHP package

Developing a PHP package

[Hugo Thunnissen]

Hello emacs developers,

I am working on a package to work with PHP code. It currently consists
of a (very tolerant) recursive descent parser and company-mode + eldoc
backends. The parser is written from scratch in emacs lisp and has no
outside dependencies. The company-mode and eldoc backends (partially)
lex the syntax tree produced by the parser to provide intelligent
completion for and information about the code someone is working on. It
is still a work in progress but It's starting to come along quite nicely
and I've been considering what to do with the work. Contributing it to
the emacs core would have my preference. Is there interest in having
such a package in the emacs core?

If so, I have several questions:

- How does the process of contributing a package to emacs usually go?

- I have read that there is work being done on incorporating lib
  tree-sitter in emacs, would tree-sitter make a package like mine
  obsolete?

- The parser is currently only used for completion, but could
  theoretically also be used (with some modifications) to do syntax
  highlighting and indentation, making for somewhat of an alternative to
  PHP-mode in the future.  Would there be interest in something like
  that?

- The package has a dependency on a bash script that uses some GNU
  coreutils (find, grep) and diff from GNU diffutils. The script is used
  to find files containing definitions of PHP classes and namespaces,
  but not for any of code parsing. What is the policy for emacs packages
  having dependencies on external programs like that?

- I am currently in the process of cleaning up the code and writing some
  documentation/tests. When I have made some progress on that, would it
  be OK for me to submit my code to this mailing list for
  feedback/reviews? That would be very helpful.

For those interested, I also made a reddit post with a small demo video,
which sprouted some conversation in its comment section:

https://www.reddit.com/r/emacs/comments/peezh4/teaser_a_php_parser_and_company_backend_in_emacs/

Thank you for taking the time to read this mail, and for future
discourse: I am new to mailing list etiquette, feel free to point out
when I am doing it wrong :)

- Hugo Thunnissen

Re: Developing a PHP package

[Stefan Monnier]

> the emacs core would have my preference. Is there interest in having
> such a package in the emacs core?

I'll let Emacs maintainers decide whether they want it in the core, but
I'd be happy to add it to GNU ELPA.  In both cases we'd first need you
to sign some copyright paperwork anyway.  If you're OK with that, please
fill the form after my sig and send it to the FSF as instructed so they
can send you the appropriate paperwork to sign.

> - I have read that there is work being done on incorporating lib
>   tree-sitter in emacs, would tree-sitter make a package like mine
>   obsolete?

Could be, but in my experience, there's often room for several competing
solutions anyway.

> - The parser is currently only used for completion, but could
>   theoretically also be used (with some modifications) to do syntax
>   highlighting and indentation, making for somewhat of an alternative to
>   PHP-mode in the future.  Would there be interest in something like
>   that?

Yes.  Better would be for it to be a *complement* rather than an
alternative, so that improvements don't need to be duplicated in the
two packages.

> - The package has a dependency on a bash script that uses some GNU
>   coreutils (find, grep) and diff from GNU diffutils. The script is used
>   to find files containing definitions of PHP classes and namespaces,
>   but not for any of code parsing. What is the policy for emacs packages
>   having dependencies on external programs like that?

Emacs already has such dependencies (e.g. `M-x diff`, `M-x grep`, ...),
so that's not a problem.  Some of your users may be affected (typically
under Windows), but that's secondary (it's only a matter of "quality"
than policy).

Do you have a Git repository for your code somewhere?


        Stefan


Please email the following information to assign@gnu.org, and we
will send you the assignment form for your past and future changes.

Please use your full legal name (in ASCII characters) as the subject
line of the message.
----------------------------------------------------------------------
REQUEST: SEND FORM FOR PAST AND FUTURE CHANGES

[What is the name of the program or package you're contributing to?]
Emacs

[Did you copy any files or text written by someone else in these changes?
Even if that material is free software, we need to know about it.]


[Do you have an employer who might have a basis to claim to own
your changes?  Do you attend a school which might make such a claim?]


[For the copyright registration, what country are you a citizen of?]


[What year were you born?]


[Please write your email address here.]


[Please write your postal address here.]





[Which files have you changed so far, and which new files have you written
so far?]

Re: Developing a PHP package

[Dmitry Gutov]

On 04.09.2021 19:37, Hugo Thunnissen wrote:
> Is there interest in having
> such a package in the emacs core?

Given that the user will need to install a major mode anyway, and we 
don't have such in the core, ELPA seems more appropriate IMO.

Re: Developing a PHP package

[Eli Zaretskii]

> From: Hugo Thunnissen <devel@hugot.nl>
> Date: Sat, 04 Sep 2021 16:37:22 +0000
> 
> - How does the process of contributing a package to emacs usually go?

You tell us you want to submit your package, we look at the code,
comment on any stuff we may wish to change to adapt to our coding
conventions, and then we add it to Emacs.

> - I have read that there is work being done on incorporating lib
>   tree-sitter in emacs, would tree-sitter make a package like mine
>   obsolete?

No, because TS will most probably be an optional library, at least
originally.

> - The parser is currently only used for completion, but could
>   theoretically also be used (with some modifications) to do syntax
>   highlighting and indentation, making for somewhat of an alternative to
>   PHP-mode in the future.  Would there be interest in something like
>   that?

Yes, I think so.

> - The package has a dependency on a bash script that uses some GNU
>   coreutils (find, grep) and diff from GNU diffutils. The script is used
>   to find files containing definitions of PHP classes and namespaces,
>   but not for any of code parsing. What is the policy for emacs packages
>   having dependencies on external programs like that?

Why can't you use etags for that?

> Thank you for taking the time to read this mail, and for future
> discourse: I am new to mailing list etiquette, feel free to point out
> when I am doing it wrong :)

Thanks for working on your package and for your interest in Emacs in
general.

Re: Developing a PHP package

[Hugo Thunnissen]

> I'll let Emacs maintainers decide whether they want it in the core, but
> I'd be happy to add it to GNU ELPA.  In both cases we'd first need you
> to sign some copyright paperwork anyway.  If you're OK with that, please
> fill the form after my sig and send it to the FSF as instructed so they
> can send you the appropriate paperwork to sign.

Great, elpa is probably the best place to start anyways :). That
papwerwork won't be a problem.

>> - The parser is currently only used for completion, but could
>>   theoretically also be used (with some modifications) to do syntax
>>   highlighting and indentation, making for somewhat of an alternative to
>>   PHP-mode in the future.  Would there be interest in something like
>>   that?
>
> Yes.  Better would be for it to be a *complement* rather than an
> alternative, so that improvements don't need to be duplicated in the
> two packages.
>

It is my understanding from reading back a bit in in the mailing list
archives that php-mode cannot be merged into emacs, so I thought that
maybe it would make sense use this as the base for a new PHP mode. I
would still have to see whether implementing that is actually practical
though.

>
> Do you have a Git repository for your code somewhere?

I do now! https://git.sr.ht/~hugot/phpinspect.el . Excuse the lack of
documentation, I haven't found time to write much of that yet.


- Hugo

Re: Developing a PHP package

[Hugo Thunnissen]

> Why can't you use etags for that?

It's been a while since I implemented this part, so I am not sure
why. Half of the code has been lingering in my dotfile repository for a
couple of years ;). I am not familiar with the workings of etags, I will
look into that.


- Hugo

Re: Developing a PHP package

[Stefan Monnier]

>> I'll let Emacs maintainers decide whether they want it in the core, but
>> I'd be happy to add it to GNU ELPA.  In both cases we'd first need you
>> to sign some copyright paperwork anyway.  If you're OK with that, please
>> fill the form after my sig and send it to the FSF as instructed so they
>> can send you the appropriate paperwork to sign.
> Great, elpa is probably the best place to start anyways :).
> That papwerwork won't be a problem.

Excellent.  Let me know when the paperwork is done.

> It is my understanding from reading back a bit in in the mailing list
> archives that php-mode cannot be merged into Emacs, so I thought that
> maybe it would make sense use this as the base for a new PHP mode.
> I would still have to see whether implementing that is actually practical
> though.

Indeed, there are some issues.  This said, `php-mode` is now in NonGNU
ELPA, so an GNU ELPA package is now allowed to depend on `php-mode`.

But that's not necessarily what I had in mind.  I was just thinking of
making sure that the two package collaborate.  E.g. maybe the code in
the current `php-mode` could be split into a part (call it `php-core`)
for which we could get the paperwork (and hence put into GNU ELPA) and
which both packages can use, and try and move as much code as possible
into that `php-core`.

BTW, you might also want to take a look at `phps-mode` which is in GNU ELPA.

>> Do you have a Git repository for your code somewhere?
> I do now! https://git.sr.ht/~hugot/phpinspect.el. Excuse the lack of
> documentation, I haven't found time to write much of that yet.

Thanks.  I'll try and take a quick look at it when I find the time.


        Stefan

Re: Developing a PHP package

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> the emacs core would have my preference. Is there interest in having
>> such a package in the emacs core?
>
> I'll let Emacs maintainers decide whether they want it in the core, but
> I'd be happy to add it to GNU ELPA. 

I think it'd be really cool to have a PHP mode in Emacs core, but either
way is fine by me.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Developing a PHP package

[Juri Linkov]

>>> the emacs core would have my preference. Is there interest in having
>>> such a package in the emacs core?
>>
>> I'll let Emacs maintainers decide whether they want it in the core, but
>> I'd be happy to add it to GNU ELPA.
>
> I think it'd be really cool to have a PHP mode in Emacs core, but either
> way is fine by me.

That would have been cool 15 years ago ;-)

Re: Developing a PHP package

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Sun, 05 Sep 2021 09:40:02 +0200
> Cc: Hugo Thunnissen <devel@hugot.nl>, emacs-devel@gnu.org
> 
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> >> the emacs core would have my preference. Is there interest in having
> >> such a package in the emacs core?
> >
> > I'll let Emacs maintainers decide whether they want it in the core, but
> > I'd be happy to add it to GNU ELPA. 
> 
> I think it'd be really cool to have a PHP mode in Emacs core, but either
> way is fine by me.

I also tend to think it would be better if a PHP mode could be in
core.