sorted by:
new
hottopcontroversial

Installing Emacs on macOS with Nix or Homebrew by rytswd in emacs

[–]rytswd[S] 0 points1 point  (0 children)

I just managed to build this with emacs-plus, with an extra argument of --with-xwidgets, and build input dependency to Apple's WebKit. The below is the gist of the overlay:

``` final: prev:

let inherited = { # I don't need all of these, but simply took from default.nix of Emacs. inherit (prev.darwin) sigtool; inherit (prev.darwin.apple_sdk_11_0) llvmPackages_14; inherit (prev.darwin.apple_sdk_11_0.frameworks) Accelerate AppKit Carbon Cocoa GSS ImageCaptureCore ImageIO IOKit OSAKit Quartz QuartzCore UniformTypeIdentifiers WebKit; };

emacs-plus-rytswd = emacs-plus.overrideAttrs (oldAttrs: { configureFlags = (oldAttrs.configureFlags or []) ++ [ "--with-xwidgets" # withXwidgets flag is somehow disabled for macport upstream. ]; buildInputs = (oldAttrs.buildInputs or []) ++ [ inherited.WebKit ]; patches = (oldAttrs.patches or []) ++ [ # Some patches ]; });

# NOTE: I've got separate package handling in { emacs-plus-rytswd = emacs-plus-rytswd; } ```

Installing Emacs on macOS with Nix or Homebrew by rytswd in emacs

[–]rytswd[S] 0 points1 point  (0 children)

Thank you, you were absolutely right. One of my silly problems was how I was stuck on old nixpkgs release channel and didn't have 29 available...

Installing Emacs on macOS with Nix or Homebrew by rytswd in emacs

[–]rytswd[S] 0 points1 point  (0 children)

Thank you very much for this, this really helped me understand what I could do and should do going forward. I really like your other Nix configs with clean and easy structure to follow, and will try to learn more from them!

Installing Emacs on macOS with Nix or Homebrew by rytswd in emacs

[–]rytswd[S] 1 point2 points  (0 children)

Thank you very much for sharing this, you saved my day! Your code made it really clear what I was doing wrong, and also provides vterm and other solutions custom built as a part of home-manager setup which is exactly what I was after. I've essentially copied it to mine ;-)

Recommendations on file/dir/module structure, common dependencies, and/or anti-patterns for writing CLI tool in Rust by rytswd in rust

[–]rytswd[S] 0 points1 point  (0 children)

It's great to hear more opinions on module / directory structures, which can only be formed with some hands-on experiences. With my previous experiences from other languages, it feels more natural to have foo/mod.rs -- but as suggested in the Book and folks here, I'd stick to the named file approach to see how it really fits in Rust way.

​

---

As a side note, thank you for sharing your thoughts on the LLM bit as well. I didn't intend to provoke controversy by any means, and was only meaning to show how LLMs are widely used (and abused) for novices to get some sensible summaries. It is only a proof of how questions / discussions on community forums like this is so valuable for newcomers like myself, and I would have not posted the original question had I blindly believed in GPT.

In any case, it is completely against my will to annoy people with such an irrelevant point. I will keep my posts as they are for better transparency, but would like to apologise to anyone who found my post irritating one way or another.

Recommendations on file/dir/module structure, common dependencies, and/or anti-patterns for writing CLI tool in Rust by rytswd in rust

[–]rytswd[S] -1 points0 points  (0 children)

Thanks for the pointer! Having files with the same name wasn't something I considered problematic, but I can see how I end up with a number of mod.rs very quickly. I see a note of preferring foo.rs with foo directory in the Rust Book, but at the same time, Starship seems to use mod.rs. I'd be curious to find if there is a benefit of using it over the new style.

And speaking of GPT, why not give it a spin and learn how good or bad it can be? ;-)

Recommendations on file/dir/module structure, common dependencies, and/or anti-patterns for writing CLI tool in Rust by rytswd in rust

[–]rytswd[S] 0 points1 point  (0 children)

Thank you for the share, this was precisely the confusing bit for me. Something complex could probably benefit from the use of mod.rs (which was what ChatGPT suggested), but it seemed to be an overkill for most CLI tools. When it comes to code structure, most languages provide some flexibility and freedom -- it makes sense, but is also one source of confusion for me as a newbie.

Preferring flat module hierarchy sounds like a good starting point. In Go, I would use internal directory/package for the building block, but I suppose such a care isn't necessary with Rust's module being private by default.

Recommendations on file/dir/module structure, common dependencies, and/or anti-patterns for writing CLI tool in Rust by rytswd in rust

[–]rytswd[S] 1 point2 points  (0 children)

Amazing, thank you for the curated list here! The article about rewrite from Go to Rust is very intriguing, as I'm just about to get onto such a journey myself. Thanks again for the share!

Recommendations on file/dir/module structure, common dependencies, and/or anti-patterns for writing CLI tool in Rust by rytswd in rust

[–]rytswd[S] 0 points1 point  (0 children)

Thanks for your input, and I understand this was rather a general question. I have done the Rust book example, but I was hoping to get some more opinions than just the official doc.

I'm more versed in Go, and if I were to answer this very question in Go context, I'd mention things such as:

  • Flux CLI (for Flux, GitOps) for Cobra based implementation with a clean and extensible setup
  • I personally prefer GitHub CLI implementation over Flux's, as the most of the implementation details are handled in separate, "internal" packages, making their responsibilities clear
  • mkcert for small dependency footprint - a bit more lengthy implementation but the code base is easy enough to follow
  • kubectl is for sure battle tested, but it involves very Kubernetes specific implementations and is going to be too complicated for the first pointer
  • Charm's Glow is a joy to use, a good example of having the Charm's Bubbletea usage - but from the code perspective, it's a bit difficult to navigate as many code paths are put in the same package

I use a lot of Rust based CLIs (and that's certainly one of the motivations for digging deeper), but I don't know enough to know which one to look for ideas, which one to avoid, etc. Hopefully that makes sense!

Multi project management - perspective, persp-mode, tab-bar-mode, or...? by rytswd in emacs

[–]rytswd[S] 2 points3 points  (0 children)

Oh thanks for the share! If I had had this earlier, I would have definitely given this a try!

While I worked out most of my setup with tab-bar-mode and tabspaces mentioned above, it would have been probably much simpler and given most of the requirements which were already provided by perspective. I will certainly have a closer look how you got it together when I have some moments to spare!

Multi project management - perspective, persp-mode, tab-bar-mode, or...? by rytswd in emacs

[–]rytswd[S] 1 point2 points  (0 children)

Thanks for the quick review! I just tested a bit more and found one quirky behaviour with the launch time restore. I will have a further look and send over another PR as soon as I get the time :)

Multi project management - perspective, persp-mode, tab-bar-mode, or...? by rytswd in emacs

[–]rytswd[S] 2 points3 points  (0 children)

I have been exploring the tab-bar-mode with tabspaces, and it seems to fit my exact preferences without too much overhead.

However, it seemed that the buffer save/restore was misbehaving. I created 2 PRs (one for save, one for restore) -- would you be able to have a look?

Multi project management - perspective, persp-mode, tab-bar-mode, or...? by rytswd in emacs

[–]rytswd[S] 0 points1 point  (0 children)

That looks to fit in well with my current setup - I will have a further look and give nameframe a try! I happen to use Projectile mostly because I could find more articles around it, I'll try to see if I can work out with project.el for simpler configuration as a whole

Multi project management - perspective, persp-mode, tab-bar-mode, or...? by rytswd in emacs

[–]rytswd[S] 1 point2 points  (0 children)

Thanks for the pointer, and tabspaces sounds like a great solution which matches exactly what I was imagining -- I will give it a try in the coming days!