-
Notifications
You must be signed in to change notification settings - Fork 38
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
Comments
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. |
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. |
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
That is already implemented :). |
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? |
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. |
I'd also like to be able to scroll the command output pane(?). |
As for the API, ctrl u/d make sense for me but I wouldn't say they're as discoverable.
So for most people j/k would work as usual still. Some tools like reveal.js have bidirectional slides. Sounds a bit complicated to implement but it would fix an issue and create a cool feature in one go. |
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.
The text was updated successfully, but these errors were encountered: