feature: Add option to specify initial number of lines in pyodide fence editors
Is your feature request related to a problem? Please describe.
If I want to add an editor with just three lines, I'd like to spare some vertical space. Currently it always has the same number of lines.
Describe the solution you'd like
Allow configuring number of lines in pyodide editors.
Describe alternatives you've considered
/
Additional context
/
I, too, like vertical space 💙
I have put a 25$ bounty on this issue over at gitpay.io.
Perhaps three options could be enabled?
- Default vertical size (9-lines?)
- Custom vertical size, user-defined
- As much vertical space as lines of code in the fence
Agree... Came here to ask if this was possible via any sort of config.
For me the issue is that larger blocks of code only show a few lines and have to be scrolled, so the suggested option 3 from @michaelweinold would be ideal.
Thanks for setting a bounty again @michaelweinold! And thanks @waimea-cpy for chiming in 🙂
Just to be transparent: features marked with the Insiders label are generally released to recurring sponsors first, as Insiders features. This sponsorware strategy is explained here: https://pawamoy.github.io/insiders/. Since this might not have been clear, I'm willing to release this feature to everyone immediately instead of releasing it to sponsors first. But if you plan on setting up bounties on other features marked with the Insiders label, please know I'll release them to sponsors first 🙂 The reason is that without Insiders features, I don't get recurring sponsors, and without recurring sponsors, my ability to work on all these open-source projects is impeded. I hope that makes sense 😄 Happy to get your thoughts on this and improve the process any way I can.
The initial idea was point 2, custom vertical size, user-defined, per code block. Point 1 is a good idea, but will need some more general thinking about how to provide default values (which are requested more and more). I'll open a new issue for that.
Point 3 is a good idea too, though needs some clarifications:
- is the height fixed (based on initial code), or does it update when new lines are added?
- do we set a maximum? I think we should. A 100+ line high editor doesn't sound like a good UX 🤔
- similarly, should it shrink back to a minimum height when removing lines?
Thank you for letting me know, @pawamoy.
is the height fixed (based on initial code), or does it update when new lines are added?
Could those be two options to be set in the mkdocs.yaml file?
do we set a maximum? I think we should. A 100+ line high editor doesn't sound like a good UX 🤔
Sounds sensible. I am not familiar with UX at all - but is there an option to set it to (for example) 50% of screen height (dynamically, depending on the user device)?
similarly, should it shrink back to a minimum height when removing lines?
If the dynamic height option is selected, I would agree.
OK so IIUC we could have the following options:
# somewhere in plugins or markdown_extensions
markdown-exec:
pyodide:
height: 10 # positive integer, or `auto` (based on initial code)
min_height: 5
max_height: 30
resize: true # resize when lines are added/removed, or false to keep fixed
The dynamic resizing feature will depend on Ace.js, probably, and my CSS skills (which are very low 😂). Hopefully LLMs will help if I struggle 🙂
The options look good - I would personally be very happy with those already.
@michaelweinold I've created a PR for this, can you please check if this looks good? #85
Thanks for the clarification re. the 'insiders' tag, and I hope you don't mind my chiming in!
When I was looking to see if I could implement this myself by modifying the settings for the Ace Editor instances, I came across this demo which shows off various sizing features, plus one that auto-resizes as the code is edited: https://ace.c9.io/demo/autoresize.html Thought it might be helpful...
@michaelweinold I've created a PR for this, can you please check if this looks good? https://github.com/pawamoy/markdown-exec/pull/85
Thank you for opening the PR. I will leave the assessment (and obviously merging) of this feature branch to the package maintainer @pawamoy. He is, I believe, also working on this feature and may therefore opt to go with his solution instead.
Thansk for the PR @amit-s19! Nice to see some activity on this issue/repo 😄
@waimea-cpy
and I hope you don't mind my chiming in!
I don't mind at all, I'm thankful for it! The link you shared will be super useful, thanks a lot!
@waimea-cpy @amit-s19 I'm curious, how did you end up on this particular issue?
@michaelweinold @amit-s19 fortunately I have not started working on this yet, so will review @amit-s19's work 🙂 But next times it would be best if you could sync with us first @amit-s19, to make sure different people do not start working on the same issue 😄
@pawamoy don't call me greedy but I came here from Gitpay 😅
@amit-s19 I thought it was a possibility 😄 And no worries, that's completely fine 🙂 I'm happy if you get the bounty!
I was looking to see if there were any open issues related to pyodide before I posted a feature request.... So I used the issue search, and this came up.
I can see that the bounty is still open on githpay. Is the PR merged?
No, I just closed it: https://github.com/pawamoy/markdown-exec/pull/85.
I have added a PR to solve this. @michaelweinold
@pawamoy can I work on this issue?
@jayantpranjal0 sure, but please read previous related PRs and comments: in short, don't use a fixed pixel value for line height, and instead try to use the Ace editor's minLines and maxLines options 🙂
@michaelweinold the feature was implemented and released 🙂 If you want to let us know how it goes.
```pyodide height="2-20"
print("initial code")
```
Fantastic - many thanks! I will happy try to add it to our documentation.