Re: [Help-nano] Soft-Wrap and Show-Codes?

[Dan Mahoney, System Admin]

On Fri, 6 Oct 2006, David Lawrence Ramsey wrote:

> Dan Mahoney, System Admin wrote:
>
> <snip>
>
> > Damn.  The real problem is that there's no real way to differentiate
> > between a "wrap" carriage return and a hard-return (otherwise I could
> > just strip after the fact with a script).

Warning, a little long, but a lot of explanation of various circumstances.

When I first learned to type it was on my dad's Smith Corona typewriter. 
I learned that the bell meant "hit return soon".  When we finally got a 
computer (running OMG WordStar under CP/M) it took me six months to 
UNLEARN hitting return at the end, and I still see it in people who are 
new to computers every day, where their justification is uneven, and they 
occasionally have a line that wrapped itself, but they hit return anyway 
(because they were looking, of course, at the keys not at the screen). 
This is a branch of the same issue.

Over the course of a year I was composing a story for some time with pico 
and then nano.  An 80,000 word story.  And I was letting people just read 
the textfile in their browser.  Their biggest annoyance was that since I 
was writing it on four different systems, the wrapping was at four 
different points throughout the same textfile.

The solution here was to write a redirector that ran it through txt2html 
(and it even cached), spat out the correct content-type, and showed nice 
formatting and fonts instead of the blasted courier new that so many 
people complained about.  I'm used to dealing with frustrations over this 
issue. :)

> And there's really no way to do it visually with a lot of soft-wrapping
> editors I've tried.  Although, with nano, I suppose that whitespace
> display mode could be extended to display hard carriage returns as well
> as tabs and spaces differently.

Just like wordperfect or word with "show-codes" or "view all characters" 
on (points at the subject)?  The soft-wrapping works the "second" way 
below in editors like Ultra Edit, and Crimson Editor (both free, both can 
handle unix mode files, for windows).

> > Having a user-definable hard-return key could be fairly easy.  For
> > example, having nano insert <BR>\n (literally) when I hit return in
> > HTML files.
>
> That sounds like something that'll have to wait until nano gets
> rebindable keys, assuming that there's also a way to add new
> functionality to the rebound keys.

This is true.  It also opens up the possibility of including modes where 
nano behaves with keystrokes a bit more like your standard word processor 
(i.e. ctrl-b inserts <B>, or the RTF sequence for "bold" etc).  Perhaps 
there could even be macro support (i.e. user definable prompts which 
could then be passed to external scripts).  Yum.  But that's a WHOLE 
nother can of worms.

> > (This actually all comes from dealing with blogging and fighting the
> > blog system's auto-format engine, which formats ALL \n to <br>...which
> > means my blogs get wrapped to the width of my ssh screen, or wrapped
> > to long-short-long-short).  I have the option to turn it COMPLETELY
> > OFF...but that requires I specify my own newlines (everything else,
> > the browser auto-wraps, which is the standard.)
>
> Maybe you could use justify here, with -r set to however wide you want
> each line to be, since it'll add newlines in the proper places then.  By
> the way, out of curiosity, what blogging software are you using that
> does this?

Livejournal.  The perl-based "jlj" client, in particular.

The default formatting mode with LJ is that it formats newlines to <br />.

The annoyance here is that more often than not nano's idea of what the 
screen should look like either looks like:

this is a paragraph that got hit by nano's auto-wrapping and also wrapped
by being displayed
on livejournal.  Since nano wrapped the lines at some width that has
nothing to do with
the width of your livejournal screen, it becomes REMARKABLY annoying to
read when it was
typed as one standard paragraph with no carriage returns at all.

Or, on the occasions I'm using it on a small terminal (like my phone):

this is a paragraph
that got hit by nano's
auto-wrapping and also
wrapped by being
displayed...

A paragraph, as concerns this, should be a SINGLE LONG LINE.  The browser 
will wrap it, regardless of browser screen width (and I believe LJ also 
adds newlines WITHOUT doing the translation).

You can turn that formatting *off*, but then I'd have to be typing the 
<br>'s myself which is just annoying for doing stream-of-consciousness 
writing.

My partways solution was to load the Term::Width perl module and basically 
look at the width of the screen and if I see a newline within ten 
characters of the right margin, delete it, and render it to space space. 
I suppose I could also make the logic more convoluted and look for 
[space][newline] since the space character is preserved when nano 
hard-wraps.

This means if I type out poetry (or more realistically, code or recipes, 
or a screenpaste of an email I've gotten) 
like:

There once was a girl from nantucket(newline)
who couldn't carry a tune in a bucket(newline)

The formatting holds, but more normal paragraphs get "unwrapped" -- most 
of the time it's flawless, but occasionally this logic has a glitch.

For example, scroll down to the bold line in this post:

http://gushi.livejournal.com/295422.html

You'll see that the header I was pasting was "close enough" to the edge 
that my logic said "crap, that was a single-line".

> > I know this sounds like feature-creepism, but how difficult would this
> > be to implement (even as an unofficial patch -- I'm willing to
> > contribute something (webspace, beer, cash to the project), as this is
> > my single biggest issue with pico/nano, but I still haven't been able
> > to get myself to switch to vi/vim/emacs for a number of reasons. 
> Unfortunately, it would be very difficult.  The display and wrapping
> routines would of course have to change to handle this.  Also, the way
> nano keeps track of the number of lines, the number of characters, and
> the current column in the file would have to change, and it would
> introduce a lot of questions.

> For example, if you're soft-wrapping one
> very long line and it's displayed as two lines, how many lines should
> nano say it has, and where should it say the cursor is positioned?

"Read 212 lines, long lines soft-wrapped".

"Line 4, position 1,282".  Chances are, if you're writing using a language 
that understands long lines (even if it's say, perl with a complicated 
regex), it will say that that line is where the error is, and since I'd 
consider this to be a non-default mode, I'd expect anyone who turns it on 
to understand that *yeah*, that's what it's *supposed* to do.

> While 
> those questions can certainly be answered eventually, I don't want
> to be asking them when nano's in a feature freeze and trying to become
> the next stable version.  In any case, I added this request to the TODO
> list, so it won't be forgotten.  Sorry I can't be of more help right
> now.

Don't worry about that.  It's on my wish-list, that's all.  It's not an 
OMG NEED THIS FEATURE.  I've got workarounds in place on it.  I apologize 
for the length of this email, but I wanted to detail exactly how and why I 
had worked around it.

> > Mainly because the behavior of nano is CONSISTENT wherever you use it.
>
> That's good to hear.
>
> > (Ideally, nano would also have a line-number indicator at column zero
> > so one could actually SEE which lines didn't have numbers (and thus
> > were soft-wrapped, but I know that's DEFINITELY more work -- and I
> > know you guys are trying to maintain the relative simplicity of pico,
> > and as much alike-behavior.
>
> That's certainly another way to indicate soft-wrapping.  What do you
> think of the extended whitespace display I mentioned above, though?

Oddly, with pico I've opened a DOS file and had the line endings show as 
non-editable non-searchable "^A" (I think it was A) characters that the 
cursor jumped over in a single keystroke (instead of two).  Nothing 
stopping the same logic from extending to ^N in nano, but that's a bad 
default case.  In theory with a good whitespace parser the only real 
whitespace you'd see in a file was on the trailing end of a tab.

I imagine if you had the DEC character set working you could probably get 
the neat dash-level dot for a space, as well as as the |P (paragraph 
marker) as well as that nifty single character ">>", or even the "arrow" 
working.  Representing it in your more standard character sets could be 
interesting.

Heh, I toiled once to play with doscmd and the like to try to get 
wordperfect for dos working on my shell -- only to realize that your 
average SSH app does not parse alt-f7 :)

Anyway, apologies for the length.  I hope I've laid my logic out clearly. 
Let me know if it all makes kinda-sorta sense.

--

"The first annual 5th of July party...have you been invited?"
"It's a Jack Party."
"Okay, so Long Island's been invited."

--Cali and Gushi, 6/23/02


--------Dan Mahoney--------
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144   AIM: LarpGM
Site:  http://www.gushi.org
---------------------------