wmb@SUN.COM (Mitch Bradley) (12/29/89)
Discussion of the possibility of a portable standard Forth window interface: > ... progressive layers of windowing functionality described ... > I really do think you can go a long way with this model without making > anything that'll break on a Mac or under Gem or Microsoft Windows or X > or Intuition. Correct, but by the time you have finished, you have defined yet another look and feel. In particular, the style of interaction with "gadgets and buttons" is a major component of look and field, and often affects the structure of the application. If Forth invents its own look and feel, Forth will become even further isolated from the mainstream, where the people and the bucks are. I would like to be proven wrong on this, but who in the Forth community has the particular combination of skill, insight, time, money, guts, and influence to do it? I had the skill, insight, time, money, and guts to try it for file system interfaces (a much easier problem in a much more mature domain), but I failed on the influence factor. Based on my observations over many years of Forth conventions and standards meetings, NOBODY has much influence in the Forth community, not even Chuck. > ... various "bells and whistles" of different OS file systems enumerated ... Ken Thompsom cut through all the file system crap about 20 years ago and articulated a good set of simplifying assumptions: the Unix file system. Then he got *real* lucky; Unix caught on, and his idea of the right set of simplifying file system assumptions influenced an entire generation of programmers. This was helped along substantially by 3 industry revolutions (minicomputer, microcomputer, and workstation) which essentially isolated the previous set of "big guns" (the mainframe manufacturers). In principle, this could still happen for windows. In practice, it hasn't happened yet, and I doubt that it will. There are too many window warriors with too many bucks behind them, fighting it out in a mature industry. Maybe there will be another revolution, and somebody will get lucky and ride it to fame and glory. Who can predict such things? > People still run Nethack in Xterm windows, Amiga console windows, > and so on... If all you want is curses, I agree that it's no problem, but it's also hardly worth doing anymore (Forth should have had curses 10 years ago; now it's moot). I can't think of too many commercially successful applications that still use a curses imaging model. Buyers have come to expect a lot more. A text-based program running in a terminal emulator window is not a window program. Mitch
peter@ficc.uu.net (Peter da Silva) (12/31/89)
> Discussion of the possibility of a portable standard Forth window interface: > > ... progressive layers of windowing functionality described ... > > I really do think you can go a long way with this model without making > > anything that'll break on a Mac or under Gem or Microsoft Windows or X > > or Intuition. > Correct, but by the time you have finished, you have defined yet another > look and feel. Perhaps, perhaps not. It all depends on how much control you let the application have over the interface. If you define the interface in terms of panes (of unknown size) that are tiled together to form a window, then put sufficiently high-level objects in the panes, what's the problem? > In particular, the style of interaction with "gadgets > and buttons" is a major component of look and field, and often affects > the structure of the application. Perhaps. I'd like some more concrete evidence of this... most systems I've seen have pretty much the same semantics for buttons. > I had the skill, insight, time, money, and guts to try it for file > system interfaces ... but I failed on the influence factor ... So the problem is primarily political, then. Not technical. > > ... various "bells and whistles" of different OS file systems enumerated ... > > Ken Thompsom cut through all the file system crap about 20 years ago and > articulated a good set of simplifying assumptions: the Unix file system. Unfortunately there are lots of systems out there that don't allow a UNIX file model. Even MS-DOS, which is heavily influenced by UNIX, has a file system that's divergent enough to cause problems. Oh, and have a look at the Mac csome time... the Mac file system is, to put it kindly, rather baroque. > I can't think of too many commercially successful > applications that still use a curses imaging model. Buyers have come to > expect a lot more. Lotus 1-2-3? MOST IBM-PC programs use text screens with no capabilities that Curses can't provide. -- `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. 'U` Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>. "It was just dumb luck that Unix managed to break through the Stupidity Barrier and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com
stever@tree.uucp (Steve Rudek) (01/04/90)
In article <8912291429.AA16742@jade.berkeley.edu>, wmb@SUN.COM (Mitch Bradley) writes: > If all you want is curses, I agree that it's no problem, but it's > also hardly worth doing anymore (Forth should have had curses 10 years > ago; now it's moot). I can't think of too many commercially successful > applications that still use a curses imaging model. Buyers have come to > expect a lot more. > > A text-based program running in a terminal emulator window is not a > window program. I've already presented my thoughts on this in a previous posting so I'll make this real brief. Curses is better than nothing. Much better. With curses support people could begin writing "silly" Forth applications along the lines of nethack, emacs, larn, rn. If we had 4 Forth applications for Unix which were even half as good as those four we'd witness a heck of a lot of fresh interest in Forth in this newsgroup. -- {pacbell!sactoh0! OR ucdavis!csusac!}tree!stever
henk@cs.eur.nl (Henk Langeveld) (01/05/90)
stever@tree.uucp (Steve Rudek) writes: >I've already presented my thoughts on this in a previous posting so I'll >make this real brief. Curses is better than nothing. Much better. With >curses support people could begin writing "silly" Forth applications along >the lines of nethack, emacs, larn, rn. If we had 4 Forth applications >for Unix which were even half as good as those four we'd witness a heck >of a lot of fresh interest in Forth in this newsgroup. What to think of 'vi', with forth as built-in extension language, as in Emacs ? Or am I just dreaming ? -- Henk Langeveld, Unix SysAdmin | domain: <henk@cs.eur.nl> Department of Computer Science | phone: +31 10 4081346 Erasmus University Rotterdam | also: langeveld@hroeur5.bitnet Room H5-05, P.O.Box 1738, NL-3000 DR Rotterdam, The Netherlands.
ripley@tubopal.UUCP (Hans-Ch. Eckert) (01/08/90)
In article <1990Jan5.113915.18626@cs.eur.nl> henk@cs.eur.nl (Henk Langeveld) writes:
]What to think of 'vi', with forth as built-in extension language, as in
]Emacs ? Or am I just dreaming ?
I've seen Emacs-clones written in Forth (I got a copy of Forthmacs for the ST
some days ago), and a friend of mine has developed a complete Forth-system
(including editor, cli and even more). Why not a vi-clone ?
Surely it is possible, so somebody just DO it !
Greetings,
RIPLEY
--
Greetings from RIPLEY | UUCP: ripley@tubopal.UUCP (ripley@opal.cs.tu-berlin.de)
Hans-Christian Eckert | ...!unido!tub!opal!ripley (Europe)
D-1000 Berlin 30 | ...!pyramid!tub!opal!ripley (World)
Regensburger Str. 2 | BITNET: ripley%tubopal@DB0TUI11.BITNET (saves $$$)wmb@SUN.COM (Mitch Bradley) (01/09/90)
> I've seen Emacs-clones written in Forth (I got a copy of Forthmacs for the ST Well, actually, the EMACS in Forthmacs isn't written in Forth. It's MicroEMACS (written in C) modified so that it can be called as a subroutine from Forth, with some hooks for compiling Forth code directly from EMACS buffers. You can also mark a "region" in an EMACS buffer and compile just that. You can pop back and forth between Forth and EMACS without losing the state of either. > Why not a vi-clone ? Please, no! Aaaaargh! vi has the most baroque command syntax of any screen editor I know. Let's not do anything to propagate it! Okay, okay, I admit it. I'm an EMACS fan. Mitch (author of Forthmacs)
peter@ficc.uu.net (Peter da Silva) (01/09/90)
> Please, no! Aaaaargh! vi has the most baroque command syntax of any > screen editor I know. Let's not do anything to propagate it! While there are valid reasons to complain about VI, the command syntax is not one of them. The limited macros, all the confusing shortcuts, and the heavy line-orientation are problems. The command syntax, which is almost universally <count>command<range>, is not. In fact, it's cleaner than the comand structure of any other screen editor I've seen yet. Certainly it's better than Emacs' ad-hockery. -- _--_|\ Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. / \ Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org> \_.--._/ v "Have you hugged your wolf today?" `-_-'
peter@ficc.uu.net (Peter da Silva) (01/09/90)
Actually, I have a Forth screens editor that uses the command syntax of vi.
Anyone want a copy?
--
_--_|\ Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>.
/ \ Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>
\_.--._/
v "Have you hugged your wolf today?" `-_-'wmb@SUN.COM (Mitch Bradley) (01/12/90)
> Discussion about relative speed of EMACS vs. vi at 1200 baud. The screen update routines in uEMACS are not as sophisticated as those in vi, so it doesn't do quite as well at low baud rates. Most other versions of EMACS (e.g. JOVE, Unipress, GNU) have excellent screen update routines that do reasonably well at low baud rates. uEMACS screen routines were originally written to make only minimal assumptions about the terminal capabilities, using only VT-52 functionality (the VT-52 did not have "insert-character"). This was probably a good idea at the time; there were some legal battles about whether or not certain portions of screen update code were proprietary. These legal issues affected JOVE (it contained some AT&T code) and GNU EMACS (it originally contained screen update code from Unipress EMACS; that code was then rewritten to avoid some legal hassles). The simpler uEMACS screen update code was not affected by these battles. Many recent versions of uEMACS use direct screen access on machines which support it (e.g. PCs). > The version of Forthmacs I got (1.1, dated '86) is surely long forgotten. > Which is the actual version ? Actually, version 1.1 is still current. I update the patches file as bugs crop up, but by and large, version 1.1 was good enough that it seemed better to leave it alone for awhile. In the shareware distribution channel, there is a tremendous time lag between the release of something and its propagation everywhere it is going to end up. If I were to change it too often, I would end up with a big support headache. > BTW: What do you think about Sun's SPARC's which have Forth builtin? I think they are fantastic, but I am very biased. I spent the last 2 years of my life developing and fighting for those Forth PROMs. That's one of the reasons that Forthmacs newsletters have been so scarce lately. From my perspective, even neglecting the Forth PROMs, the SPARCstation-1 machine is the most satisfying machine that Sun has yet built, and I have been involved with all of Sun's machines since the Sun-1. Mitch