Hacker Newsnew | past | comments | ask | show | jobs | submit | ephimetheus's commentslogin

Didn’t they just drastically increase the price for non US citizens? I think it almost went up by 10x

I appreciate the opinion, but that precludes it from being used in repos that are not jj-first and happen to use submodules.


I got into jujutsu recently for the mega merge workflow.

The only thing I’m missing now is support for git submodules, especially when working with workspaces.

This requires me to keep using git worktrees with collocated jj in each of them, which is suboptimal.


Does jj’s own workspaces not help? I don’t use submodules so I don’t know.


Is selecting text in the PDF supported? I can’t get that to work in iOS Safari.


Text selection broken on Mac OS Safari as well. Worked in Chrome on Mac OS.


So far whenever jujutsu came up I didn’t find its features that convincing relative to git.

I have to say however that the mega merge workflow seems intriguing and might in fact be a solution to having to serialize my work like I do in git for now.

I think I’ll look into that.


What always disqualifies these projects for me is the fact that they need to use a headless browser to export to PDF. PDF export is the primary feature I need from these, and it’s a shame the export mechanism is still this slow and unreliable.


I found with that revealjs slides can be exported to pdf via their tools menu, and print it. It worked on Firefox. True that it’s a manual step. But no need to rely on a headless browser as soon as you don’t want to script it.

https://quarto.org/docs/presentations/revealjs/presenting.ht...


Yea.

Having intentionally stayed away from going down the PDF rabbit hole, but now confronting it again recently … what’s the deal with how sparsely populated the space is with solid and (relatively) light weight rendering solutions/back-ends?

Am I missing something or am I right in thinking that there’s a kinda pandoc/FFmpeg shaped hole in the document tooling space that no one wants to (or can’t) fill? Where tex and chrome based solutions are arguably just too heavy for a number of needs but all we really have?


The problem is that Markdown is not really a markup language, since it only defines the content and structure, but has no way to specify how it will be displayed. To go from content (Markdown) to rendered presentation (PDF) you need a proper markup languaje (HTML/Tex) to be able to specify its layout.


The reason it's hard to render straight from Markdown isn't because it's not a markup language like html - because Markdown is just syntactic sugar for a subset of html. Because of that, it's usually easier to just use the abundant html tooling to render it. The problem is that html needs CSS to render nicely - and any tool used to render CSS+HTML is almost by definition a browser engine.


Exactly, I would've hoped someone could come up with a way to render markdown directly into a PDF, without roundtripping via tex and having to handhold the styling process in the way that's required now.


This is why I still use beamer and pandoc.


This is a fantastic analogy!


Which package do you mean? Last time I tried this it was kind of clunky.


It's just called "markdown". I used it to make this template a few years ago:

https://gist.github.com/te-lang-wakker/b401bcf7f05658c624fab...

Only problem was that hyperlinks are converted into footnotes, but I'd be surprised if you can't hack your way around that.


For experiment data, there is a layer on top of all of this that distributes datasets across the computing grid. That system has a way to handle replicate at the dataset level.


Paperless-ngx is fantastic! I’ve been running it for a while and it works great!

I wrote an iOS [1] app to connect to you instance and it’s open source [2].

[1] https://apps.apple.com/de/app/swift-paperless/id6448698521

[2] https://github.com/paulgessinger/swift-paperless


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: