Re[7]: Autoformat

1999-10-27 Thread Alexander V. Kiselev

I   (Marck)  am  posting  this  on  behalf  of  Alexander  V.  Kiselev
<[EMAIL PROTECTED]>  who  has  unfortunately  been unable to get any
mail  posted  to the list since the server problems earlier this week,
although  he  is  still  receiving list traffic. Those of you familiar
with  his contributions to date will understand how frustrated he must
feel :-(.

---

Hello all.

Let's clarify things a bit. Here goes explanation of the author of 
another Delphi-based ASCII editor (WinEdt), Alex Simonic. 
Maybe it will help both the RIT labs programmers and the 
audience here to understand, what can be done with auto-
formatting. Of course, considering e-mail application like TB, 
necessary changes are to be made, but the overall concept 
proved to be almost excellent (this is based on my own 
experience with the program named above and on the opinion 
expressed on the WinEdt mailing list). Okay, he we go:-))

*
WinEdt supports line wrapping and paragraph wrapping. Line 
wrapping is enabled or disabled through the appropriate option 
in the Document Settings Dialog. Line wrapping applies only if 
your caret is over the right margin (as specified in 
Preferences| Editor Dialog) and you are positioned at the end 
of line. In such a case WinEdt goes back to the first space and 
simulates a line break. A more interesting concept is 
Paragraph wrapping, which is particularly useful when you are 
making additions/ changes to the sentence in the middle of a 
paragraph. However, the ASCII "concept" of a paragraph is not 
very well defined: lines are the basic components of ASCII 
files. 

WinEdt implements a wrapping strategy that is particularly 
suitable for writing TeX documents. Paragraphs are normally 
separated by empty lines. Lines that contain a Comment (as 
specified and enabled in Settings| Miscellaneous Dialog) are 
not formatted and also serve as paragraph separators. 
Furthermore, in the Settings Dialog you can specify so called 
"paragraph breaks" and "exceptions." If a line starts with any of 
the strings specified as paragraph breaks then such a line is 
considered a paragraph break unless it also matches a string 
specified as an exception to the rule. 

This allows two strategies for setting up paragraph breaks: you 
can either list all the strings that should serve as paragraph 
breaks. For example, the default settings specify: 
 \begin
 \end
[the rest of the list skipped...]

Alternatively, some users might prefer disabling the formatting 
of all lines starting with "\" and then simply enter the exceptions 
such as "\cite"... After some dynamic adjustments this 
approach will yield the required result as well - you can enter 
the exceptions as you encounter them during your work. 

In Document Settings Dialog you can also specify whether or 
not indented lines should be subject to formatting.

If you don't like the Wrapping feature you can disable it (eg. by 
clicking the appropriate Status Line Panel). You can still 
manually format a paragraph through the "Edit| Format| Format 
Paragraph" Command (by default it is associated with the 
(shortcut) Insert Key). This is more emacs-like behaviour... 

Auto wrapping is always disabled when you are in a Block 
Selection mode. If you select a portion of text and then call 
Format Paragraph command you can also specify the left and 
right margins for this paragraph by simply making the 
appropriate (left/right) block selection. Try it! 

WinEdt also supports "Soft" file format. This is the format used 
by many word processors and unconventional editors, in which 
paragraphs are separated by line terminators while lines are 
dynamically wrapped. If you open a file in "Soft" Mode WinEdt 
will display it properly. However, this "Soft" Mode is not 
WinEdt's native mode (WinEdt is primarily an ASCII editor) 
and the performance might not be as good as for ASCII files. 
Please note that while you might find wrapping in "Soft" mode 
more intuitive (especially if your experience is with WYSIWYG 
word processors) such files might no longer be transferable as 
ASCII files. 
*

Okay, my apologies for this rather long explanation... Please 
consider this. This is what I call "well-thought" implementation:-) 
IMHO, of course.

P.S. There exists a technical explanation of the implementation 
described above, too. It might be of some help to The Bat! 
programmers. If they (or anybody else) needs it, I can post it 
off-the-list, too. Or else everybody interested can just download 
WinEdt from www.winedt.com and see, how it works. I'm using 
it all the time (instead of Word, too) and am entirely satisfied 
with its functionality. BTW, I have no connection to the WinEdt 
project other then admiring user

SY, Alex
-- 
Alexander V. Kiselev, St.Petersburg, Russia
--- 
Thought for the day:
  Walk through doors, don't crawl through Windows.

 
 

Re[7]: Autoformat

1999-10-28 Thread Oliver Sturm

Hi Marck D. Pearlstone,

On Mittwoch, 27. Oktober 1999 at 20:21:16 you wrote:

OS>> I  don't  care  at all, really. Even if I repeat myself: I want a
OS>> function to auto-format the text I type.

MDP> I  was  only  saying  that that is not what is *there*. Accepted it is
MDP> what you are suggesting.

Thanks ;)

MDP> Be  specific.  "Badly thought out" is not. If you're a programmer then
MDP> you, too, should be able to define a bug clearly.

Badly  thought out is not specific, you're certainly right about that.
But every programmer has to deal with the user (and I am a user of The
Bat!,  not  it's  programmer)  telling  her "I don't like the way this
function  works  for  this  reason  and  that". She needs to go to her
chamber  or  whatever  and think about which parts of the program from
the technical point of view (that's the point you can only really have
if  you  know the source, too) could be faulty in whatever way (notice
the absence of the word "bug" here) to cause the user's criticism.

OS>> Making  a  function  work in the way it should have from the start
OS>> has  nothing  to  do  with enhancing anything. A bug is not only a
OS>> single point you can lay your hand on and say "this is what has to
OS>> be  done  to  fix  it",  but  it's  also  failure  in  concept  or
OS>> implementation. IMO, that's exactly the point about a-f.

MDP> I  disagree.  "Making  a  function  work  better" comes more under the
MDP> "suggestions for improvement" banner. By definition a "bug" is a logic
MDP> error which has a defined method for reproducing it and a quantifiable
MDP> effect on what happens.

It  seems  we  have a different understanding of what is a logic error
with  a...  and  so  on. I've several times described exactly in which
cases  the a-f function doesn't do what it's supposed to do (or what I
think  it should do, as AFAIK there's no public statement about that).
That behaviour is absolutely reproducible (just like your problem with
the  quotes)  and it certainly has a quantifiable effect (for example,
taking our time discussing it ;-)


MDP> The  guys  at RIT have a policy of only acknowledging the first report
MDP> on  a specific bug and only notifying that single person of its' cure.
MDP> It is my belief that they do read them all.

LOL. I certainly hope so!

[description of several bugs cut]

MDP> .. in due course?

Exactly.  I  don't  believe  it's the best way to have a priority list
made  up  of the most interesting programming tasks. Inserting lots of
new icons is surely very important, although nice.

OS>> Pardon me for ranting.

MDP> Pardoned. It's been an interesting debate. :-)

It  is.  Anyway,  why  don't  they  make  The  Bat!  open  source? I'd
immediately take over that a-f function ;)

Oliver Sturm

--
Oliver Sturm / <[EMAIL PROTECTED]>

Key ID: 71D86996
Fingerprint: 8085 5C52 60B8 EFBD DAD0  78B8 CE7F 38D7 71D8 6996