emacscollective / emacs.g

The Emacs Collective
ISC License
88 stars 49 forks source link

Replace hardcoded path with relative path #26

Closed dalugm closed 1 year ago

dalugm commented 1 year ago

Not everyone put their configuration under ~/.emacs.d, someone may place it in ~/.config/emacs etc...

tarsius commented 1 year ago

Thanks!

The correct relative path seems to be etc/codespell/ignore-words, not ../etc/codespell/ignore-words. Can you confirm that?

I cannot test this right now because I first have to package codespell for my distro. I will merge this once that is done and I do another update round anyway. (Applying a change to master, also means manually merging that into a dozen branches, so I try to avoid doing it for changes that aren't all that important.)

Ps: I use ~/.config/emacs now too.

dalugm commented 1 year ago

Can you confirm that?

I think ../xxx is right, since we changed to (user-emacs-directory)/lib in this line

https://github.com/emacscollective/emacs.g/blob/8d045c31ac3fa360e0428e4ebf473520eaaf3543/Makefile#L29

If we want to find the file under (user-emacs-directory)/etc/codespell dir, we need to use the relative path.

I have confirmed this in make codespell-dry, but I found I add a extra ../ in the --skip line in this pr (sry).

图片

If I remove it, make codespell-dry works fine.

图片

ps: I'm not a programmer, I don't know why the --skip line will jump back to the parent dir. (sed is too complicated to me)


BTW, you said

The correct relative path seems to be

Did you mean we shouldn't change to the (user-emacs-directory)/lib dir?

dalugm commented 1 year ago

The llama package in current master branch are using https instead of ssh, and there is one commit using ssh in this pr. Which one should we use? I know borg is using https now, should we keep using ssh?

And... I don't know how to change that commit message to solve the conflict. I only know how to use git commit --amend. If you can solve that problem, it would be great.

tarsius commented 1 year ago

I think ../xxx is right

Yep. Good thing I did not install my own edit without testing. :grinning:

Anyway, it will take a while until I get around some packages for my distro again and can test it. Meanwhile you can just change this in your configuration of course.

I am in the process of switching to https. Eventually I will also change the urls in the existing configuration, but as a consequence users will have a ton of conflicts when merging into their configuration. I also plan another change with a similar effect, but that still needs more work and testing. I plan to do these things at the same time, so that it is less work for everyone.

and there is one commit using ssh in this pr.

That was a mistake from when I though I would still merge this right away. I will remove these commits again.

Which one should we use?

In your own configuration you are of course free to do whatever you want. For configurations shared with others I now use https. For your own packages you might want to use ssh, so no extra configuration is necessary for pushing.

tarsius commented 1 year ago

Anyway... I decided to merge this now after all. (But I won't merge the result into all other layer branches until the next update round.)

dalugm commented 1 year ago

still needs more work and testing. I plan to do these things at the same time, so that it is less work for everyone.

Anyway... I decided to merge this now after all. (But I won't merge the result into all other layer branches until the next update round.)

Thanks for your meticulous work. I know this is a big project. Just take your time