Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Request] Scroll behaviour #61

Open
zoedsoupe opened this issue Nov 24, 2023 · 7 comments
Open

[Request] Scroll behaviour #61

zoedsoupe opened this issue Nov 24, 2023 · 7 comments

Comments

@zoedsoupe
Copy link

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
Copy link
Owner

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
Copy link

arcstur commented Nov 25, 2023

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
Copy link
Owner

mfontanini commented Nov 26, 2023

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
Copy link
Owner

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
Copy link
Owner

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
Copy link

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

@DrunkenToast
Copy link
Contributor

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:

  • h/l: prev/next slide
  • j/k: down/up on current slide, if at at the start/end => prev/next slide

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 :) ).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants