pdf-tools VS lorri

Also https://github.com/politza/pdf-tools/issues/706

;; Fix blurry PDFs on MacOS. ;; From https://github.com/politza/pdf-tools/issues/51 (setq pdf-view-use-scaling t)

First things first, install pdf-tools, a great Emacs package for viewing pdfs. The default pdf viewer Docview is very limited so you should definitely get this package.

nov.el is pretty nice, although pdf-tools makes PDFs tolerable.

It looks enjoy pdf-tools got a new maintainer and he already changed the the melpa ⠀recipe, so you can get it via the package manager. I think this is a good development. My impression is, that he is new as an Emacs package maintainer, so please be kind and supportive, so he will stay on it for a while. :)

I have been using emacs pdf-tools lately and really enjoying it https://github.com/politza/pdf-tools

View, annotate PDFs and more with Emac's pdf-tools. There is also the built-in doc-view.

[pdf-tools](https://github.com/politza/pdf-tools) will let you do that.

I tried setting (add-hook 'pdf-view-mode-hook (lambda() (linum-mode -1))), which I found here. But it doesn't seem to do anything.

doc-view.el aside, there's https://github.com/politza/pdf-tools which may have its own set of issues.

lorri

And how does niv compare to https://github.com/target/lorri

Yes, you can "hold on", it's called gcroots. There's lorri which you can also use to defer the tediousness of managing the gcroots to a daemon.

Not that I know of but if you are having trouble with rebuilding and running out of memory, maybe the solution would be to cache the builds locally? You could use lorri to cache your development builds (https://github.com/target/lorri).

> Using a special command (nix-shell) whenever I needed to do development things (e.g. Rust builds) was not my idea of fun.

Funny you should mention that, because that's exactly what got me using Nix everywhere :). I've always hated installing tools and libraries globally—what if I need a different version for a future project?—so I like tools that sandbox as much as possible like virtualenv, cargo, cabal... etc. But these tools are all language-specific and have their own limitations (especially around native libraries and dependencies written in other languages).

nix-shell gives me the equivalent of virtualenv that works for everything. I can have a single sandboxed environment even if my project uses a bunch of different languages and I can manage everything in a reproducible, low-overhead fashion. No more worrying about making a mess by installing tools or packages globally.

Then, once I got really used to that, I spent some time setting up direnv[1] and lorri[2]—both of which are themselves managed with Nix, of course!—so that my environment gets automatically configured as soon as I enter a project directory without needing to call nix-shell explicitly. To be honest, the experience is still a bit rough, but it works well enough day-to-day that I have my reproducible sandbox cake and eat it in an mostly frictionless way too :).

[1]: https://direnv.net/

[2]: https://github.com/target/lorri