NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/lang/pop/153

Internet Message Format | 1992-12-16 | 5.0 KB

Path: sparky!uunet!pipex!unipalm!uknet!news.cs.bham.ac.uk!axs
From: [e-mail] (Aaron Sloman)
Newsgroups: comp.lang.pop
Subject: Re: Editors
Summary: people have very different tastes in interfaces
Message-ID: <[e-mail]>
Date: 16 Dec 92 22:31:00 GMT
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: School of Computer Science, University of Birmingham, UK
Lines: 95
Nntp-Posting-Host: emotsun

[e-mail] (Steve Knight) writes:

> Date: 15 Dec 92 13:40:58 GMT
> Organization: Hewlett-Packard Laboratories, Bristol, UK.

(Someone else, Tim read(?) wrote):
> > So what is your over all conclusion Robin? Perhaps oneof():
> > 1) Ved should be extended to offer more of the functionality of EMACS.
> > 2) Pop11 should be separated from the editor, to allow full user choice.
(Steve)
> Surely (2) should refer to POPLOG and not POP-11?  I don't see how POP-11
> and VED are connected in any interesting way (unless you count the fact
> that VED is largely written in POP-11.)

I have previously proposed to the poplog development team that
POPLOG should define a client-server protocol for interacting with
*any* programmable editor. This should support compiling from a
marked range, sending an arbitrary bit of the editor buffer to
Poplog, writing arbitrary characters from Poplog into arbtrary
locations in the editor buffer, informing poplog which file is
currently being edited, Poplog asking the editor to switch to a new
file, the editor asking Poplog where to get a file required via a
HELP, or SHOWLIB command (and if the file is not available on the
machine on which the editor is running POPLOG should be prepared to
squirt it down a socket, etc.) and so on.

Then a version of VED could run in a separate process from a Poplog
development process, as could Emacs. The editor process and the
Poplog process could even be on different machines.

> My own conclusion would be (3), POPLOG should be extended to provide more
> standard tools, such as mailers and readers, but this extension should NOT
> be done using VED but using the X-toolkit interface.  It is completely
> unacceptable to me to use a text editor to process my mail.

It is completely unacceptable to me to have to use mouse and menus
to process my mail. I want a collection of text editing facilities
tailored to doing various things like, preparing a reply to the
current message, deleting the current message, marking the current
message, copying the current message to another file, creating an
index of messages in the current file, going to a selected message,
going to the next message, going to the previous message, going to
the next message from the current sender, removing unwanted lines in
the current mail header etc. etc. I would use function keys and/or
ENTER commands for all of this.

Actually I have most of this in a local birmingham package called
LIB VED_GETMAIL, which extends existing stuff in the Unix Poplog
VED library (e.g. LIB SEND, VED_REPLY, VED_MCM, VED_CCM, VED_MDIR
etc.) and is an alternative to LIB VED_MAIL

> ...I want a
> graphical interface properly geared up for the task in hand.  Otherwise
> you end up with the lame EMACS compromise and no one wants that!

The second most dangerous mistake any software designer can ever
make is to assume that there's something nobody wants. For the most
dangerous mistake change the quantifier.

> [The problem with this suggestion is that the actual toolkit to be
> used is unclear.  Should it be Motif or OpenLook?  Or even Athena (yukk)?
> Another possibility would be to write a POPLOG-style toolkit based
> solely on X-windows and not the X-toolkit (but how to integrate into the
> event handler?)  Yet another solution would be to extend the Poplog widget
> set to provide enough widgets for this.]

Er, ... that's roughly what the UIDE project will make possible,
mainly by combining OBJECTLASS and RC_GRAPHIC to produce a graphical
objects library (GO_TOOLS) which can then be used to design highly
functional interfaces. It will probably not require additional
widgets.

It will not look like Motif, nor like OpenLook, but who cares about
what it looks like as long as it has good functionality?

(I know, I know.... lots of people care about looks. But then let
them wait for a widget based system, which will be bulky slow, hard
to change, etc. etc.)

> However, I do agree with Tim in his suggestion that POPLOG should be
> made to work nicely with EMACS.  And that probably means making sure that
> extend_searchlist is able to broadcast to the user-editor that the search
> lists have changed.

This would not be necessary if the sort of protocol I listed above
were used, which would have the advantage that you could use the
editor on a machine that did not have the files that Poplog had
access to. (It's beginning to sound like a poplog version of NFS ?)

Aaron
--
Aaron Sloman, School of Computer Science,
The University of Birmingham, B15 2TT, England
EMAIL   [e-mail]  OR [e-mail]
Phone: [phone]       Fax:   [phone]