search

mfontanini / presenterm

A markdown terminal slideshow tool
https://mfontanini.github.io/presenterm/
BSD 2-Clause "Simplified" License
1.2k stars 29 forks source link

[Request] Scroll behaviour #61

Open zoedsoupe opened 10 months ago

zoedsoupe commented 10 months ago

Sometimes, mostly when writing code blocks, it overflows the terminal/screen vertical viewport. I would be awesome the ability to “scroll down” to a slide content, if it is even possible.

For now the solution is to break the code block into smaller ones to fit the screen size, on different sldies.

mfontanini commented 10 months ago

I think typically presentation tools don't allow scrolling and you need to adjust the content to fit on the slide. I'd even say if your code is so long if doesn't fit into a single slide then you probably should split it.

I'll look into this tho. The terminal does support scrolling so it would be a matter of hooking that into a hotkey and seeing what breaks.

arcstur commented 10 months ago

I think your first point makes a lot of sense. However, there's something different about using these kind of tools of slides on the terminal. It's very hard to predict the amount of space required. I can increase/decrease the font at my wish, and also the screen size. So I have to prepare my slides with a specific screen size and font size/zoom in mind, and if something changes it can break visibility.

Thinking about this, I think it would make sense to scroll (and maybe hook that into J/K up/down?) the screen.

However, if some kind of PDF or image export in the future is on your mind, users who use it with scrolling in mind would make their content do not fit a PDF page. Maybe that's a tradeoff, in this case, that is okay. Don't know, just thinking out loud here, haha.

mfontanini commented 10 months ago

So I have to prepare my slides with a specific screen size and font size/zoom in mind, and if something changes it can break visibility.

Yeah, my thoughts on this is you should probably develop the slides in a specific terminal size and then use that same terminal size when displaying it. e.g. have an alias like alias presenterm-terminal=your-terminal-emulator --width x --height y. I'll see how this works, in theory it should be simple but I need to see how images look like with scrolling + the footer is probably by default going to be "scrollable" too so unless I do something about it, you will only see the footer once you scroll to the bottom.

However, if some kind of PDF or image export in the future is on your mind,

That is already implemented :).

mfontanini commented 10 months ago

in theory it should be simple

Famous last words. The scrolling API in the terminal just moves the visible text up/down so it won't show the text that's off-screen. This requires tracking whether the text overflowed and doing the translation ourselves which is a lot more involved.

As for API, any concerns with using a separate set of keys for this? hjkl are already used to move to the next/previous slides so I was thinking something else. Maybe C-d and C-u? Thoughts?

mfontanini commented 7 months ago

I just created #209 which sort of tackles this problem from another angle. Rather than letting you scroll, that change lets you detect that the presentation overflows the terminal screen. This lets you at least figure out whether there's overflows without having to scroll through every slide every time you make a change/start the app.

bracketttc commented 3 months ago

I'd also like to be able to scroll the command output pane(?).

DrunkenToast commented 1 month ago

As for API, any concerns with using a separate set of keys for this? hjkl are already used to move to the next/previous slides so I was thinking something else. Maybe C-d and C-u? Thoughts?

As for the API, ctrl u/d make sense for me but I wouldn't say they're as discoverable. I think it would make sense for something like this as well:

So for most people j/k would work as usual still.

Some tools like reveal.js have bidirectional slides. Perhaps an idea for this case would be to have overflowed text become a new vertical slide as well as having a <!-- break --> command to manually split a slide into vertical one.

Sounds a bit complicated to implement but it would fix an issue and create a cool feature in one go. Issues I see currently would be the output pane and visualization of vertical slides (currently there is only a bar, and we don't have fancy animations :) ).