Hi there!
On 2 May 00, at 14:57, Allie Martin wrote
about "Re: auto-format is too robotic isn't it?":
> > Allie, will you please understand that within plain/text medium there is
> > no way for the program to distinguish between _your_ hard returns and
> > the hard returns inserted by the line-wrapping algorithm?
>
> Pardon my slowness for making that erroneous suggestion. :-/
>
> The real reason for my response here is that you didn't really mention
> whether or not my proposed problems with your solution to the
> auto-formatting issues are equally as erroneous and lacking in
> understanding, or are they in fact valid?
Allie, no personal offence, please! I didn't mean to insult you, just wanted to
stress the idea that if we stay on the grounds of _plain_text_ medium, we need
to take into account that there is _no_ paragraph concept applicable to this
medium. The document consists of _lines_, not paragraphs.
There exist a number of ideas as to how resolve this problem. If anybody
cares to read about it, and (more interesting) to read about it from the
viewpoint of software developer, I'm again suggesting that you read the
Wrapping section of the online help for WinEdt 5.1 (www.winedt.com).
I basically do not understand the common gripes about the autowrap vs.
autoformat issues which from time to time get posted to this list. I don't think
it's too hard to hit Alt-J or whatever from time to time. But _if_ we consider the
autoformat feature, we immediately need to consider, how exactly should TB's
editor decide, which block of text _is_ a paragraph and which isn't.
In my previous message I suggested that the indented line should be
considered as the paragraph _boundary_, note further that I suggested this
only as a quick fix to what we have right now (see also below). This would
mean the following: if I have the text formatted this way:
some text
then start typing immediately after the word "text" above, the "autoformat" _is_
active all right (again, download and install WinEdt to understand what I mean:
this program can be configured to behave exactly this way!). This means that
eventually I get:
some text some text some text some text some text some text some text some
text some text some text some text some text some text some text some text
some text some text some text some text some text some text some text some
text
Now look further. _If_ I now place my cursor this way:
<cursor is here>
some text some text some text some text some text some text some text some
text some text
and start typing, the new input _is_not_ considered as the part of the "some
text" paragraph, since indented line is considered as a paragraph break. This
means that the text I type in is considered a _separate_ paragraph and
autowrapped as such.
If OTOH I place my cursor as shown below:
some text some text some text some text some text some text some text some
text some text some text some text some text some text some text some text
some text
<cursor here>
the new input _again_ is NOT wrapped "into" the "some text" paragraph, since
the next line after is again indented.
Finally, as the only different possibility, I place the cursor as shown below:
some text some text some text some text some text some text some text some
text some text some text some text some text some text some text some text
some text
<cursor here>
_then_ the new input is still considered the part of the "some text" paragraph
and wrapped into it, as in:
some text some text some text some text some text some text some text some
text some text some text some text some text some text some text some text
some text <new text>
What part of it you don't like?;-) Again, note that the list of characters that
mark the "paragraph break" when located at the beginning of the line may be
made configurable (again, as in WinEdt), which would extend the functionality
even further. Note also, that given the current implementation of autowrap it
should be quite simple (and require minor extra coding) to re-implement it the
way I proposed above.
Finally, I have to admit that if we "lift" the plain-text condition, the whole
problem could be considered from absolutely different viewpoint. For example,
the programmers can choose whatever hex string they like to act as a
"linebreak" and to leave "hard" linebreak for the user. This is the way Word
works, for example. Note two things:
1. This would require major changes in the source code of the program and is
therefore not the good thing to implement given the fact that version 2 is said
to be rolled out by the end of May;
2. Having worked alot with WinEdt (see above), I myself do find the way to
determine the paragraph breaks even _better_ then the way Word and the
other word processors exploits; at least this pure-ASCII way of doing things is
_much_ more flexible and configurable from the user's viewpoint. Yes, it
requires some time to understand how it works, but then it works as smoothly
as that.
Dixi;-))
--
SY, Alex
(St.Petersburg, Russia)
http://mph.phys.spbu.ru/~akiselev
---
Thought for the day:
The only thing that hurts more than paying income tax
is not having to pay income tax.
---
PGP public keys on keyservers:
0xA2194BF9 (RSA); 0x214135A2 (DH/DSS)
fingerprints:
F222 4AEF EC9F 5FA6 7515 910A 2429 9CB1 (RSA)
A677 81C9 48CF 16D1 B589 9D33 E7D5 675F 2141 35A2 (DH/DSS)
---
--
--------------------------------------------------------------
View the TBUDL archive at http://tbudl.thebat.dutaint.com
To send a message to the list moderation team double click here:
<mailto:[EMAIL PROTECTED]>
To Unsubscribe from TBUDL, double click here and send the message:
<mailto:[EMAIL PROTECTED]>
--------------------------------------------------------------
You are subscribed as : archive@jab.org
