Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Linux support is broken
See original GitHub issueKitty works perfectly well under linux, so it makes sense for this project to also support linux. If I open a ~8 page pdf, my terminal goes blank, the termpdf process uses about 6GB of ram and 100% of a CPU core, while just showing a blank screen. Opening a big pdf file almost halted my computer, I think because it used close to 9GB of ram.
Not really a helpful issue description, but I will try to investigate why this happens when I have a little more time. Given that you probably are on macOS, you might want to install a VM to do some simple testing one day. I’m using kitty from git btw, on a fully updated Arch linux system, with the newest PyMuPDF.
Great initiative btw! Folllowing emacs pdf-tools in terms of features is a nice idea.
Issue Analytics
- State:
- Created 4 years ago
- Reactions:1
- Comments:12 (12 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
I don’t think so really, just switched to bash whenever I wanted to use this. However, I can’t test this now, because for some reason libmupdf (need for the python bindings) seems broken on Arch Linux.
The problem seems to be that fish shell screws around with
TIOCGWINSZ. If runtermpdf.pyin a fresh bash instance it works fine.