Scrolling code blocks in the 'present' tool

[Jeff Mitchell]

Hello Gophers,

In the present tool, I want to include (via '.code', or ideally
'.play') some code blocks that aren't long, but are long enough (given
the font size) that they're running off the bottom of the slide.
They're not complex examples, but they're showing interface/struct
behavior so they have ended up rather vertically-oriented.

Is there a way to make either the included code field, or the slide
itself, become scrollable? I have tried making the block editable, but
this did not change the vertical behavior.

Apologies if this has been answered repeatedly but my Google-fu was
mostly turning up presentations about Go instead of about the tool.
This is using a version of the present tool and libraries from a few
days ago.

Thanks,
Jeff

[Dan Kortschak]

Can you not present the parts of the code over a couple of slides? I would be straightforward to add scrolling, but it would hurt presentations because its present would cause more people to use it - at the moment it is a constraint that keeps people honest.

[Jeff Mitchell]

I'm not sure if your response is meant to indicate that the present
tool can't do this, or that you don't think it should (but not
answering whether it can), but on the question of whether it should:

The argument that X shouldn't exist because if it did people would use
it ignores whether or not X is in fact _a good thing_ that would well
serve those people and their use cases.

I could stretch the code over a couple of slides, but while that might
keep me "honest" (against undefined criteria), it would drastically
reduce readability and understandability. In my case, I'm trying to
show an example of an interface. So:

- 1 line for the package (understood it could be removed from the
display, explained later)
- 1 line for the fmt import (same)
- 3 lines for a minimal interface with one function
- 2 lines for a struct with no members to implement the interface
- 3 lines for the implementation of the interface function
- 3 lines for a function that takes in the interface and does one
simple thing with it
- 3 lines for a main function to actually run it so when I hit the
Play button something happens

That's 16 lines without any blank lines, which are really necessary
for readability; add in the blank lines and you're at 25 and the
bottom line is falling off of the bottom edge of the slide. Add 6
lines (without blank lines) to show a minimal example of satisfying
multiple interfaces and you're missing the bottom quarter of the code.

It's very simple code showing a very simple concept. In this case, I
as the presenter feel that having more vertical space in one slide and
being able to scroll up and down provides a better way to walk through
the code than breaking it up into multiple slides where the previous
block(s) can't easily be referenced by the audience member trying to
follow along and needing to reference what was discussed a few moments
ago. It's far more jarring to go back and forth through multiple
slides than scroll down and up a couple of lines. I don't agree that
being able to scroll would hurt my presentation; the current behavior
is what's hurting it.

Additionally, I'd like the code to be editable and runnable via .play;
although in the first case omitting the top two lines (the package and
import) would allow the code to fit on one slide (but not for the
multi-interface example), it creates a degree of inconsistency if a
user wants to edit the code to run. For instance, if the user tries to
output via log instead, AFAICT this will cause a compiler error
because the fmt import will be unneeded but hidden from the edit box
so will not be able to be removed. So really only the "package main"
line can be safely hidden.

Thanks,
Jeff

[Dan Kortschak]

Absolutely it can be put in. It's just a matter of changing the js that is used in those elements (you can use a forked static directory to do this with the present code as it is.

I agree that this is a question of whether it should go in, but it it does not ignore whether it is a good thing - I don't think it would be a good thing in the general case. From your description I can see ways that an editable and runable version would work with the current implementation of present that would not ned scrolling.

Take a look at some of the present slide files from Andrew's, Francesc's and Sameer's talks where they essentially do code walks of reasonably complex applications. The clarity is not harmed by this absence - I think it is improved.

[Jeff Mitchell]

On Sat, Apr 23, 2016 at 10:31 PM, Dan Kortschak
<dan.ko...@adelaide.edu.au> wrote:
> Take a look at some of the present slide files from Andrew's, Francesc's and Sameer's talks where they essentially do code walks of reasonably complex applications. The clarity is not harmed by this absence - I think it is improved.

A code walk of a reasonably complex application I'd be happy to split.
In this case it's a very simple application showing a minimal viable
example that I would simply like to present in full on one slide, even
if it means scrolling a line or two. One nice thing about being a
presenter -- it's up to you to convey the information in the way that
you think will work best for your material and your soundtrack. If you
choose poorly, it's on you.