7 ms·

I'm really glad that emacs is integrating modern tooling like LSP and tree-sitter, now Claude Code, but this approach is showing its age. I'm an emacs user of 2

I'm really glad that emacs is integrating modern tooling like LSP and tree-sitter, now Claude Code, but this approach is showing its age. I'm an emacs user of 20 years and honestly it's getting hard to configure everything these days. Claude Code before the IDE integration was actually the easiest thing to get working (since it just worked and then auto-revert-mode keeps my buffers in sync.) I'm on a new MacOS install for $WORK trying to get lsp and ts work with a Typescript/Go repo and after some $PATH wonkiness (my default shell is not the same shell as the one that emacs launches in) got typescript-ls working but gopls is still having issues being downloaded. I haven't spent the hour or two it would probably take to figure out why the in-built downloader can't put gopls in the right place. I'm curious what emacs users are doing these days. I'm using Zed right now and really enjoying it but it's really hard to give up 20 years of emacs and I do love how emacs can scale from small one-off config file editing to huge projects and I love how configurable it is. Is neovim better in this space? Should I be learning how to debug elisp better to understand how the commands interact with my environment? I've been using emacs keybindings (in Dvorak at that) for so long I don't know if I'd enjoy the neovim editing experience.

antipaul 1y ago
In macOS, I use the GUI Emacs from https://emacsformacosx.com/ https://emacsformacosx.com/ Perhaps if you solve shell issues there once, they will stick.
- Karrot_Kream 1y ago
  I'm running Homebrew's GUI Emacs which inherits from its opening shell. If I run GUI emacs from my shell then it inherits the environment of the shell so that seems to be doing okay. I'm quite busy outside of work right now so I'll probably take a crack at this in a few weeks, but it's also dismaying how annoying it is to manage all the ts and lsp dependencies to make my projects work, let alone pointing the lsp to use the right package.json or go path or other things. I have no doubt that, in time, I can whack-a-mole the issues down. It does reduce my confidence in changing my environment because of how brittle the stack is. That's what makes me curious about the rest of the ecosystem. Zed mostly works though I have had to configure it to use project-specific linter configs using somewhat underdocumented settings files. I'm curious if neovim is easier to get working because it's a smaller beast so easier to debug, but I also just don't know if I'd enjoy a switch to few-key modal editing from the chorded emacs style I love.
frumplestlatz 1y ago
For your particular shell issue: https://github.com/purcell/exec-path-from-shell https://github.com/purcell/exec-path-from-shell It can extract PATH and other environment variables from your login shell configuration.
- pxc 1y ago
  !! This seems really nice for macOS users! Less clunky than the "envfile" option Doom Emacs provides for sure. I also recognize the author's name because I use their direnv integration package all the time! That one is great, too.
lelele 1y ago
>> I'm curious what emacs users are doing these days. Still using it because of the massive amount of customizations accumulated in a time span close to yours. I'm often tempted to switch, but if I look back, what other editor would have served me for ~20 years, mostly unchanged? I remember writing lots of macros for Visual Studio 6 and then Microsoft revamped the object system of their IDE with .NET. My understanding is that Visual Studio plugins may not work from an IDE version to the next. Yes, customizing Emacs requires time, but so does relearning a new environment every few years. I do use other editors, however, for things that would require too much time to configure in Emacs, or for which I prefer a GUI interface. For example, at the moment I'm working on a C++ project in Emacs, yet for debugging and a Git GUI I have VSCode open. >> Is neovim better in this space? Maybe, because of the bigger use base of NeoVim/Vim. >> Should I be learning how to debug elisp better to understand how the commands interact with my environment? Definitely. >> I've been using emacs keybindings (in Dvorak at that) Hi, mate! (^_^) >> for so long I don't know if I'd enjoy the neovim editing experience. What? No [Neo]Vim user has ever ported Emacs keybinding to Insert Mode? O_o
- Karrot_Kream 1y ago
  > What? No [Neo]Vim user has ever ported Emacs keybinding to Insert Mode? O_o I'm curious how fluid that is. My experience with Emacs keybindings has been, well, variable to say the least. Maybe the vim-alike folks can make better experiences. Readline's emacs bindings are a bit lacking but still fairly good for day-to-day usage.
  - pxc 1y ago
    I am truly, to borrow a phrase from another commenter on this post, a "longtime Emacs dabbler". But I use Evil mode everywhere and sometimes use other Emacs bindings in Insert mode where they don't directly conflict with some other Evil binding. It feels more or less harmonious to me, but I started with Evil and I'm not particularly attached to any default Emacs bindings.
iLemming 1y ago
> Should I be learning how to debug elisp better to understand how the commands interact with my environment? Hell yeah, you should. I just don't understand how the heck people would claim to be using Emacs for decades and still not knowing how to use the built-in profiler, edebug, apropos, macro expansion, advising system, indirect buffers, etc. They would complain how "fickle" Emacs is, without even realizing that they are literally operating a living, breathing, dynamic and malleable system. If there's a car that allows you to assemble some parts onto it and turn it into a submarine while you're still driving it, of course it would require you at least the knowledge of basic troubleshooting and the acceptance that shit may break at any point. You have no idea how liberating the feeling is when you can pinpoint a problem, launch a gptel buffer and then ask Emacs to write some elisp for a hook or an advising function, you can even try the snippet in-place, without ever moving it anywhere. These days I don't even try to strive for a "clean" config - it's modular enough and I can relatively easily navigate through it. Whenever I face a problem, I just add some elisp. When something breaks (usually due to upstream changes), I don't even get annoyed. Identifying a problem and finding a workaround doesn't take too long - typically minutes - and it doesn't even happen very often.
- macintux 1y ago
  > I just don't understand how the heck people would claim to be using Emacs for decades and still not knowing how to use the built-in profiler, edebug, apropos, macro expansion, advising system, indirect buffers, etc. The second half of your message is interesting. The first half is needlessly condescending.
  - iLemming 1y ago
    > is needlessly condescending. While this may sound condesending, I believe it's understandable where the snub is coming from. VSCode doesn't need evangelism - it has become the de facto standard that every programmer is expected to know. Emacs occupies a different position entirely, and when curious newcomers encounter comments like "I used Emacs for 15 years before switching to...", they draw conclusions that may not reflect the full picture. Upon closer examination, these long-time "experts" often reveal they barely engaged with Emacs beyond basic editing - they've never published packages (which is actually far simpler than creating VSCode extensions), never written custom functions, never even added a simple advice for their own needs. This isn't truly "using Emacs"; it's merely dabbling in it. Unlike conventional tools where years translate to expertise along a predictable curve, Emacs rewards deep engagement over mere time served. When someone who spent years passively using Emacs criticizes it publicly, they inadvertently discourage potential users who might have discovered something transformative. The damage is disproportionate: criticizing VSCode barely makes a dent in its massive user base, but dismissing Emacs can deter the very people who would thrive in its ecosystem - those willing to invest in understanding a tool that becomes an extension of their thinking rather than just another tool. Therefore, of course I would be confrontational. I honestly have not ever seen an accurate, honest, factual review of Emacs criticism and comparison with other tools in the same space, because simply there isn't any other tool that operates at the same level. Critics compare surface features while missing that Emacs is essentially a different category of software altogether.
nextaccountic 1y ago
Note, Zed now has integration with Claude Code too[0], as an alternative to its own native agent (which funds Zed itself) [0] https://github.com/jiahaoxiang2000/claude-code-zed https://github.com/jiahaoxiang2000/claude-code-zed
alwillis 1y ago
Neovim editing has come a long way; you go from barebones (no plugins) to full-blown IDE and everything in between. There are lots of pre-configured Neovim distributions if you don't want to roll your own, such as LazyVim [1]. There are lots of AI plugins for Neovim [2]. [1]: https://www.lazyvim.org/ https://www.lazyvim.org/ [2]: https://github.com/rockerBOO/awesome-neovim?tab=readme-ov-file#ai https://github.com/rockerBOO/awesome-neovim?tab=readme-ov-fi...
- monooso 1y ago
  I have no idea why you're being downvoted.
donaldihunter 1y ago
> I'm curious what emacs users are doing these days. Using Emacs for pretty much everything. Org (w/ babel) for most of my notes, blogs, presentations and todo lists. Magit for everything git. Gnus for keeping up with the linux kernel mailing list firehose. LSPs for C, Python, Go, Rust. Tide for typescript. I use aider and aidermacs for my AI pair programming. Haven't tried Claude Code yet but it's on my todo list because everyone raves about it. I even use mastodon.el, and Circe for IRC. I use macOS native emacs built from source, currently 31.0.50. The largest project I work with is the Linux kernel which I edit remotely using Magit and LSP over TRAMP.
pxc 1y ago
> I'm curious what emacs users are doing these days. Integrating with a new language ecosystem is a significant amount of work for me because it involves making choices about what packages to configure and how, and which external dependencies to go with (e.g., which LSP server to use). I try to make those choices carefully, and for a lot of projects I touch in only a dabbler in those languages. It takes time to figure out. But for actually managing external dependencies (LSP servers, linters, static analyzers, etc.), I use Nix (in particular devenv.sh) and direnv so that Emacs doesn't have to download them; it just finds them on the path. I also sometimes configure those tools via Devenv as well, creating an in-repo RC file for them and pointing to it with an appropriate environment variable. Then my configuration lives in source control and the rest of my team can use the same tools regardless of editor choice.
- Karrot_Kream 1y ago
  Yes Nix is also something I've been thinking of diving into with emacs to solve this issue. What's your experience been running Nix on non-Linux targets? I mostly use MacOS and FreeBSD outside of Linux, primarily MacOS.
  - pxc 1y ago
    I've written most of the development environment declarations for my team's projects, which are mostly glue code or IaC in Terraform, Python, Bash (Nix can do some really cool things with Bash scripts[1]), and Ruby, and some Nix packages that we also use to deploy those projects. About half of my team uses Nix on macOS, and the other half uses Nix on Linux (via WSL), and our other deployment targets are all Linux on AWS (some EC2 boxes, some Lambda services, some ECS/Fargate deployments), though not all of those are Nix-based. There are sometimes small differences, like sometimes a Python package with native dependencies will fail to build in some Linux environments but not on macOS or vice-versa, but generally you don't, even then, need to special-case things by operating system to make them work uniformly. As for overall support, macOS is a more chaotic and quirky environment: macOS updates break applications or remove APIs more often than Linux updates do, macOS updates nuke configuration files in `/etc`, or blindly steamroll system users (low UIDs), the login shell doesn't manage environment variables or other aspects of the GUI session, etc. These are extra hurdles that Nix has to work around on macOS. But it generally works well and the only real hooks that Nix needs into your environment are some shell scripts that need to be sourced on startup. If you know how to manage your PATH and shell initialization in general, you can do it with Nix. (Additionally, one distributions of Nix itself includes some extra software for managing these hurdles that works pretty well at the cost of a more opinionated and more "invasive" install-- check out "Determinate Nix" if you're interested.) Other than that, it's basically the same as on Linux. Package selection is good, things mostly work the same way. Nix's support for platforms other than Linux and macOS is less mature. In years past, efforts have waxed and waned, but in the past few years there've been some concerted and persistent efforts to make Nix and Nixpkgs more usable on Windows, NetBSD, and FreeBSD. Even native (e.g., not just cross-compilation from other platforms) support for Windows is actually a thing! You can also easily set up "remote builders" to local VMs for Linux and FreeBSD so that you can transparently build packages and environments for those platforms on your Mac, if that's a frequent choice of development platform. Overall I'd say it's pretty good, but I don't personally know much about the current status of FreeBSD. It looks like there are a few hundred FreeBSD-specific packages in Nixpkgs, and there's also a fork of NixOS based on FreeBSD called NixBSD. Most packages include "platforms = [ unix ];" in their metadata, which means they're at least intended to build for not just Linux and macOS but also FreeBSD, but I don't know if Hydra is building binaries for any FreeBSD platforms. If it's not, then many packages may be untested and have small build problems. My guess is that at worst, Nix on FreeBSD is probably slightly behind where Nix on Linux was when I got into it 7 or 8 years ago. At that time, Nix still felt amazing and very worth it, but certainly required a willingness to learn how to package things and fill in gaps yourself to get the most out of it. Consider dropping by NixOS' Matrix community; I'm sure there's a FreeBSD channel. -- 1: https://github.com/abathur/resholve/ https://github.com/abathur/resholve/
wwarner 1y ago
I run emacs in docker to manage these issues https://github.com/wwarner/emacs-native-dockerfiles https://github.com/wwarner/emacs-native-dockerfiles
komali2 1y ago
> I'm curious what emacs users are doing these days. 8 years user here so still an emacs noobie, but I switched to nvim two months ago and haven't opened emacs in a month. Just slapped on lazy.vim and have been toggling the different AI tools in LazyExtras. I do find the ecosystem a lot better in nvim and it seems the community around nvim is more publicly engaged with new AI tooling - check out ThePrimeagen for example.
- iLemming 1y ago
  > 8 years user here so still an emacs noobie, but I switched to nvim I don't know man, whenever I see comments like this, I just don't get it - there's just no "switching" for me personally to anything, like ever, I just don't even see the possibility for it. The question that always gets me is like: "were you just using it like ... I don't know to edit text? That's all you've done with it?..." I have no idea how would I be able to do my things in anything else, whatever that is - Nvim, Sublime, Helix, etc. - How would I control video playback from my editor while taking notes? - How would I annotate PDFs? - Or, create and manage Anki cards - my flashcards are just my notes, they don't require a different medium to exist. - Or how would I test APIs - I don't need to use stuff like Postman - all my endpoint investigations are in my notes. Documented and perfectly reproducible. - How would I manage my dotfiles? I use Org-babel for it and it makes my entire system immutable - is it better than Nix? I dunno, it just works and it's simple. - What would I use for file management? I just wrote a wrapper that uses rsync to move large files around, how would I ever do anything like this in other than Emacs? How would I mark all the files that are over 1GB, older than three months and match a given regexp? - In Emacs, I can move my cursor to a piece of plain text like "RFC 959", "SAC-28410", or "my-org/some-service#182" and immediately start reading shit - it intelligently recognizes that the first one is an RFC document, another is a Jira ticket and the third one is a Pull-request on GitHub. - I can type a single query and simultaneously search for it on Wikipedia, Google, YouTube, GitHub, Hacker News or my own browser history, and I wouldn't even know how to do that in something that's not Emacs. - In Emacs I can type a shell command and pipe results into a buffer, or pipe the content of a buffer to a shell command. - In Emacs, my color theme changes depending on time of the day, because Emacs has built-in lunar and solar calendars. - How would I read and manage my email in Helix? - How would I track time? Clock in/out of tasks, generate time reports, do pomodoros? - How would I search, browse and read Hacker News and Reddit? - How would I create presentations? - How would I test database queries? - How would I manage Docker containers? - How would I read man pages? - How do I translate text? - And how would I interact with LLMs? ... Nope, there's no "switching" for me. It's just not possible. My entire life is woven into this text-based operating system. My thoughts, my work, my communications, my entertainment - they all exist as interconnected plain text that I can grep, link, transform, and version control. Every keystroke I've memorized, every workflow I've perfected, every piece of data that references another - it would take years to rebuild this in whatever there might be, and I'd still be left with a pale imitation. Emacs isn't just where I edit text; it's where I live.
__MatrixMan__ 1y ago
The path pain sounds to me like a job for nix. If a dependency is not ready at hand, the fix should be a single code change in the project, not separate environment fixes for each dev.
_flux 1y ago
Btw, LLMs are actually quite helpful for configuring Emacs, in particular for creating custom functionality.. But yeah, I broke my home Emacs setup somehow so that rust-mode no longer works in some situations. I have my config in git, though, so maybe I'll figure it out! At least I've started migrating to use use-package for configuration, to bring some structure to the configuration. Zed does seem rather interesting, but I don't ever see it being as configurable/extensible at runtime as Emacs. I suppose one could always just implement such features into the Zed itself; I presume its code is not too indimidating, given it's a modern code base and not likely to break in unexpected ways.
fergie 1y ago
> Typescript If Typescript is a big part of what you need to deal with on a daily basis, then at some point it makes sense just to use VSCode. And BTW, thats totally by design and a part of Microsoft's developer aquisition strategy.
b5n 1y ago
`use-package` has pretty much simplified everything: ;; c (use-package c-mode :ensure nil :defer t :mode "\\.cu?\\'" :config (setq c-default-style "gnu" c-basic-offset 2) :hook ((c-mode . lsp) (c-mode . bmacs-ide)))
- globular-toast 1y ago
  Use-package can even install third party packages automatically. Definitely worth learning. I converted my .emacs a few years ago. I'm using borg[0] to install stuff though because I like git. [0] https://github.com/emacscollective/borg https://github.com/emacscollective/borg

antipaul 1y ago

In macOS, I use the GUI Emacs from https://emacsformacosx.com/ https://emacsformacosx.com/ Perhaps if you solve shell issues there once, they will stick.

Karrot_Kream 1y ago
I'm running Homebrew's GUI Emacs which inherits from its opening shell. If I run GUI emacs from my shell then it inherits the environment of the shell so that seems to be doing okay. I'm quite busy outside of work right now so I'll probably take a crack at this in a few weeks, but it's also dismaying how annoying it is to manage all the ts and lsp dependencies to make my projects work, let alone pointing the lsp to use the right package.json or go path or other things. I have no doubt that, in time, I can whack-a-mole the issues down. It does reduce my confidence in changing my environment because of how brittle the stack is. That's what makes me curious about the rest of the ecosystem. Zed mostly works though I have had to configure it to use project-specific linter configs using somewhat underdocumented settings files. I'm curious if neovim is easier to get working because it's a smaller beast so easier to debug, but I also just don't know if I'd enjoy a switch to few-key modal editing from the chorded emacs style I love.

frumplestlatz 1y ago

For your particular shell issue: https://github.com/purcell/exec-path-from-shell https://github.com/purcell/exec-path-from-shell It can extract PATH and other environment variables from your login shell configuration.

pxc 1y ago
!! This seems really nice for macOS users! Less clunky than the "envfile" option Doom Emacs provides for sure. I also recognize the author's name because I use their direnv integration package all the time! That one is great, too.

lelele 1y ago

>> I'm curious what emacs users are doing these days. Still using it because of the massive amount of customizations accumulated in a time span close to yours. I'm often tempted to switch, but if I look back, what other editor would have served me for ~20 years, mostly unchanged? I remember writing lots of macros for Visual Studio 6 and then Microsoft revamped the object system of their IDE with .NET. My understanding is that Visual Studio plugins may not work from an IDE version to the next. Yes, customizing Emacs requires time, but so does relearning a new environment every few years. I do use other editors, however, for things that would require too much time to configure in Emacs, or for which I prefer a GUI interface. For example, at the moment I'm working on a C++ project in Emacs, yet for debugging and a Git GUI I have VSCode open. >> Is neovim better in this space? Maybe, because of the bigger use base of NeoVim/Vim. >> Should I be learning how to debug elisp better to understand how the commands interact with my environment? Definitely. >> I've been using emacs keybindings (in Dvorak at that) Hi, mate! (^_^) >> for so long I don't know if I'd enjoy the neovim editing experience. What? No [Neo]Vim user has ever ported Emacs keybinding to Insert Mode? O_o

Karrot_Kream 1y ago
> What? No [Neo]Vim user has ever ported Emacs keybinding to Insert Mode? O_o I'm curious how fluid that is. My experience with Emacs keybindings has been, well, variable to say the least. Maybe the vim-alike folks can make better experiences. Readline's emacs bindings are a bit lacking but still fairly good for day-to-day usage.
- pxc 1y ago
  I am truly, to borrow a phrase from another commenter on this post, a "longtime Emacs dabbler". But I use Evil mode everywhere and sometimes use other Emacs bindings in Insert mode where they don't directly conflict with some other Evil binding. It feels more or less harmonious to me, but I started with Evil and I'm not particularly attached to any default Emacs bindings.

iLemming 1y ago

> Should I be learning how to debug elisp better to understand how the commands interact with my environment? Hell yeah, you should. I just don't understand how the heck people would claim to be using Emacs for decades and still not knowing how to use the built-in profiler, edebug, apropos, macro expansion, advising system, indirect buffers, etc. They would complain how "fickle" Emacs is, without even realizing that they are literally operating a living, breathing, dynamic and malleable system. If there's a car that allows you to assemble some parts onto it and turn it into a submarine while you're still driving it, of course it would require you at least the knowledge of basic troubleshooting and the acceptance that shit may break at any point. You have no idea how liberating the feeling is when you can pinpoint a problem, launch a gptel buffer and then ask Emacs to write some elisp for a hook or an advising function, you can even try the snippet in-place, without ever moving it anywhere. These days I don't even try to strive for a "clean" config - it's modular enough and I can relatively easily navigate through it. Whenever I face a problem, I just add some elisp. When something breaks (usually due to upstream changes), I don't even get annoyed. Identifying a problem and finding a workaround doesn't take too long - typically minutes - and it doesn't even happen very often.

macintux 1y ago
> I just don't understand how the heck people would claim to be using Emacs for decades and still not knowing how to use the built-in profiler, edebug, apropos, macro expansion, advising system, indirect buffers, etc. The second half of your message is interesting. The first half is needlessly condescending.
- iLemming 1y ago
  > is needlessly condescending. While this may sound condesending, I believe it's understandable where the snub is coming from. VSCode doesn't need evangelism - it has become the de facto standard that every programmer is expected to know. Emacs occupies a different position entirely, and when curious newcomers encounter comments like "I used Emacs for 15 years before switching to...", they draw conclusions that may not reflect the full picture. Upon closer examination, these long-time "experts" often reveal they barely engaged with Emacs beyond basic editing - they've never published packages (which is actually far simpler than creating VSCode extensions), never written custom functions, never even added a simple advice for their own needs. This isn't truly "using Emacs"; it's merely dabbling in it. Unlike conventional tools where years translate to expertise along a predictable curve, Emacs rewards deep engagement over mere time served. When someone who spent years passively using Emacs criticizes it publicly, they inadvertently discourage potential users who might have discovered something transformative. The damage is disproportionate: criticizing VSCode barely makes a dent in its massive user base, but dismissing Emacs can deter the very people who would thrive in its ecosystem - those willing to invest in understanding a tool that becomes an extension of their thinking rather than just another tool. Therefore, of course I would be confrontational. I honestly have not ever seen an accurate, honest, factual review of Emacs criticism and comparison with other tools in the same space, because simply there isn't any other tool that operates at the same level. Critics compare surface features while missing that Emacs is essentially a different category of software altogether.

nextaccountic 1y ago

Note, Zed now has integration with Claude Code too[0], as an alternative to its own native agent (which funds Zed itself) [0] https://github.com/jiahaoxiang2000/claude-code-zed https://github.com/jiahaoxiang2000/claude-code-zed

alwillis 1y ago

Neovim editing has come a long way; you go from barebones (no plugins) to full-blown IDE and everything in between. There are lots of pre-configured Neovim distributions if you don't want to roll your own, such as LazyVim [1]. There are lots of AI plugins for Neovim [2]. [1]: https://www.lazyvim.org/ https://www.lazyvim.org/ [2]: https://github.com/rockerBOO/awesome-neovim?tab=readme-ov-file#ai https://github.com/rockerBOO/awesome-neovim?tab=readme-ov-fi...

monooso 1y ago
I have no idea why you're being downvoted.

donaldihunter 1y ago

> I'm curious what emacs users are doing these days. Using Emacs for pretty much everything. Org (w/ babel) for most of my notes, blogs, presentations and todo lists. Magit for everything git. Gnus for keeping up with the linux kernel mailing list firehose. LSPs for C, Python, Go, Rust. Tide for typescript. I use aider and aidermacs for my AI pair programming. Haven't tried Claude Code yet but it's on my todo list because everyone raves about it. I even use mastodon.el, and Circe for IRC. I use macOS native emacs built from source, currently 31.0.50. The largest project I work with is the Linux kernel which I edit remotely using Magit and LSP over TRAMP.

pxc 1y ago

> I'm curious what emacs users are doing these days. Integrating with a new language ecosystem is a significant amount of work for me because it involves making choices about what packages to configure and how, and which external dependencies to go with (e.g., which LSP server to use). I try to make those choices carefully, and for a lot of projects I touch in only a dabbler in those languages. It takes time to figure out. But for actually managing external dependencies (LSP servers, linters, static analyzers, etc.), I use Nix (in particular devenv.sh) and direnv so that Emacs doesn't have to download them; it just finds them on the path. I also sometimes configure those tools via Devenv as well, creating an in-repo RC file for them and pointing to it with an appropriate environment variable. Then my configuration lives in source control and the rest of my team can use the same tools regardless of editor choice.

Karrot_Kream 1y ago
Yes Nix is also something I've been thinking of diving into with emacs to solve this issue. What's your experience been running Nix on non-Linux targets? I mostly use MacOS and FreeBSD outside of Linux, primarily MacOS.
- pxc 1y ago
  I've written most of the development environment declarations for my team's projects, which are mostly glue code or IaC in Terraform, Python, Bash (Nix can do some really cool things with Bash scripts[1]), and Ruby, and some Nix packages that we also use to deploy those projects. About half of my team uses Nix on macOS, and the other half uses Nix on Linux (via WSL), and our other deployment targets are all Linux on AWS (some EC2 boxes, some Lambda services, some ECS/Fargate deployments), though not all of those are Nix-based. There are sometimes small differences, like sometimes a Python package with native dependencies will fail to build in some Linux environments but not on macOS or vice-versa, but generally you don't, even then, need to special-case things by operating system to make them work uniformly. As for overall support, macOS is a more chaotic and quirky environment: macOS updates break applications or remove APIs more often than Linux updates do, macOS updates nuke configuration files in `/etc`, or blindly steamroll system users (low UIDs), the login shell doesn't manage environment variables or other aspects of the GUI session, etc. These are extra hurdles that Nix has to work around on macOS. But it generally works well and the only real hooks that Nix needs into your environment are some shell scripts that need to be sourced on startup. If you know how to manage your PATH and shell initialization in general, you can do it with Nix. (Additionally, one distributions of Nix itself includes some extra software for managing these hurdles that works pretty well at the cost of a more opinionated and more "invasive" install-- check out "Determinate Nix" if you're interested.) Other than that, it's basically the same as on Linux. Package selection is good, things mostly work the same way. Nix's support for platforms other than Linux and macOS is less mature. In years past, efforts have waxed and waned, but in the past few years there've been some concerted and persistent efforts to make Nix and Nixpkgs more usable on Windows, NetBSD, and FreeBSD. Even native (e.g., not just cross-compilation from other platforms) support for Windows is actually a thing! You can also easily set up "remote builders" to local VMs for Linux and FreeBSD so that you can transparently build packages and environments for those platforms on your Mac, if that's a frequent choice of development platform. Overall I'd say it's pretty good, but I don't personally know much about the current status of FreeBSD. It looks like there are a few hundred FreeBSD-specific packages in Nixpkgs, and there's also a fork of NixOS based on FreeBSD called NixBSD. Most packages include "platforms = [ unix ];" in their metadata, which means they're at least intended to build for not just Linux and macOS but also FreeBSD, but I don't know if Hydra is building binaries for any FreeBSD platforms. If it's not, then many packages may be untested and have small build problems. My guess is that at worst, Nix on FreeBSD is probably slightly behind where Nix on Linux was when I got into it 7 or 8 years ago. At that time, Nix still felt amazing and very worth it, but certainly required a willingness to learn how to package things and fill in gaps yourself to get the most out of it. Consider dropping by NixOS' Matrix community; I'm sure there's a FreeBSD channel. -- 1: https://github.com/abathur/resholve/ https://github.com/abathur/resholve/

wwarner 1y ago

I run emacs in docker to manage these issues https://github.com/wwarner/emacs-native-dockerfiles https://github.com/wwarner/emacs-native-dockerfiles

komali2 1y ago

> I'm curious what emacs users are doing these days. 8 years user here so still an emacs noobie, but I switched to nvim two months ago and haven't opened emacs in a month. Just slapped on lazy.vim and have been toggling the different AI tools in LazyExtras. I do find the ecosystem a lot better in nvim and it seems the community around nvim is more publicly engaged with new AI tooling - check out ThePrimeagen for example.

iLemming 1y ago
> 8 years user here so still an emacs noobie, but I switched to nvim I don't know man, whenever I see comments like this, I just don't get it - there's just no "switching" for me personally to anything, like ever, I just don't even see the possibility for it. The question that always gets me is like: "were you just using it like ... I don't know to edit text? That's all you've done with it?..." I have no idea how would I be able to do my things in anything else, whatever that is - Nvim, Sublime, Helix, etc. - How would I control video playback from my editor while taking notes? - How would I annotate PDFs? - Or, create and manage Anki cards - my flashcards are just my notes, they don't require a different medium to exist. - Or how would I test APIs - I don't need to use stuff like Postman - all my endpoint investigations are in my notes. Documented and perfectly reproducible. - How would I manage my dotfiles? I use Org-babel for it and it makes my entire system immutable - is it better than Nix? I dunno, it just works and it's simple. - What would I use for file management? I just wrote a wrapper that uses rsync to move large files around, how would I ever do anything like this in other than Emacs? How would I mark all the files that are over 1GB, older than three months and match a given regexp? - In Emacs, I can move my cursor to a piece of plain text like "RFC 959", "SAC-28410", or "my-org/some-service#182" and immediately start reading shit - it intelligently recognizes that the first one is an RFC document, another is a Jira ticket and the third one is a Pull-request on GitHub. - I can type a single query and simultaneously search for it on Wikipedia, Google, YouTube, GitHub, Hacker News or my own browser history, and I wouldn't even know how to do that in something that's not Emacs. - In Emacs I can type a shell command and pipe results into a buffer, or pipe the content of a buffer to a shell command. - In Emacs, my color theme changes depending on time of the day, because Emacs has built-in lunar and solar calendars. - How would I read and manage my email in Helix? - How would I track time? Clock in/out of tasks, generate time reports, do pomodoros? - How would I search, browse and read Hacker News and Reddit? - How would I create presentations? - How would I test database queries? - How would I manage Docker containers? - How would I read man pages? - How do I translate text? - And how would I interact with LLMs? ... Nope, there's no "switching" for me. It's just not possible. My entire life is woven into this text-based operating system. My thoughts, my work, my communications, my entertainment - they all exist as interconnected plain text that I can grep, link, transform, and version control. Every keystroke I've memorized, every workflow I've perfected, every piece of data that references another - it would take years to rebuild this in whatever there might be, and I'd still be left with a pale imitation. Emacs isn't just where I edit text; it's where I live.

__MatrixMan__ 1y ago

The path pain sounds to me like a job for nix. If a dependency is not ready at hand, the fix should be a single code change in the project, not separate environment fixes for each dev.

_flux 1y ago

Btw, LLMs are actually quite helpful for configuring Emacs, in particular for creating custom functionality.. But yeah, I broke my home Emacs setup somehow so that rust-mode no longer works in some situations. I have my config in git, though, so maybe I'll figure it out! At least I've started migrating to use use-package for configuration, to bring some structure to the configuration. Zed does seem rather interesting, but I don't ever see it being as configurable/extensible at runtime as Emacs. I suppose one could always just implement such features into the Zed itself; I presume its code is not too indimidating, given it's a modern code base and not likely to break in unexpected ways.

fergie 1y ago

> Typescript If Typescript is a big part of what you need to deal with on a daily basis, then at some point it makes sense just to use VSCode. And BTW, thats totally by design and a part of Microsoft's developer aquisition strategy.

b5n 1y ago

`use-package` has pretty much simplified everything: ;; c (use-package c-mode :ensure nil :defer t :mode "\\.cu?\\'" :config (setq c-default-style "gnu" c-basic-offset 2) :hook ((c-mode . lsp) (c-mode . bmacs-ide)))

globular-toast 1y ago
Use-package can even install third party packages automatically. Definitely worth learning. I converted my .emacs a few years ago. I'm using borg[0] to install stuff though because I like git. [0] https://github.com/emacscollective/borg https://github.com/emacscollective/borg