[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Dan Mahoney, System Admin
Subject: Re: [Help-nano] Soft-Wrap and Show-Codes?
Date: Sun, 8 Oct 2006 04:13:51 -0400 (EDT)

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

Dan Mahoney, System Admin wrote:


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

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:

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]