Editing Help:Text editor support (section)

==== Line and paragraph breaking ====
Lynx built-in hard limits line length. In version 2.8.3, find this line in <code>LYGlobalDefs.h</code>:
: #define MAX_LINE 1024
This can be modified to a longer length (e.g. 8192) and recompiled. If you are unable to recompile Lynx, the following are workaround suggestions.

Lynx is prone to breaking lines longer than 1023 characters: When this happens, a large paragraph with lots of reference data may easily become broken, and articles saved like that may take at best a slightly inconsistent appearance; at worst, complex articles might lose their structure.

The character length limit is dependent on maximum buffer length set for a line, the default size of which is 1023 characters; this behaviour can be observed when moving the cursor to a text area line exceeding the limit, whereby Lynx will issue an alert: "Form field value exceeds buffer length! Trim the tail."

Even if a paragraph of article text on its face is not very long, it may still contain multiple references along with extensive amounts of related code and data for them, which makes an actual paragraph in article code much longer, and in some cases, well beyond the length of the 1023-character limit. When a line of text exceeds that limit and a text file is sent back to the Lynx textarea, Lynx will yield an error message: "Alert! Very long lines have been wrapped!". In such a case it's best not to save article content before such issues have been mitigated.

Therefore, article editors should be careful to follow the character length of longer lines, and where (usually) possible, insert strategic linebreaks with carriage returns (not HTML <CODE>&lt;BR&gt;</CODE> tags): Advanced text editors, like vi or VIM, do typically show cursor position within a line in their status areas, and thus allow to gauge line length when the cursor is at the end of a line.

In a longer paragraph of article code containing references, single linebreaks can be inserted within reference code, so long as parameter values themselves are not broken.
*Some Wikipedia editors hold the practice of entering a linebreak before every reference parameter (as can be seen in examples of [[Wikipedia:Citation templates|Citation templates]]; Whether this is a good practice within text, is subject to debate);
*Other editors choose not to interfere with a paragraph's visual consistency and enter a linebreak before a very long URL, one that is longer than the visual line in a terminal window, which is usually the length of 80 characters. If the situation in text necessitates, a linebreak can also be inserted before other parameters.

Because URLs are typically long, placing these on a new line is handy for comparing article editions, as some textually non-breaking code prepended and/or appended to a URL may lie outside a comparison column's viewport, and this may hinder in discovery of changes made to an article.

If a paragraph line is near the limit or exceeds it by just a few characters, then article editors can choose to optimize code or text:
*By removing superfluous spaces:
**the best practice with extensive template data (such as references) is to only separate the last character of a previous parameter value and the marker pipe of next parameter's name;
**In plain text after a sentence-ending period, some article writers add two spaces instead of one, but browsers ignore this.
*By refactoring template data into a shorter format: <CODE>date=26&nbsp;February&nbsp;2011</CODE> can be replaced with <CODE>date=2011-02-26</CODE> &mdash;&nbsp;Users with their own date preferences should then see dates in their favoured format when logged in;
*By rewording a line without affecting the nature of the text within.
*The above applies, even if a paragraph line does not contain breakable code.

If a line paragraph still exceeds the 1023-character limit, but does not contain any reference code (or any other wikicode that would work with linebreaks), then users should consider logically breaking that paragraph into two for better legibility.