From mboxrd@z Thu Jan 1 00:00:00 1970 From: john at keeping.me.uk (John Keeping) Date: Thu, 28 Jun 2018 09:28:53 +0100 Subject: [PATCH v4 00/16] Render READMEs inline in tree view In-Reply-To: References: <152885510454.7253.3542488576272033383.stgit@mail.warmcat.com> <152948941145.29466.10223016890282865269.stgit@mail.warmcat.com> <20180627195143.GP6584@john.keeping.me.uk> Message-ID: <20180628082853.GT6584@john.keeping.me.uk> On Thu, Jun 28, 2018 at 01:22:34AM +0200, Jason A. Donenfeld wrote: > Hey John, > > Thanks tons for your input, as always. > > On Wed, Jun 27, 2018 at 9:51 PM John Keeping wrote: > > - It is desirable to have the existing source view in addition to the > > rendered content, preferably with syntax highlighting via the source > > filter; for example Markdown, HTML or SVG can be sensibly viewed in > > both ways > > Got it, so this is the big kicker. Essentially we need a nice way for > the render filter to fallback to the source filter, as you said, with > then a `&source=1` override (and link) if a user explicitly wants the > source, in order to have both views. That seems like a good idea. This > would solve the issue with line numbers as well. > > But how to implement this efficiently? With the lua filters, it really > doesn't matter, but with the exec filters, we perhaps incur the > penalty of exec'ing twice. Maybe that's acceptable, though. The other > approach would be for the source-filter to print its own line numbers, > and so the render filter itself could just fall back to calling > internally the source filter, and perhaps even indicating what it did > via the exit code, but I think I like this idea less. A third option > is to do this selection entirely within cgit via mimetype/fileext > selection, while I was initially hesitant about this, maybe this is an > okay approach after all. > > Assuming we go with the first approach -- of the renderer fallback -- > we would then have: > > - render-filter (nee about-filter) > - source-filter > > Then, if render-filter returns an exit code, cgit assumes we're in > source filter mode. Yeah, I don't think there's any way to avoid exec'ing twice in source view - we need to run the source filter for output and we need the render filter to tell us whether we should output a link to the rendered content. If we've been asked to render and can render, then the render filter can just run and exit normally, but if it wants to say "unsupported" then we have to exec the source filter as well. There is an alternative if we're willing to move away from simple filters and introduce a new filter type which provides headers before its output, for example: Mode: source Supported-modes: source, render I'm not convinced that this is a good thing, but the only other way to avoid exec'ing two processes is to configure in CGit. My hesitation with that is that the only way we have to do that is via file extensions and I don't really like tying everything to a file extension ("README" is a perfectly fine filename and we should be able to display that as rendered Asciidoc if that's what it is). > > - For some content types, the easiest way to render it is to simply > > include the file with an iframe; this is the case for images and PDFs > > at the moment > > > > Now, if the render filter can say "I don't support this" and can do so > > reasonably efficiently, we can use that to control whether render mode > > is enabled and whether we use the "fallback to mimetype" to include an > > iframe. Or with the asset path extension to the filter arguments, we > > could have the filter generate the