Use with projectile

[paopaol]

i was use emacs 26.
and i place a .projectile file in my root-directory.then i open a cpp file which in my sub-directory. but the eglot use the file current direcotory as the root direcotry in lsp server init param.

lsp-mode works fine.
how can i fix this problem. thanks

[joaotavora]

Eglot doesn't use projectile, it uses Emacs's built-in project.el. See the documentation for project-find-functions. By default it searches for a .git directory, but your could add a function that searches for .projectile files.

This is entirely untested, it's possible you need to add more functions.

(defun joaot/find-projectile-project ()
  (let ((probe (locate-dominating-file default-directory ".projectile")))
    (when probe `(projectile . ,probe))))

(add-hook 'project-find-functions 'joaot/find-projectile-project 'append)

[bbatsov]

@joaotavora Given how popular Projectile is, it seems to me that you can at least add a check whether it's present and use it's project resolution logic. It's not like I can't add project.el integration to Projectile, but I really don't get what's the issue with adding some conditional support for Projectile given how simple eglot's usage of project.el is.

I get that project.el is built-in, but having something built-in doesn't necessarily make it the one true way, right? 😉

Obviously I'm a bit biased, but the "wontfix" tag was certainly disappointing to me.

[bbatsov]

I just remembered someone actually brought this up on Projectile's side as well - here's the conversation for reference bbatsov/projectile#1282

[joaotavora]

[ @dgutov, sorry to bother you again, but I think maybe you might want to add two cents to this, given you are the project.el maintainer ]

It's not like I can't add project.el integration to Projectile

I'm sure you can :-)

but I really don't get what's the issue with adding some conditional support for Projectile given how simple eglot's usage of project.el is.

That's precisely it: it's simple! Think with me: why should I add a non-essential dependency to eglot when:

1. You tell me that it's not hard to a a project.el backend to projectile. (I wouldn't expect it to be, at least not to someone with your skills).
2. There are alternatives in emacs core, where I want Eglot to be headed eventually

Eglot's core philosophy is this minimalism. I think part of the reason that some users are preferring eglot.el over lsp-mode.el is this. You may very well not appreciate them like I do, and that's just fine, but these are eglot's aesthetics, if you will. I wrote Eglot like this precisely to encourage people (and especially people like you) to contribute to Emacs's built-in alternatives : project.el, flymake.el, completion-at-point-functions, etc...

doesn't necessarily make it the one true way, right? 😉

It's not about the one true way. It's about giving project.el, which I personally believe is very well designed, enough visibility so that people (again like you) start paying some attention to it.

In the end it's also about maintainability. I don't want to learn projectile.el, sorry :-)

Same as with the flymake/flycheck debate. I want to give flymake.el visiblity. But I'm not actively shutting out flycheck.el.

I think the only point where you might rightly criticize is with the yasnippet.el integration. I wish there was an alternative in emacs core. In fact I started this work in the yasnippet.el repo, a new snippet.el library, but it's not quite finished yet (do you have a copyright assignment and want to finish it?).

Obviously I'm a bit biased, but the "wontfix" tag was certainly disappointing to me.

Again, it's not personal. It's a question of philosophy. And maintainability. I believe eglot should have a single interface to solve the problem "find the project for this file".

[joaotavora]

I just remembered someone actually brought this up on Projectile's side as well - here's the conversation for reference bbatsov/projectile#1282

I just read up on this conversation diagonally. Perhaps unsurprisingly, I agree 100% with @dgutov.

Regarding "the project I've been working on for 7 years", here's a strictly personal take: I kinda hate yasnippet, which I worked on for many years, too. If I could, I would rewrite all of it. I've been farther from that goal, but still not there. Meanwhile I can only be thankful that someone as industrious as Noam is maintaining it. We should be working providing yasnippet.el and projectile.el's legacy interface as a thin wrapper around much better designed libraries in Emacs's core or GNU Elpa. You can keep all the github stars and badge-bling and contribute to better and free software.

[bbatsov]

There are alternatives in emacs core, where I want Eglot to be headed eventually

Fair enough. I didn't know you planned to do this. As I told Dmitry, I think that Core is a dangerous place for innovation that's why I'm wary of putting projects there. For project.el I agree it certainly makes for something like this to be in Emacs, for Eglot it would depend on how popular LSP will become. Seems that the prognosis is optimistic right now. :-)

It's not about the one true way. It's about giving project.el, which I personally believe is very well designed, enough visibility so that people (again like you) start paying some attention to it.

Well, it's not really me you should worry about, but I understand your perspective.

In the end it's also about maintainability. I don't want to learn projectile.el, sorry :-)

That's perfectly fine.

Same as with the flymake/flycheck debate. I want to give flymake.el visiblity. But I'm not actively shutting out flycheck.el.

Are you implying that I'm actively shutting out project.el? The only premise I really question is whether core projects should be treated specially or not (and their long-term viability, given the relatively few people who end up maintaining them). That has nothing to do with project.el (or Emacs for that matter).

I think the only point where you might rightly criticize is with the yasnippet.el integration. I wish there was an alternative in emacs core. In fact I started this work in the yasnippet.el repo, a new snippet.el library, but it's not quite finished yet (do you have a copyright assignment and want to finish it?).

I'm afraid I'm not following. Is this based on something I said in the past? I recall I was frustrated with yasnippet when I was using it, but my memory has gone fuzzy.

Again, it's not personal. It's a question of philosophy. And maintainability. I believe eglot should have a single interface to solve the problem "find the project for this file".

Understood. Then I guess you can just close this ticket.

Regarding "the project I've been working on for 7 years", here's a strictly personal take: I kinda hate yasnippet, which I worked on for many years, too. If I could, I would rewrite all of it. I've been farther from that goal, but still not there. Meanwhile I can only be thankful that someone as industrious as Noam is maintaining it. We should be working providing yasnippet.el and projectile.el's legacy interface as a thin wrapper around much better designed libraries in Emacs's core or GNU Elpa.

I think that "much better design" is often subjective. I've seen plenty of poorly designed libraries in ELPA and Core. A project's hosting/status has nothing to do with its quality. Generally I would be happy to shed some of Projectile's project detection logic if favour of using project.el, but my use cases are simple and Projectile's users have some really fancy ones. Obviously it's up on us to decide how far we want to go with flexibility as it usually makes the code more complex, but that's a topic for a much longer philosophical conversation. :-)

If my messages came across the wrong way (again) - you've got my apologies. I was just interested why you're opposed to supporting Projectile directly and now I know.

You can keep all the github stars and badge-bling and contribute to better and free software.

As for people like contributing to Emacs's core - I'd love to do this, but I hate the dynamics there. The contribution process is hostile to newcomers and even if this is not a real problem for me at this point, it's still not something I want to inflict upon myself excessively. :-) I think that the fact that there are almost no new faces who stick around for long in Emacs core is the most powerful argument supporting the theory that we've got some real issue and not an imaginary one.

I don't give a fuck about stars, "fame" and glory - every project I ever started I started with the same goal - "I needed something myself.". If I build something that gets the job done for me, that's all the recognition I need. Sure, it's nice to make some wider impact with your work, but that's always accidental never the goal. That's why I'm also unwilling to engage myself to work on something I don't need, if I've already built tool(s) with which I'm reasonably happy. I'd like to help out solve more problems, but none of us has the time to work on every possible interesting project.

[joaotavora]

Are you implying that I'm actively shutting out project.el?

No, not at all. But there is an heated issue in this repo where someone complains that flycheck is much better and flymake sucks. I have suggested a way to get flycheck.el working in Eglot, but the the suggestion wasn't taken up.

A project's hosting/status has nothing to do with its quality.

I think I deserve your benefit of the doubt that I actually looked at the two designs. And I prefer project.el's, sorry.

The contribution process is hostile to newcomers

It's not, really. You just get a lot of eyes on your code. And you're not 100% in control of your code, because it's not really "yours" anymore. I think both are great thing.

happy to shed some of Projectile's project detection logic if favour of using project.el

Great. Let's have a candidate member for project-find-functions in projectile.el then. That's all that's needed, AFAIK.

but my use cases are simple and Projectile's users have some really fancy ones

Let them use projectile's fancy features for those, then. They won't break if you write a small function to plug into project-find-functions.

I'm afraid I'm not following. Is this based on something I said in the past? I recall I was frustrated with yasnippet when I was using it, but my memory has gone fuzzy.

No, I was just saying that since I have a yasnippet.el check in Eglot, but refuse projectile.el check, you could rightfully criticize me for that. You didn't, so don't worry. But if you had, it would be OK: that's what I was trying to say.

If my messages came across the wrong way

You always say this in in discussions :-) Chill, they don't come across the wrong way. I just don't agree with them.

[bbatsov]

I'm an eastern european after all - our direct communication style upsets many people. 😆 (even some other eastern europeans form time to time)

I think I deserve your benefit of the doubt that I actually looked at the two designs. And I prefer project.el's, sorry.

I guess you're referring to the root lookup design, right? Which is like 1% of Projectile. 😉 The big problems is, of course, what to do with projects nested in projects, projects with modules and stuff like this. If I conveniently omit them you'd have exactly the same design complexity-wise. I'm saying all this just to illustrate the point that you can't really compare designs without comparing the use-cases. We all want simple designs that achieve every possible (common?) use-case, but that's not always possible.

It's not, really. You just get a lot of eyes on your code. And you're not 100% in control of your code, because it's not really "yours" anymore. I think both are great thing.

That's not true. It simply is not. You get a handful of extremely opinionated reviewers and that's about it. Give me the benefit of the doubt - I've also had some small contributions to core and I've monitored the emacs-devel channel for over 10 years... It's not about who's in control - it's about how feedback is structure, who constructive it is and so on. Emacs has a toxic contribution culture and only someone who hasn't been exposed to other more open programming communities wouldn't notice this. I spent most of my time in the realms of Ruby and Clojure which are pretty different from Emacs's.

Great. Let's have a candidate member for project-find-functions in projectile.el then. That's all that's needed, AFAIK.

I think it's meant to be the other way around, right? I meant for me it'd be convenient if there was some bullet-proof project detection logic in project.el, I drop all the current project-detection code and I focus only on project navigation and management. This might happen some day. Time will tell.

Anyways, I said I'll provide this function and I will.

[joaotavora]

I think it's meant to be the other way around, right?

If you can provide all the "fancy features" of projectile.el by basing it on project.el interface, sure, it's much better. But until then

Anyways, I said I'll provide this function and I will.

Cool.

Emacs has a toxic contribution culture

A toxic reaction usually involves two parts. ;-) Here's the way I go about it. When I'm on emacs-devel, I imagine I'm in this big round table of older, younger, people of many backgrounds, technical, political... Really face to face with old gandalfs and also the cool kids. Regardless when I speak with respect, people generally respect me, and good things happen.

[dgutov]

I've left some more comments on the other thread. Here, I'd like to point out this:

I get that project.el is built-in, but having something built-in doesn't necessarily make it the one true way, right?

The difference between Projectile and project.el is like CIDER vs completion-at-point-functions plus the built-in completion-at-point command. Granted, the latter is considerably better adopted, but the intent is the same. So I'd rather not frame the situation in terms of competing projects.

Regarding the Emacs contribution culture, 🤷‍♂️. It may be somewhat archaic, but not toxic (at least for the last few years, maybe it was worse before). And if you ask for commit access, you often don't even have to talk to people.

I spent most of my time in the realms of Ruby and Clojure which are pretty different from Emacs's.

@bbatsov, didn't you at some point criticize both the Ruby core development process, and the difficulty of contributing to Clojure as well?

[bbatsov]

The difference between Projectile and project.el is like CIDER vs completion-at-point-functions plus the built-in completion-at-point command. Granted, the latter is considerably better adopted, but the intent is the same. So I'd rather not frame the situation in terms of competing projects.

👍

@bbatsov, didn't you at some point criticize both the Ruby core development process, and the difficulty of contributing to Clojure as well?

Yeah, I did, but for different reasons. There's always room for improvement. :-)

Anyways, I think it's clear how we have to proceed - I want us to start working on project.el in partnership with @dgutov, as that's really the only sane course of action. My only request is to find some way to manage/hack on the project that's not emails and ad-hoc commits to Emacs's master. :-) Maybe we can setup somewhere a git repo for project.el and just sync it up from time to time with Emacs? How does this sound?

[dgutov]

@bbatsov The common way for feature development these days is to create throwaway scratch/some-new-feature branches in the Emacs repo, and push code there. The discussions are still led on the mailing list. Do you have anything against that setup?

We could create a GitHub repo for the issues, or to host an Emacs fork and push code there, but that would exclude other core developers from the discussion, so I'd rather not.

Anyway, I'm not really expecting a lot of code changes, at least at first. Why not start with the mailing list?

[joaotavora]

Anyway, I'm not really expecting a lot of code changes, at least at first. Why not start with the mailing list?

Baby steps :-) If @bbatsov is still slightly sore with emacs-devel, it's better to setup the scratch/super-enhanced-project-el branch first and see some cowboy commit action there first. We can always clean it up later.

[dgutov]

Of course. There's even no need to setup anything. Commit away!

[joaotavora]

Perhaps to clear up my previous post: I think it's always better to approach a "request for comments" with something concrete to show. It clears up a lot of questions.

[dgutov]

Sometimes it's helpful to start with a discussion first, like clojure-emacs/cider#2351 (comment) demonstrates, so that we don't up rejecting a lot of proposed code. But I don't mind either approach.

[joaotavora]

Sometimes it's helpful to start with a discussion first

yeah, I know, it's a trade-off. BUt considering the context, and since you don't expect a lot of code...

[bbatsov]

Working with Emacs's repo is not really a concern for me. My concerns are:

• having a nice way to track open tasks, progress, who focuses on what, etc. Emacs never work well for this IMO.
• having some way to release project.el independently from Emacs (a-la seq.el, cl-lib.el, etc), so tools that rely on it won't have wait for Emacs releases to leverage some new features (that one is optional, but I think it's highly desirable)
• simplifying the process of code reviews - I don't see any harm in doing some traditional reviews before sending something on its way to Emacs

I agree with @dgutov that probably there won't be that many changes happening, but still it'd be nice if we managed to do them in a structured and enjoyable manner.

[joaotavora]

There is a way to release on GNU elpa one-file projects managed in trunk. I do that with jsonrpc. Coordinate with Dmitry and emacs-devel. Good luck!

…

On Wed, Nov 21, 2018, 09:06 Bozhidar Batsov ***@***.*** wrote: Working with Emacs's repo is not really a concern for me. My concerns are: - having a nice way to track open tasks, progress, who focuses on what, etc. Emacs never work well for this IMO. - having some way to release project.el independently from Emacs (a-la seq.el, cl-lib.el, etc), so tools that rely on it won't have wait for Emacs releases to leverage some new features (that one is optional, but I think it's highly desirable) - simplifying the process of code reviews - I don't see any harm in doing some traditional reviews before sending something on its way to Emacs I agree with @dgutov <https://github.com/dgutov> that probably there won't be that many changes happening, but still it'd be nice if we managed to do them in a structured and enjoyable manner. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#129 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXnw3K8OCfEy0iotjsyeF4rzSQ4suXkks5uxReEgaJpZM4XbCBQ> .

[dgutov]

@bbatsov Releasing project.el on GNU ELPA is indeed possible and not too hard. It can help external users with API-breaking changes, too.

Regarding the (non-optional?) rest: any chance you are going to start looking into contributing without extra effort from me up-front?

Yes, I'd also like to have a better bug tracker, code review platform, etc, for Emacs development, but using third-party platforms would mean excluding some people who already participated and have a stake in it, from those discussions. For non-user-facing, core project, the downsides outweigh the upsides, in my opinion. Especially since, again, I don't expect to see a lot of activity. Please feel free to prove me wrong here, of course.

[joaotavora]

I think we can all agree that emacs could work with new tools that fit more "modern" users. But that doesn't mean it's very bad. I for one love the pragmatic simplicity of code-reviews-as-email-replies-to-diffs, for example. I'm sure you can find a way to find this enjoyable @bbatsov: put on some retro sneakers and pretend you're an 80's hacker: don't need no stinkin web browser!

[bbatsov]

Regarding the (non-optional?) rest: any chance you are going to start looking into contributing without extra effort from me up-front?

Yeah, certainly. I just wanted to discuss some potential project setup, but I can live without it. Might be good for me to rediscover my 80s hacker side. :-) I'm trying to get a CIDER/nREPL release out the door and probably afterwards I'll pause on that front and try to do some work on project.el and projectile.

I'll sync-up with you via email when I get there.

[joaotavora]

@bbatsov

[wyuenho]

For posterity's sake, this bit of glue appears to work well:

  ;; Bridge projectile and project together so packages that depend on project
  ;; like eglot work
  (defun my-projectile-project-find-function (dir)
    (let ((root (projectile-project-root dir)))
      (and root (cons 'transient root))))

  (projectile-mode t)

  (with-eval-after-load 'project
    (add-to-list 'project-find-functions 'my-projectile-project-find-function))

Thanks @joaotavora for pointing me to the right direction in #175

EDIT BY @joaotavora : Watch out, this snippet is potentially problematic. Better avoid.!!!! See #697.

[joaotavora]

Watch out, the snippet above is problematic since it reduces project.el's ability to quickly discover project files.

[rileyrg]

Sorry to be late to the party here, but is there really no built-in compatibility between the excellent projectile and eglot? project.el might be ok for some, but it's lacking in many areas compared to projectile and while I understand that it's not a feature race, eglot recognizing a .projectile file as a root doesn't seem too much of an incursion. recognising .git as the "project root" doesnt work in cases where the .git is at the top of a hierarchy of smaller projects/modules.