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

Automatic line wrapping in the fullscreen editor #102

Open
patrikaxelsson opened this issue Sep 23, 2017 · 5 comments
Open

Automatic line wrapping in the fullscreen editor #102

patrikaxelsson opened this issue Sep 23, 2017 · 5 comments
Milestone

Comments

@patrikaxelsson
Copy link
Contributor

Scenario:
You are writing a message and decide you need to change something say ten lines up which makes the line longer.

Currently, you first have to manually wrap/break the actual line to be able to enter the text and then you have to manually wrap all the following lines if you want the message to look tidy.

It would be very nice if the editor did the wrapping for you instead and it would save a lot of time for people like me who have a hard time writing a text without multiple edits.

@punktniklas
Copy link
Owner

I agree that it's a bit annoying that you most of the time need to "make room" on a line before you can add text to it. But I'm not sure what the best solution would be. Should it push the rest of the text in front of it and re-wrapping all the lines below as needed? For the entire text or just the current paragraph. (However a paragraph is defined.)
What about when you delete text, should it do the reverse and always pull text up from lines below as room becomes available?

There are probably cases where this is not desireable. E.g. when editing code snippets.

@patrikaxelsson
Copy link
Contributor Author

I think it would be most useful if it pushed the text in front of it, rewrapping the text in the current paragraph to make room. And for delete it should pull up text from below lines of the current paragraph.

The definition of a paragraph would depend on how NiKom stores the text, I guess. For example if it was possible to define a paragraph as a very long line, ending with the first intentional line break, the definition would be clear.

If the definition what a paragraph is is not clear and the code has to make an educated guess, I can see that there could be occasional issues while editing code snippets. However, I think it would be a big convenience in most cases.

@adamel
Copy link
Contributor

adamel commented Oct 5, 2017

Reflow should definitely only happen within the current paragraph. I think paragraphs should be delimited by two newlines in a row, i.e.

This is the first paragraph.

This is the second paragraph.
Still still the second.

This is the third paragraph.

@punktniklas
Copy link
Owner

punktniklas commented Oct 6, 2017

NiKom doesn't currently really have a concept of a paragraph. Texts are just stored as individual lines. But an empty line is probably a good definition of where a new paragraph starts.

FidoNet texts, as a comparison, are stored as paragraphs and it's up to the reader to wrap the lines when displaying a text. When NiKom is saving a FidoNet text it ends the paragraph (i.e. puts a '\r') when there is a blank line, so that's the same. It also ends the paragraph when the next line starts with a white space. This trick is also used when quoting texts to prevent the "XY>" prefix of the quote to be re-wrapped.

I think the line-starts-with-whitespace rule is a good one too. I.e.

This is one
paragraph.
 But this is
a new paragraph.

@adamel
Copy link
Contributor

adamel commented Oct 6, 2017

Newline followed by whitespace (another newline, space, tab) may be a good general rule for paragraph separators. That will also prevent reflow into indented code lines.

@punktniklas punktniklas added this to the 2.4 milestone Dec 29, 2017
@punktniklas punktniklas modified the milestones: 2.4, 2.5 Jan 18, 2018
@punktniklas punktniklas modified the milestones: 2.5, Soonish Sep 30, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants