Preformatted blocks should not be wrapped #164

Open
opened 2020-05-25 17:01:37 +00:00 by makeworld · 5 comments

The recent Bombadillo update wraps text at 100 columns, which is really nice for reading. But it also wraps preformatted blocks of text, which should not be happening, as lines breaks are often important in those kinds of blocks. At worst, preformatted text should be wrapped at the last column of the terminal, but the best option would be implementing side scrolling for those blocks. Maybe it makes sense to implement the former as a quick fix, and then work on the latter.

The recent Bombadillo update wraps text at 100 columns, which is really nice for reading. But it also wraps preformatted blocks of text, which should not be happening, as lines breaks are often important in those kinds of blocks. At worst, preformatted text should be wrapped at the last column of the terminal, but the best option would be implementing side scrolling for those blocks. Maybe it makes sense to implement the former as a quick fix, and then work on the latter.
sloum added the
rendering
gemini
enhancement
labels 2020-05-25 17:40:06 +00:00
Owner

It is not possible, within the current way bombadillo works, to treat the wrap width for any line differently than any other line. If it would be better to remove the 100 character wrap we can do that, but I think that user experience would suffer.

I have no interest in incorporating horizontal scroll into Bombadillo and would reject a plan to do so. I genuinely feel that wrapping is better than truncating, and the spec seems to agree there, stating: graphical clients should implement horizonatl scrolling in preference to wrapping. Implying that terminal client may wrap. 100 characters seems a reasonably appropriate wrap width for all content and creates a uniform experience (I had requests to wrap at 60 or 80 columns). Given that the preformatted blocks would wrap at the terminal width regardless, the better way to think of the columns is that there is a virtual window inside of the terminal (or in web parlance: I have created a div with a set width and overflow set to wrap).

This may eventually be able to be worked into v3.0.0, where a lot of big changes to core components will be made. I see that being at least 6 months or a year out though. In the interim I feel like there are limits in place for what can be accomplished without major re-writes.

I have more thoughts on this and have spent the last 20 minutes writing and re-writing stuff here, but think I will leave it with what was written above for a bit and then come back to this with further thoughts later.

It is not possible, within the current way bombadillo works, to treat the wrap width for any line differently than any other line. If it would be better to remove the 100 character wrap we can do that, but I think that user experience would suffer. I have no interest in incorporating horizontal scroll into Bombadillo and would reject a plan to do so. I genuinely feel that wrapping is better than truncating, and the spec seems to agree there, stating: graphical clients should implement horizonatl scrolling in preference to wrapping. Implying that terminal client _may_ wrap. 100 characters seems a reasonably appropriate wrap width for all content and creates a uniform experience (I had requests to wrap at 60 or 80 columns). Given that the preformatted blocks would wrap at the terminal width regardless, the better way to think of the columns is that there is a virtual window inside of the terminal (or in web parlance: I have created a div with a set width and overflow set to wrap). This may eventually be able to be worked into v3.0.0, where a lot of big changes to core components will be made. I see that being at least 6 months or a year out though. In the interim I feel like there are limits in place for what can be accomplished without major re-writes. I have more thoughts on this and have spent the last 20 minutes writing and re-writing stuff here, but think I will leave it with what was written above for a bit and then come back to this with further thoughts later.
Author

I have no interest in incorporating horizontal scroll into Bombadillo and would reject a plan to do so.

I understand this, especially for a terminal client.

I feel like the best way forward, if you agree with my premise that wrapping preformatted blocks should be avoided, would be to change the way the wrapping works so that it is possible to not wrap certain lines. But I understand that that might be difficult, no worries. The way it works now is great, and much better than without the wrapping like it was before.

Thanks for the reply!

> I have no interest in incorporating horizontal scroll into Bombadillo and would reject a plan to do so. I understand this, especially for a terminal client. I feel like the best way forward, if you agree with my premise that wrapping preformatted blocks should be avoided, would be to change the way the wrapping works so that it is possible to not wrap certain lines. But I understand that that might be difficult, no worries. The way it works now is great, and much better than without the wrapping like it was before. Thanks for the reply!
Owner

I am ok with the idea of wrapping at maximum 100 columns for all text except preformatted lines, which would (by necessity) wrap at the edge of the terminal.

With all of the activity lately, and potentially more pressing issues, I dont have the bandwidth to look into a fix for this currently. I do not believe the current rendering and wrapping flow will be able to support this, but I am open tot he concept of it. I'll add a help wanted tag since this is something I will not get to in the nearterm, but may return to once the initial rush of gemini updates calms a bit. I am pretty frazzled from all the work on it lately and am nearing the point where I'll need to take a break for a bit if I continue at this pace.

I am ok with the idea of wrapping at maximum 100 columns for all text except preformatted lines, which would (by necessity) wrap at the edge of the terminal. With all of the activity lately, and potentially more pressing issues, I dont have the bandwidth to look into a fix for this currently. I do not believe the current rendering and wrapping flow will be able to support this, but I am open tot he concept of it. I'll add a help wanted tag since this is something I will not get to in the nearterm, but may return to once the initial rush of gemini updates calms a bit. I am pretty frazzled from all the work on it lately and am nearing the point where I'll need to take a break for a bit if I continue at this pace.
sloum added the
help wanted
label 2020-05-25 17:56:40 +00:00
Author

Thanks for keeping this issue open, no worries. I hope all my issues aren't contributing to you being frazzled too much, let me know. Take care!

Thanks for keeping this issue open, no worries. I hope all my issues aren't contributing to you being frazzled too much, let me know. Take care!
Owner

A bit, but not in a way that should prevent you from submitting issues. You have brought up good stuff that needs to be tended to, some of it urgently. It just happens that a few of the items really would take a rebuild of much of the application since it wasn't originally built to accomodate those features.

More and more we are running up against that kind of situation. When it was just me and one or two other people using the application it was easier to just make decisions based on my preferences. However, with the influx of other people I am having to make choices that affect those people... which can lead to a lot of work that I wouldnt do if I was still just writing it for me and a few others (where I could just shrug and say, meh, it is odd but it gets the job done well enough).

I guess what I am saying is that I think it is good to aspire to continued improvements in usability. I need to learn to balance that with my available time and try to be more flexible about things moving in directions that just arent that important to me personally, but are important to other people. Again, thank you very much (truly) for your help and for bringing these things up!

A bit, but not in a way that should prevent you from submitting issues. You have brought up good stuff that needs to be tended to, some of it urgently. It just happens that a few of the items really would take a rebuild of much of the application since it wasn't originally built to accomodate those features. More and more we are running up against that kind of situation. When it was just me and one or two other people using the application it was easier to just make decisions based on my preferences. However, with the influx of other people I am having to make choices that affect those people... which can lead to a lot of work that I wouldnt do if I was still just writing it for me and a few others (where I could just shrug and say, meh, it is odd but it gets the job done well enough). I guess what I am saying is that I think it is good to aspire to continued improvements in usability. I need to learn to balance that with my available time and try to be more flexible about things moving in directions that just arent that important to me personally, but _are_ important to other people. Again, thank you very much (truly) for your help and for bringing these things up!
sloum added this to the 3.0.0 milestone 2020-06-13 22:22:20 +00:00
sloum added the
non-urgent
label 2020-06-15 06:26:06 +00:00
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: sloum/bombadillo#164
No description provided.