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

auto-justify body text #14

Closed
tbnorth opened this issue Mar 10, 2014 · 10 comments
Closed

auto-justify body text #14

tbnorth opened this issue Mar 10, 2014 · 10 comments
Assignees
Milestone

Comments

@tbnorth
Copy link
Contributor

tbnorth commented Mar 10, 2014

Leo can wrap or not wrap body text, but this is just a visual rendering relative to the body editor window size. It would be nice if Leo could also automatically justify (insert newlines) in text as you type.

@tpgit
Copy link

tpgit commented Apr 14, 2014

+1 for this feature.

@edreamleo
Copy link
Member

There are several ways Leo could insert newlines. After a specified column, or when the line would exceed the width of the body pane. On first thought, at a specified column seems more useful.

Comments, please.

@edreamleo edreamleo added this to the 5.4 milestone Apr 27, 2016
@calvertvl
Copy link

Nearly all other text editors--if they offer this feature--use the specified column method, as far as I am aware. Normally it is described as wrap or rewrap, which comes into conflict with the @wrap/@nowrap directives in Leo.

I think terminology may be the biggest issue here.

For clarity, when I refer to wrap/rewrap below I am describing the insertion of newlines, or removal and re-insertion to change the length of the lines. I think of justify as a purely visual (formatting) option (e.g. stretching character width so left and right appear to end at the same place) in the same general category as the existing @wrap behavior (known in some cases as word wrap).

Providing a rewrap-text command and using a specified number of columns to wrap seems to be much more flexible than only wrapping at the width of the body pane. The behavior is also consistent if the user switches between different screen resolutions that would affect maximum visible line length (e.g. laptop with external display).

In other editors, the rewrap-text command generally does the following:

  • Two consecutive newlines are treated as a paragraph break.
  • The operation is executed for selected text or current paragraph (I'd suggest selected text or current node for Leo).
  • The implementation often retrieves number of columns (N) from clipboard, using global config as a fallback (for Leo, perhaps a new node-body directive similar to @pagewidth?).
  • Upon execution: rewrap each paragraph to N columns (for Leo, use Python library textwrap.TextWrapper for each paragraph?)

Obviously, the above doesn't exactly work well for code, but it is ideal for documentation or other prose. To work for code, it may only be necessary to change the definition of the paragraph break, but I'm not sure...I usually use language-aware code reformatting programs in that case, and they usually offer similar max-line-length options when appropriate.

@edreamleo edreamleo modified the milestone: 5.4 Sep 21, 2016
edreamleo added a commit that referenced this issue Sep 25, 2016
When @int autojustify > 0, Leo will insert a newline before the present word if it would exceed the given column number.
Uses the auto indent feature to add indentation.
@edreamleo
Copy link
Member

Rev 8ae11ae adds experimental support for auto indentation for programming. The only new code is in the newPlainChar method in leoEditCommands.py. Let me know what you think.

When the new setting @int autojustify is greater than zero, Leo will insert a newline before the present word if it would exceed the given column number. A newline is added only if the user is typing at the end of a line.

The code uses the auto indent feature to add indentation.

Important: Leo's reformat-paragraph and unformat-paragraph commands use whatever @pagewidth setting is in effect, so imo the only thing that is needed is to add hard newlines when programming.

I'll close this now. Please reopen if there are problems.

@edreamleo
Copy link
Member

I already don't like this feature. It would take AI to know how to split lines properly.

For example, the user will want to insert comment delims when extending comments.

@tbnorth
Copy link
Contributor Author

tbnorth commented Sep 25, 2016

My guess is the OP wanted this for prose, not code. I'd like it for prose too - my experiments weren't very successful when I tried it though (some time ago). It should certainly be possible.

@edreamleo
Copy link
Member

On Sun, Sep 25, 2016 at 7:44 AM, Terry Brown notifications@github.com
wrote:

My guess is the OP wanted this for prose, not code. I'd like it for prose
too - my experiments weren't very successful when I tried it though (some
time ago). It should certainly be possible.

​Have you tried reformat-paragraph and unformat-paragraph? I use them all
the time.

EKR

@tbnorth
Copy link
Contributor Author

tbnorth commented Sep 26, 2016

Yes but that's intrusive, having to hit something at the end of every para., other than return, to type fixed width text, or letting the window wrapping handle it until you're done typing, then go back and reformat all the paras.

tbnorth added a commit that referenced this issue Jan 9, 2017
updates 8ae11ae which closed #14

Leo build: 20170109160438
@tbnorth tbnorth self-assigned this Jan 9, 2017
@tbnorth
Copy link
Contributor Author

tbnorth commented Jan 9, 2017

To finish the discussion above, this actually works well for prose - I'd forgotten it was done already. So I think it's a valuable feature. It should probably get a toggle command though, so you can toggle it on and off, and I guess a setting to determine if it's on by default.

@tbnorth tbnorth reopened this Jan 9, 2017
@tbnorth
Copy link
Contributor Author

tbnorth commented Jan 12, 2017

Done in 05df9a

@tbnorth tbnorth closed this as completed Jan 12, 2017
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

4 participants