Subject: Re: It would be groovy...

From: Being Riptup <[email-masked]>
Date: Mon, 9 Mar 1998 11:01:32 -0700 (MST)

On Thu, 26 Feb 1998, David Miller wrote:

> On 26 Feb 1998, Robin S. Socha wrote:
> 
> The feature-list in Pine 4.00 will have
> 
>             [X]  enable-reply-indent-string-editing
> 
> allowing what you see here...
> 
> Sorry Robin> JH> I hope this is the right place to send this.  If not, just tell
> Sorry Robin> JH> me.
> Sorry Robin> 
> Sorry Robin> It isn't.

I couldn't help being reminded of that annoying LACK of rejustification,
not to mention the justification you DON'T want. 

I sometimes neaten it manually. You'd hav trouble automating the process.
You could assume that unmatched punctuation (unmatchable punctuation
hasn't this caveat) that begins more than say THREE lines is part of a
quote-margin, a heuristic that would less often corrupt messages as you
increased the threshold.

Quote-Margins: Sorry Robin>, JH>

For messages received without the Quote-Margins header, the user could
enter the quote margins manually if they set the threshold to 0 or <empty
value>, the default. That would let you hit ^J on a quoted paragraph and
get clean results, so that the quoting above would appear this way:

> Sorry Robin> JH> I hope this is the right place to send this.  If not,
> Sorry Robin> JH> just tell me.
> Sorry Robin> 
> Sorry Robin> It isn't.

Note that identical Quote-Margins connect paragraphs. You'd need to add,
or remove Quote-Margins strings in the same way that justification adds or
removes carriage returns.

In other words, you'd replace /nl with a string variable that defaults to
"/nl" in the context of justification.

> The Pine Team does read pine-info and they get alot of ideas here.
> It's actually (IMHO) exactly where such ideas should be hashed out!

A switch somewhere to turn off or a key-press to reverse that automatic
line wrap in pico would be nice. Could you make it do virtual
line-wrapping? It would reduce the want for HTML writing and interpreting
power in mail-readers or their child-processes, especially from people
who write you HTML.

By the way, it would be nice if you let people view unrendered HTML.

I doubt WordPerfect invented the format where carriage returns begin
paragraphs and new lines are inserted as needed only for the display (not
the file). See variable new line string above, and tell me if you see a
useful, soluble problem.

For backwards compatibility, when the message was actually sent, the
variable new-line strings would become static: written.

Basically, this would just let you keep paragraphs justified while
working. For maintaining backward compatibility in the final product, the
variable new line strings would be sent (stored?) with the 80 character
screen width assumption--in justified paragraphs.

Internally differentiating justified and unjustified paragraphs (paragraph
beginnings should be visible and not part of the final product) would cut
that annoying half measure that makes me continually terminate a line with
a space, then backspace from the first character of the next line to
concatenate the two after the automatic line wrapping function breaks 
them. I regularly edit files that should have long lines where I don't
press ^J.

And while we're on ^J, PINE inserts a superfluous space at the end of
paragraphs it justifies. It also exchanges the space at automatic line
breaks for a new line. It would be nice if when a line is concatenated
with the previous line, the space is reinserted.

PINE also assumes lines above the cursor are part of the paragraph and 9
times out of 10 I don't want that--at least until you support
Quote-Margins.