Re: Extension Language for a Text Editor

Nikolai Weibull wrote:

> ...
>
>>Well, to be blunt, whatever you come up with won't be as popular or
>>useful as the existing regular expressions, just because they'll be a
>>nonstandard replacement of something already very common.  PCRE
>>regexps are extremely flexible and well-known.
>>    
>>
>As useful?  Please, my dear sir, there has to be something better than
>the way we describe regular expressions now.  At least for searching
>text.  The syntax we have today for regular expressions is basically the
>same, only extended, as that that Ken Thompson uses in his 1968 paper on
>it.  Or that of _real_ regular expressions long before it.  And
>remember, real regular expressions only have * (Kleene star) and no +.
>There has to be a simpler syntax that can be useful for interactive text
>search-and-replaces.  Look at Vim, Emacs, and Perl (and thus,
>basically, Ruby)'s syntax.  They are all extensions of this, adding new
>short cryptic ways of saying things that you often don't need, and if
>you did you wouldn't want to do it that way anyway.  The real example of
>how it has gotten out of hand is the overuse of backslash (\).  It is
>everywhere.  having to move my hand to the upper right corner of my
>keyboard all the time is a real pain.
>Of course we'll have to see if I'm actually able to come up with
>anything better.  It's probably not going to be as easy as I'd like to
>suggest here.  However, look at the Perl 6 Apocalypse 5[1] to see one way
>of moving away from cryptic (?:...) metasyntaxes.
>  
>
I've seen one (1) way of improving regexp's.  It involved using graphic 
representations while creating them.  After expression creation, it was 
rendered into text (and if you knew what you wanted, you could just type 
it in).  I haven't seen any actual language improvements that weren't in 
some way isomorphic.  (I.e., you can use pretty graphics for each of the 
inserted characters, and you might do something to make typing the 
escape character easier, but improving the semantics ... I haven't seen 
any better options.  And improving the syntax... possibly if you switch 
to unicode...but then how do you enter it?

>>That isn't to say people won't use them, ...
>>    
>>
>Nah OK.  You've got a point.  But, as with most free software, this
>one's for me ;-).  If anyone wants to tag along later on, fine.  But I
>  
>
So you won't be interested in the graphic editor.  I've got a vague idea 
of how much additional work that would be.  It was in a commercial 
product on the Mac, but I don't think it's being made any more.  (Either 
Nisus or Qued/M ... probably Qued/M, but if it's Nisus, I seem to 
remember that the feature went away in a later version... too complex 
for many of their potential customers, perhaps.)

>won't care if no one is interested, Emacs and Vim are fine editors.
>Even notepad has its uses.  It can, for example, tell you if a file is
>smaller or greater than 65535 bytes very easily ;-).
>I have, perhaps, failed to describe the real winning here.  (Alas, I
>realize I forgot to mention it.)  As you perhaps know, Vim, and most
>other UNIX software, operate on a line-by-line basis.  This restriction...
>
>--
>::: name: Nikolai Weibull    :: aliases: pcp / lone-star / aka :::
>::: born: Chicago, IL USA    :: loc atm: Gothenburg, Sweden    :::
>::: page: www.pcppopper.org  :: fun atm: gf,lps,ruby,lisp,war3 :::
>main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}
>  
>
Not to discourage you, but have you looked at NEdit?  It doesn't have a 
full scripting language, but it has some nice pattern recognition 
mechanisms.  And it's GPL.  (OTOH, I've never gotten their source to 
compile...they don't use a standard make system, but something of their 
own creation that seems to me to have problems.)