Re: ::scr Towards a better text editor

[Richard Clamp <richardc@xxxxxxxxxxxxx>]

On Mon, Oct 01, 2001 at 03:00:33PM +0100, simon wistow wrote:
> On Mon, Oct 01, 2001 at 02:06:23PM +0100, Richard Clamp said:
> 
> > Eh?  Sorry, what?  Doesn't scan.  What's 'this'?
> 
> Muddling text modes.

I have distinct yet similar modes for dealing with email messages,
perl code, and TeX documents.  They're all text so the similarity is
helpful, they're different types of text so the differences in the
(non-core) behaviour are useful too.

Explain how this could be better handled.  It's currently just a blind
assertion, that's why I'm challenging it.

> I just don't think that Emacs is intuitive - not even internally. 

By internally do you mean internally consistent?  You'd have to give
me an example though.

> Mark made a good point about this when I first bought this up 
> http://london.pm.org/pipermail/london.pm/2001-July/002223.html

Yes, though the points seem to be, "xemacs is puzzling when I first
start it" and "X apps seem to use the mouse oddly".  I wholly agree
with that.  If you're deriving a different point I'm curious.

> Celia would be good to jump in here about intuitiveness and interfaces [hint
> hint].

Anyone who's used an interface and had opinions of it is just as able
to comment, surely?

> I didn't say editor extensions though - I said a macro language. Ultraedit has
> a macro language that lets you simulate any keypress or menu option ... but
> nothing else. And I don't really need it to do more. Ok, yes, it would be nice
> in some ways to have the document API exposed to a scripting language like
> Perl but not strictly necessarily. See below about feature creep.

I would find an editor that only provided me with keystroke repetition
as an extension mechanism unduly limiting.  There's a reason people
don't use notepad, and it's not because it isn't manly.

> > You have to stop?  Surely if it's modular and demand loading you don't
> > need to worry unduly about this.
> 
> Yes, I think you have to stop. Feature creep is a bad thing and just makes
> stuff too complicated. Interfaces are especially susceptible to this.

How does my editing interface (hitting keys) change when a syntax
highlighting module is loaded?  Did making my tab key grok perl stop
me moving between lines with the keybindings I'm used to?  

Sure might not want all that stuff to go in the core, but I do still
want to be able to do it.  The leaner you try and keep the core, the
harder that gets (for example look at the evolution of jed - the
editor which uses slang as it's internal language)

> There is the argument that you raise that people should be able to add
> features later using a modular system. So what you're saying is that you want
> a simple text editor with an exposed document API that allows modular loading
> of extensions.

Document API?  Editor API makes slightly more sense to me - create a
buffer, attach a process to it, frob, put results into original
buffer.  For some things these hooks need to go quite deep, say into
the file specification routines which enable something like tramp to
work, but yeah, that's something I'd want.

>                                             If you think Emacs is perfect then
> that's fine and you're lucky because you've got the perfect text editor.

I don't I assure you.  I'm only using emacs in response to your
assertions about it, same as I invoked the spirit of vim to correct
your assertion about cursor motion in the vi family.

-- 
Richard Clamp <richardc@xxxxxxxxxxxxx>