george@hyper.lap.upenn.edu (George "Sir Lleb" Zipperlen) (04/24/91)
I have about 50% of the the Apollo DM editor working using the Apollo
Text Management Library (TMLib). The major things that need to be added
are search/replace and mark/region handling. I don't know how to
handle rectangular regions with wrapping in effect.
Oh yes, I couldn't get history/UNDO to work.
Also missing is a lot of other DM functionality such as window
management and key re-definition, and the DM command language; as I've
cheated and bound a lot of functions directly to keyboard/mouse events.
Additional functionality not in the DM
text cursor distinct from window manager cursor
8-bit fonts or pairs of 7-bit fonts to get at
characters in the range 128-255.
If you don't mind storing your file as a TMLib object, rather
than as unstructured text, you can use multiple fonts.
I've been doing this in spare time -- the real project was a template
oriented multi-lingual dictionary editor.
If there's interest, I could clean out the dictionary stuff, and post it
here, or in alt.sources in a few weeks.
TMLib itself is part of the MIT X11/contrib distribution, and needs C++
to compile. You can do a lot more with it than writing flat editors.
Any idea how much work it would be to do a DM -like window manger for X?
I can't stand uwm, twm, awm, SunView, Mwm, MacIntosh, Windows3, or any
others I've tried, and I'm stuck using shared-mode X on the Apollo
(slow, and soon to disappear...). I did like the old Xerox
XDE/ViewPoint environment, though, and SmallTalk is nice too.
I know the DM editor is addictive, when I ftp files from Suns, NeXTs,
and other beasts to edit them on the the Apollo!
--
George Zipperlen george@hyper.lap.upenn.edu george@apollo.lap.upenn.edu
...!{rutgers, uunet, mit-eddie, decwrl}!upenn.edu!hyper.lap!george
Blatant plug: funky-music-request@hyper.lap.upenn.edu: "Won't be no Static" -JBrees@dabo.citi.umich.edu (Jim Rees) (04/25/91)
In article <41853@netnews.upenn.edu>, george@hyper.lap.upenn.edu (George "Sir Lleb" Zipperlen) writes:
I have about 50% of the the Apollo DM editor working using the Apollo
Text Management Library (TMLib).
What I'd like to see more than the DM editor is DM pads. I've got an xpad
client written, but it doesn't work exactly right because of limitations in
the way ptys work. The xpad client needs to get a notification when the guy
at the other end of the pty is blocked on a read, so that it can then drain
all the output and update the boundary between the input and output sides of
the pad. I can make this work in Domain/OS by either mucking with the
innards of ptys or writing my own pty type manager. But I don't know how to
do it in general on a vanilla Unix pty.
What my xpad does now is it waits for output, and when it gets some, updates
the pads. But this doesn't always work because there is no way to know the
order in which i/o events happened. This is crucial for moving the input
text to the proper place in the output half of the pad.
Suggestions welcome. Also, anyone know how to subclass Athena text widgets?
I want to be able to draw the line between the input and output halves of
the pad, and I think I need to subclass the sink widget to do this.
I suppose it might make sense to write a "DM edit" widget and use that
instead. That's a bigger project than I want to get into, but maybe it
could be spun off of George's DM editor.
This is a low-priority project for me so I don't expect to have anything
usable for a while, if ever.root@ttsi.lonestar.org (System) (04/26/91)
In article <512af270.cb12@dabo.citi.umich.edu> rees@citi.umich.edu (Jim Rees) writes: >What I'd like to see more than the DM editor is DM pads. I've got an xpad >client written, but it doesn't work exactly right because of limitations in >the way ptys work. The xpad client needs to get a notification when the guy >at the other end of the pty is blocked on a read, so that it can then drain >all the output and update the boundary between the input and output sides of >the pad. I can make this work in Domain/OS by either mucking with the >innards of ptys or writing my own pty type manager. But I don't know how to >do it in general on a vanilla Unix pty. It seems to me that the easiest way to approach this is through the Epoch extensions to GNU emacs which enables multiple windows (pads if you will) to be popped. If you combine epoch with multishell.el (by Aamod Sane), you have the nice ability to pop up shell windows. Multishell depends upon cmushell.el which is a whole lot nicer than the default GNU shell mode. The only thing left to do would be to write the elisp for DM emulation. Much of this effort will simply be a key-mapping-to-existing functions exercise. Alot will be writing some wrapper routines. I'd be surprised if someone hadn't already done this. I've done a superficial job of mapping the left keypad and top right row of keys. It's just a fraction of the DM functionality, but heck, now I have all the benefits of emacs at my disposal which DM can't begin to match. Another dividend from this approach is that you've now learned an editor that plays on dumb terminals as well as a fancy X display. (I'm talking about emacs and not epoch which is limited to X display. The two are identical when it comes to keyboard editing functionality.) With emacs on a dumb terminal, you can have multiple shell buffers, etc. etc. etc. DM is a pretty sleek cat but it wouldn't be the end of the world if it went away. -- Mark S. Evans Tandem Telecommunications Systems Inc. Phone: 214-516-6201 850 E. Central Parkway Fax: 214-516-6801 Plano, TX 75074 Mail: mse@ttsi.lonestar.org
rees@dabo.citi.umich.edu (Jim Rees) (04/30/91)
In article <1991Apr26.140019.8433@ttsi.lonestar.org>, root@ttsi.lonestar.org (System) writes: >What I'd like to see more than the DM editor is DM pads. It seems to me that the easiest way to approach this is through the Epoch extensions to GNU emacs which enables multiple windows (pads if you will) to be popped. Correct me if I'm wrong, but I think you've missed the point. There are two features of DM pads that I don't think you can get from emacs shells: 1. The ability to edit input before it gets eaten by the shell. I don't mean in a separate buffer that you have to arrange to use ahead of time, I mean in the shell window itself. 2. Correct ordering of input and output. For example, if I type "sleep 4 <nl> echo foo <nl>" the output should look like this % sleep 4 % echo foo foo % not like this % sleep 4 echo foo % foo % I believe that at least feature no. 2 requires mods to the pty driver.
nazgul@alphalpha.com (Kee Hinckley) (04/30/91)
In article <51443fc4.cb12@dabo.citi.umich.edu> rees@citi.umich.edu (Jim Rees) writes: >2. Correct ordering of input and output. For example, if I type "sleep 4 ><nl> echo foo <nl>" the output should look like this > % sleep 4 > % echo foo > foo > % >not like this > % sleep 4 > echo foo > % foo > % > >I believe that at least feature no. 2 requires mods to the pty driver. The Korn shell tries. It lets you type ahead and see it, but then it displays it all where it should be too. -- Alfalfa Software, Inc. | Poste: The EMail for Unix nazgul@alfalfa.com | Send Anything... Anywhere 617/646-7703 (voice/fax) | info@alfalfa.com I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.