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

make rendered mode easier to use in a shell environment #1823

Closed
dankamongmen opened this issue Jun 24, 2021 · 23 comments · Fixed by #1825
Closed

make rendered mode easier to use in a shell environment #1823

dankamongmen opened this issue Jun 24, 2021 · 23 comments · Fixed by #1825
Assignees
Labels
documentation Improvements or additions to documentation enhancement New feature or request haileris kallisti! hail eris, all hail discordia
Milestone

Comments

@dankamongmen
Copy link
Owner

dankamongmen commented Jun 24, 2021

direct mode and rendered mode are at heart differentiated by whether output is generated outside of notcurses.

with that said, we could do a lot to make rendered mode more useful in a traditional scrolling shell environment. i'm basically thinking some combination of:

  • don't use the alternate screen
  • don't set a base cell that draws over all the screen (don't lose preexisting text above us)
  • initialize the virtual cursor on the standard plane to wherever it was at program start
  • set the standard plane to scroll
  • at exit, cursor is placed after the last output
  • [profit]

i don't think this needs to be a notcurses_core_init() option, and probably shouldn't, but it ought at least be tested and documented, and some examples written, and rough spots identified and ironed out.

@dankamongmen dankamongmen added documentation Improvements or additions to documentation enhancement New feature or request haileris kallisti! hail eris, all hail discordia labels Jun 24, 2021
@dankamongmen dankamongmen added this to the 3.0.0 milestone Jun 24, 2021
@dankamongmen dankamongmen self-assigned this Jun 24, 2021
@dankamongmen
Copy link
Owner Author

maybe plot this out with the work i'm doing on notcurses-info. i'd like to generate all that output in a notcurses rendered mode context, but have it usable in the shell.

@dankamongmen
Copy link
Owner Author

i think maybe NCOPTION_PRESERVE_CURSOR would be a satisfactory solution to cursor placement on both startup and shutdown, and is the right way to do that. the only time we don't know the cursor location in rendered mode is startup, and this closes that hole (when we want to) without a new genrally-useless function.

@dankamongmen
Copy link
Owner Author

the banners need be integrated into this. sample the cursor after the intro banner is printed.

@dankamongmen
Copy link
Owner Author

so what happens when we, say, create an ncselector in this configuration? i think we'd want it displayed, causing scrolling if necessary. but we need it to stay coherent and self-contained. well, that points to one and only one solution: a plane bound to a scrolling plane is affected by the the latter's virtual line number. exciting! but dangerous!

@dankamongmen
Copy link
Owner Author

But that brings up a good point--for this to work, scrolling on the standard plane has to be paired with an actual scroll of the visible area.

@dankamongmen
Copy link
Owner Author

Looks like you can already set the standard plane's scrolling mode, good good.

dankamongmen added a commit that referenced this issue Jun 24, 2021

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
@dankamongmen
Copy link
Owner Author

ok, getting there! we have the option implemented. we need to check it on shutdown, and if it's set, place the cursor at the logical row based on the standard plane. we need bump the cursor down if we print init banners. and i think that's it!

@dankamongmen
Copy link
Owner Author

hot damn looks to be working perfectly

2021-06-24-183955_1072x1417_scrot

this is big!

@dankamongmen
Copy link
Owner Author

@joseluis , you'll want to be aware of this, i think

@dankamongmen
Copy link
Owner Author

only problem left is that we always put the cursor at the bottom at the end of rendered mode, which fucks us up when we're not starting at the bottom. need to check for NCOPTIONS_PRESERVE_CURSOR there.

@dankamongmen
Copy link
Owner Author

oh, we probably ought use the notcurses->cursor_{y,x} instead of inventing new ones down in the termdesc stack.

@dankamongmen
Copy link
Owner Author

got that handled. only remaining issue is accounting for init banner relative to initial cursor placement.

@dankamongmen
Copy link
Owner Author

2021-06-24-185402_1072x1417_scrot

yes!

@dankamongmen
Copy link
Owner Author

gotta knock out some unit test breakage, and test te hell out of this, but sweet!

@joseluis
Copy link
Collaborator

@dankamongmen is this only going to work with the standard plane?

I'm trying to think of the best way to use this with the hi-lvl rust wrappers that don't have the concept of the standard plane...

@dankamongmen
Copy link
Owner Author

@dankamongmen is this only going to work with the standard plane?
I'm trying to think of the best way to use this with the hi-lvl rust wrappers that don't have the concept of the standard plane...

hrmmmmmmmmm. so this feature isn't all the way there yet -- i haven't yet developed anything very serious with it (just notcurses-info), and i'm sure it might change a little. for one, i haven't yet locked down how extra planes will interact, just some vague thoughts about "planes bound to a scolling plane ought scroll". but i think the latter might be enough -- need to experiment.

so right now, i'd think that via whatever mechanism you allow this mode to be entered, it needs to internally mark the standard plane as scrolling, and do the other steps outlined above. those needn't be exposed to the user. and what i think is going to happen is that when you have a plane bound to a scrolling standard plane, and that former plane goes beyond the bottom of the visual area at render time, scrolling will encompass said plane, not just the standard plane. so it all falls out. i just need to make sure that works properly. does that make any sense?

@dankamongmen
Copy link
Owner Author

2021-06-26-180335_1072x1417_scrot

@joseluis
Copy link
Collaborator

yes it makes sense.

So I guess I could internally get the cursor position from the standard plane, duplicate it, move it to its own pile, enable scrolling, and work over it. right?

@joseluis
Copy link
Collaborator

BTW the output of notcurses-info appears for me like this:
image

I'm using --version: wezterm 20210618-221225-e3fdef7f.

Before the colors commits it was like this:
image

@dankamongmen
Copy link
Owner Author

BTW the output of notcurses-info appears for me like this:
I'm using --version: wezterm 20210618-221225-e3fdef7f.

sacre bleu! sounds like i need dig out the laptop. thanks for the heads-up!

@dankamongmen
Copy link
Owner Author

So I guess I could internally get the cursor position from the standard plane, duplicate it, move it to its own pile, enable scrolling, and work over it. right?

hrmmmm i see a problem here. you presumably would want to be writing arbitrarily much data to this secondary plane, and having the screen scroll with it. so normally you could just set that plane scrolling, and it would do exactly that -- but it wouldn't interact with preexisting text, etc. because we need to truly scroll the screen, and normally we just logically scroll within the plane. so no, that wouldn't work, at least the way i'm seeing this working. hrmm.

it would work if you moved the secondary plane down a row each time you wanted a true screen scroll, but that sounds difficult to know -- i'm trying to make this largely no-effort for the user. hrmmmmmmmmmmmm.

@joseluis
Copy link
Collaborator

joseluis commented Jul 6, 2021

it would work if you moved the secondary plane down a row each time you wanted a true screen scroll, but that sounds difficult to know -- i'm trying to make this largely no-effort for the user. hrmmmmmmmmmmmm.

@dankamongmen is there a specific thread I should be monitoring for this topic?

@dankamongmen
Copy link
Owner Author

@dankamongmen is there a specific thread I should be monitoring for this topic?

#1883 is probably where remaining design will be going on, feel encouraged to chime in

@dankamongmen dankamongmen modified the milestones: 3.0.0, 2.4.0 Aug 24, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation enhancement New feature or request haileris kallisti! hail eris, all hail discordia
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants