Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use with projectile #129

Closed
paopaol opened this issue Oct 14, 2018 · 24 comments

Comments

Projects
None yet
5 participants
@paopaol
Copy link

commented Oct 14, 2018

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

This comment has been minimized.

Copy link
Owner

commented Oct 15, 2018

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)

@joaotavora joaotavora changed the title can't find project root dir Use with projectile Oct 15, 2018

@bbatsov

This comment has been minimized.

Copy link

commented Nov 20, 2018

@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

This comment has been minimized.

Copy link

commented Nov 20, 2018

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

@joaotavora

This comment has been minimized.

Copy link
Owner

commented Nov 20, 2018

[ @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

This comment has been minimized.

Copy link
Owner

commented Nov 20, 2018

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

This comment has been minimized.

Copy link

commented Nov 20, 2018

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

This comment has been minimized.

Copy link
Owner

commented Nov 20, 2018

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

This comment has been minimized.

Copy link

commented Nov 20, 2018

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

This comment has been minimized.

Copy link
Owner

commented Nov 20, 2018

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

This comment has been minimized.

Copy link

commented Nov 20, 2018

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

This comment has been minimized.

Copy link

commented Nov 20, 2018

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

This comment has been minimized.

Copy link

commented Nov 20, 2018

@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

This comment has been minimized.

Copy link
Owner

commented Nov 20, 2018

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

This comment has been minimized.

Copy link

commented Nov 20, 2018

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

@joaotavora

This comment has been minimized.

Copy link
Owner

commented Nov 20, 2018

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

This comment has been minimized.

Copy link

commented Nov 20, 2018

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

This comment has been minimized.

Copy link
Owner

commented Nov 20, 2018

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

This comment has been minimized.

Copy link

commented Nov 21, 2018

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

This comment has been minimized.

Copy link
Owner

commented Nov 21, 2018

@dgutov

This comment has been minimized.

Copy link

commented Nov 21, 2018

@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

This comment has been minimized.

Copy link
Owner

commented Nov 21, 2018

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

This comment has been minimized.

Copy link

commented Nov 21, 2018

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

This comment has been minimized.

Copy link
Owner

commented Nov 21, 2018

@bbatsov
hackerman

@wyuenho

This comment has been minimized.

Copy link

commented Dec 4, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.