Re: Possible activity heading towards XyWrite replacement

[wbass@xxxxxxxx]

>Epsilon sounds intriguing, but you don't say what its
>advantages are over Xy IV-cumU2.

Well, firstly, I don't really want to start a contest. I do have
great respect for what the U2 folks have done. I don't use Xy IV
(I still use III+, mostly because it's considerably somewhat
leaner), so I probably can't give the worlds best comparison.
Chances are I'd continue to use both, and my goal would be that
my keyboard personalizations would be compatible for things I use
frequently, so that switching between them frequently would be
easy, without having to retrain my fingers in the process.

But let me take a shot at a "what are the advantages" type of
comparison.

(Note: the following may be more readable with a fixed pitch
font. Copied and pasted to a notepad window, for example.)

Epsilon advantages:

 1. A much more modern, 32-bit, multiplatform implementation.
  Whatever work I do to further enhance/personalize my editing
  environment, I don't have to fight DOS boxes and emulators of
  various sorts to have my work port well to platforms other
  than Windows.

 2. Stemming from (1) above:

   a. A *real* undo and redo facility. I can back out that last
    keystroke, or 2, or 10, or 20, always and reliably,
    without cluttering/fragmenting my disk(s) with endless
    autosaves

   b. Real unicode support. Epsilon implements "buffers" (the
    entitiy which holds data being edited) in both 8 bit and
    16 bit flavors, and automatically switches the entire
    buffer to a 16 bit one as soon as any character in the
    buffer is found to be greater than 255. It also does
    conversions to/from the various unicode file "encodings"
    when reading or writing (some of which are basically 8
    bit, but use "escape" sequences to encode unicode chars
    >255).

   c. *real* mixed case and long filename support, including
    the appropriate (by OS) distinctions between "case-
    preserving" and "case-sensitive" filename handling.

   d. Real "windows" support. If I want a display that is, say,
    170 characters wide for a given file for some reason, I
    can get it quickly and easily using the GUI version.
    There is of course pull down menus and all of that, but
    that isn't all that important to me.

   e. real, on-going maintenance bug fixes, so that one's
    environment is not cludged up with a bunch of workarounds
    for unfixed XY bugs. Although XY IV 4.018 apparently got
    to a fairly good level of "cleanliness," it seems clear
    that work stopped on it not because it was found to be
    bug-free, but rather because a company folded. Best I can
    tell, most major epsilon releases continued until bug
    finding really did stop, and you always go back to final
    version of such major releases if the latest version
    (which always has new function and hence new bugs) is
    found to be wanting.

 3. Better functionality in many areas.

   a. Documentation: both online and printed documentation are
    available, and excellent, and really cover what you need
    to do extensive personalization. Some of this is really
    slick: for example the documentation in winhelp documents
    "functions" (such as "CD ", for Xy's Cursor Down
    primtive, for example) rather than keys, and as the help
    page for "CD " (or epsilon's equivalent thereof) is
    displayed, the help program queries an active copy of the
    epsilon editor (using DDE or COM) to find what key(s)
    that the "CD " function is CURRENTLY bound to, and
    displays those also.

    A printed and bound manual is available from an "on
    demand" printing service, for about $15 plus shipping.
    The quality of the XY documentation isn't even in the
    same league, and there simply is no need for books like
    Tyson's, which are largely efforts by user to discover
    all of the stuff the was left undocumented by the vendor.

   b. True regular expression support, including provisions for
    substitutions in the a change command replacement string
    where portions of the search string are used in the
    replacement string for portions match by "wildcards". For
    example, if X denotes some kind of "wildcard" expression,
    and a search argument like "abXcdXef" finds matchs of
    abJOEcdFREDef and abMARYcdJANEef, then the change command
    can be made to replace

     abJOEcdFREDef with abMIKEcdJOHNef, and
     abMARYcdJANEef with abSUEcdMISTYef,

    by appropriate specification of from and to arguments.

   c. There is enough functionality in the epsilon "dired"
    (directory) listing window that epsilon becomes a pretty
    reasonable "file manager" substitute, including
    provisions for file copying, moving, deleting, rename,
    filename case-folding, and what not.

   d. "Prefix-key" keyboard mapping. Any key can be defined as
    a "prefix," giving rise to the possibility of endless
    "key assignments." For example, Ctrl-X is by default
    defined as a prefix key, and "commands" can be bound to
    sequences like Ctrl-X,A or Ctrl-X,Ctrl-B or whatever. In
    addition, keys can be rebound to functions in an
    impromptu "on the fly" manner within a given session,
    without having modify and load another "keyboard file".

    When the going get tough, I find binding organized in
    this way much easier to remember then endless shift,
    ctrl, ctrl-shift, ctrl-alt, alt, alt-shift, and ctrl-alt-
    shift bindings.

   e. Modes: you can define "modes" for different file types,
    such as "C" source, assemble source, HTML, or whatever.
    Epsilon knows about a dozen or so such modes.

    You can have key bindings automatically overriden on a
    mode-by-mode basis. So, for example, if you have a bunch
    of keys that help you when you are editing hebrew, you
    can use them for other function when editing "C" source.
    Or whatever.

    As it comes "out of the box," epsilon does "code
    coloring" based on modes.

   f. Coloring. Each character in a "buffer" for a file being
    edited has a settable *and queryable* "color" attribute,
    which controls the background and foregroud colors used
    in displaying that character. This facility is used for
    the "code coloring" that epsilon does.

    It's only lately that I've begun to appreciate the value
    of this. For example, XyWrite III+ implements "redlining"
    using the  and  tags, and those tend (in III+
    at least) to interact badly in files where one already is
    using  tags very much. Were I implementing the same
    thing epsilon, I might simply use the coloring facility
    to keep track of deleted and added text (the color
    property can be tested, or even included in searches, via
    epsilon's primitives).

   g. Source code availability. As I indicated in my last post,
    epsilon is a two tiered implementation. If you took just
    the executable (.exe) file, it doesn't interface to the
    user much at all. Instead it implements the concept of
    (any number of) "buffers," which, when filled with data,
    are displayed in windows, in certain ways. Buffer's are
    "nice," compared to what a programmer usually has to deal
    with -- for example, you don't have to worry about
    allocating the space that they use, and you can insert a
    character into the "middle" of a buffer without have to
    worry about making space for it.

    Then there are "primitives," to load files into buffers,
    edit buffers, and manage windows that can be used display
    buffers. And there are buffer search primitives, with
    "regular expression" support. But there is no user
    interface or "user commands" at this point."

    All of the user commands are written in EEL, and all EEL
    source code is provided. This is not like XPL code --
    it's semi-compiled a thousand times faster. So it's
    really a different ballgame than XyWrite. How many time
    have we just wished that XyWrite source code was
    available, so that this or that glitch/shortcoming could
    be fixed right? With epsilon, there is a low level (the
    implementation of buffers and the display mechanism for
    them) for which you don't get the source, but just an
    awful lot of the functionality is done in EEL, who's
    source code is provided (as is the EEL compiler).

    According to a response from an inquiry I made to Lugaru,
    Lugaru does have an intent to be sure that epsilon is
    "open sourced" in the course of any events that would
    otherwise cause it to become abandonware.

The above is just a list of some major things that come to mind,
and is by no means all-inclusive.

Epsilon disadvantages:

 1. The big disadvantage, of course, is that epsilon is not a
  WYSIWYG "word processer" that understands paragraphs,
  indented subsections, lists (undented and indented
  paragraphs) and such, reflowing these structures onscreen
  automatically as one writes. Nor does it understand variable
  pitch font printing, and formating output for such printing.

  I find that automatic reflowing of such structures onscreen
  is essential to me when I am writing, so this is the first
  thing that I propose to "fix." For the most part, I intend to
  "fix" it using (a subset of) exactly the same "tags" that XY
  uses, such as  or  (<> being guillemets, of
  course), and to display them the same way that XY does.

  Personally, I do so little printing, that I probably would
  not implement a variable-width font printing facility.
  Rather, my approach would be to keep the markup compatible
  enough with XyWrite that XyWrite could be used to do the
  printing, at least in the short term.

 2. No "command line." When all is said and done, this is really
  the reason that I haven't used epsilon more already. But I
  think this is also fixable, and this would be the other item
  (besides reflowing) that I would fix right off.

  Consider a "change" command, for example. In epsilon (or
  emacs), the "change" command would be "bound to some key."
  When you hit that key, epsilon would first prompt you for the
  "from" string. After entering that and pressing Enter, it
  would prompt you for the "to" string, and then finally do the
  command when you enter that string and press Enter. I don't
  much care for this "architecture" for two reasons: (a) it's
  more key bindings that I must remember (which I find harder
  to remember than the corresponding command line verbs -- as
  long as I have to enter arguments, I might just as well be
  entering a command verb), and (b) it doesn't let me see both
  the "from" and "to" change strings at the same time.

  However, I think it is quite doable to use the "prompt area"
  as a command line, via a new "command" writen in EEL (and
  bound to a key) which prompts for an entire command-line type
  command, parses the command line for a verb and arguments,
  and then does whatever is requested (perhaps calling existing
  EEL routines to "finish" a command like the change command,
  so that there is no need to actually write the guts of a new
  "change command" implementation.

>Epsilon sounds intriguing, but you don't say what its
>advantages are over Xy IV-cumU2.

So the above is a start. However, I'm not sure that this level of
comparison makes a lot of sense. When you look at "Xy IV-cumU2,"
you are looking at something which has a fixed, unchangable
underpinning (XY 4.018), and that has been massaged for 15 years
into something that is about as far as it's going to go. A
substantial part of the U2 functionality, if you really look at
it, is compensation for XY's shortcomings and idiosyncrasys,
which largely aren't there in epsilon to begin with. And, at
least when I think about my "XY on epsilon plan" and thoughts,
I'm looking at something that is near the beginning of it's
evolution, which has a different and generally much larger (save
"word processing functionality") and "cleaner" set of
underpinnings on which to build. Who knows where it might go.

Wally Bass