Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > Extension Language for a Text Editor

Reply
Thread Tools

Extension Language for a Text Editor

 
 
Nikolai Weibull
Guest
Posts: n/a
 
      10-09-2003
* Simon Strandgaard <(E-Mail Removed)> [Oct, 09 2003 18:42]:
> > I'd say this is way simpler, more effective, and more extensible
> > than redefining all-new regexp syntax. Especially since the
> > existing syntax is hairy enough.

>
> Yes this isn't going to be easy. I am the kind of type which like
> hairy problems
>

Remember that there is more than syntax to consider. Both semantics and
actually doing the matching. You can alter the syntax without altering
the semantics and matching. (I may be expressing this incorrectly
though),
nikolai

P.S.
What I'm saying here is that even if you change the syntax, you don't
have to make it any less powerful, or reimplement it from the start.
D.S.

--
::: 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);}

 
Reply With Quote
 
 
 
 
Nikolai Weibull
Guest
Posts: n/a
 
      10-09-2003
* Dale Martenson <(E-Mail Removed)> [Oct, 09 2003 09:10]:
> You may want to look at the VIM's use of Ruby for writing
> extensions. Documentation available inside of VIM via ":help
> ruby".

Yes, but have you actually seen anyone use it? Or any of the other
extension languages available (Tcl, Perl, Python)?
> For an up-to-date copy of VIM see: http://www.vim.org

Hm, have you not seen me post on the Vim lists? I'm an avid user of
Vim. Thanks anyway ,
nikolai

--
::: 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);}

 
Reply With Quote
 
 
 
 
Nikolai Weibull
Guest
Posts: n/a
 
      10-09-2003
* Gavin Sinclair <(E-Mail Removed)> [Oct, 09 2003 09:10]:
> This capability of Vim doesn't seem to be heavily used. I certainly
> don't use it. Partially because the integration is a bit lacking (but
> you could do Ryan's aligner very easily - but then there's an
> excellent and well-supported vim plugin for that anyway). Partially
> because I couldn't be bothered.

The problem with Vim is that it has an interface to every possible
language, so none of them becomes the standard. VimL is the standard of
course, but it would be great if we could force a better language as
well. (By "better" I of course mean _bigger_ right?
nikolai

--
::: 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);}

 
Reply With Quote
 
Nikolai Weibull
Guest
Posts: n/a
 
      10-09-2003
* Seth Kurtzberg <(E-Mail Removed)> [Oct, 09 2003 09:10]:
> Well, for one thing, doing it in lisp would be reinventing the wheel, as
> emacs has been around for ages.

Yes, this is true, and one of the strongest points for not going down
that road.
> One main advantage that I see to ruby is that one could modify existing
> code and add new code much more easily if the modifier doesn't have a
> lisp background. lisp code is horribly unreadable.

This is, however, only an opinion, not a truth. Lisp code may be
unreadable to you, and many who have never gotten used to it. But
there's no point in saying that it would be easier to modify others
code, simply because it wasn't written in Lisp. With Lisp you get 40
years of coding standards build-up. I bet that people able to speak
Lisp without starting to lisp (hahaha, so funny) are very able to modify
other peoples code. Probably even more so than for many other
languages, as Lisp is, after all, very clean and simple in many
respects. I'm guessing that everyone hates Lisp because of Common Lisp.
Common Lisp is large and hard to grasp, whereas there are many
alternatives that are small and simple to comprehend.
> If you do want to use a functional language Haskell is a much better
> choice, and would in fact be interesting in this context.

Yes, in fact Haskell would be great as I am studying at Gothenburg
University, which is one of the two or three major hubs of Haskell
research and development. I do, however, feel that Haskell is to
complex and, as you should also feel (as a Ruby user), to restrictive.
Typing is one of its strong selling points, and I'm not a fan of typing.
nikolai

--
::: 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);}

 
Reply With Quote
 
Nikolai Weibull
Guest
Posts: n/a
 
      10-09-2003
* Robert Klemme <(E-Mail Removed)> [Oct, 09 2003 18:42]:
> Since others have commented on various aspects of your posting I'll only
> throw my 2c at this:
> > Also, is there any way of redefining the // operator for constructing
> > regular expression objects? I'm planning on implementing a new regex
> > syntax for the editor (to make searches/substitutions easier to
> > describe).

> Why do you want to change it? I find it quite flexible and expressive
> (especially when using flag "x"). And especially if you want to attract
> rubyists to use TREC (The Ruby Editor to Come), then you should ensure
> that their knowledge of ruby regexps is not obsoleted, since rx's will
> likely play an important role in user defined extensions!

Hehe. Yeah, that is true. So we'd need two separate constructs.
>
> You can always define methods in Kernel like this:
>
> irb(main):002:0* module Kernel
> irb(main):003:1> def rx(str)
> irb(main):004:2> puts "building rx from '#{str}'"
> irb(main):005:2> end
> irb(main):006:1> end
> => nil
> irb(main):007:0>
> irb(main):008:0* rx %q{(foo)+ \s+ (\w+)}
> building rx from '(foo)+ \s+ (\w+)'
> => nil
> irb(main):009:0> rx '(foo)+ \s+ (\w+)'
> building rx from '(foo)+ \s+ (\w+)'
> => nil
> irb(main):010:0>
>
> Which isn't too bad IMHO.
>

No, it isn't actually. Thank you for pointing this out. This could
actually be the answer to my question. I'll have to think about this.
I had totally forgot that we had very restrictive single-quoting
contexts (and even the %q{}). Thanks,
nikolai

P.S.
I realize now that that last part may seem a bit sarcastic, but it
isn't, I promise.
D.S.

--
::: 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);}

 
Reply With Quote
 
Simon Strandgaard
Guest
Posts: n/a
 
      10-09-2003
On Fri, 10 Oct 2003 03:36:46 +0900, Nikolai Weibull wrote:

> * Simon Strandgaard <(E-Mail Removed)> [Oct, 09 2003 09:09]:
>> What a coincidence.. I am also writing a programmers editor (AEditor)
>> in Ruby.
>> http://aeditor.rubyforge.org/

> Yes, I have seen it, and tried it (see below).


Great. Thanks for trying it


[snip]
>> where is the homepage ?

> eh, it was included in the end of the mail (marked [3])
> http://www.pcppopper.org/code/win/sled/
>> http://sourceforge.net/projects/slackedit

> This is very old. Do not use


Ok.. I have just download the source, but cannot extract it:

server> unzip slackedit-src.zip
Archive: slackedit-src.zip
End-of-central-directory signature not found. Either this file is not
a zipfile, or it constitutes one disk of a multi-part archive. In the
latter case the central directory and zipfile comment will be found on
the last disk(s) of this archive.
unzip: cannot find zipfile directory in one of slackedit-src.zip or
slackedit-src.zip.zip, and cannot find slackedit-src.zip.ZIP, period.
server> md5 slackedit-src.zip
MD5 (slackedit-src.zip) = 45346944242e2b3edb418f6f9d76d776
server> ll
total 172
-rw------- 1 neoneye neoneye 175584 Oct 9 21:51 slackedit-src.zip
server>


>> Your Trove-info says 'gnome', but no unix install.

> No, the plan was to port it to Gtk/GLib, but that never happened.


Ok


>> My original plan were to use Ruby as an extension language and write
>> the core in C++... At some point started experimenting using Ruby for
>> everything, and now I have actually written AEditor completely in Ruby!!
>>

> Yeah, it is very nice and simply done. I like your code. I see you've
> read your GOF well (especially the first chapter I presume . I
> do, however, feel that you've gone into it a bit too much. I mean, It's
> fine to represent lines as object, but individual characters? It gets a
> bit big at that point


The first+second incarnation of AEditor were coded in C++, and had a
little memory consuming datastructure. I was too focused on using as
little memory as possible and at the same time have an efficient program.
I have spend too many years on this without actually producing anything.
Now I follow the saying "make it work, make it right, make it fast".
I am in the 'make it work/right' phase at the moment.
Speed and memory-consumption doesn't yet matter.

Actually I got the GoF book this summer.. I don't know how I could live
without it. I am not inspired by its suggested design.


>> > * What would be easier to do using Ruby?

>>
>> undo/redo/macros.. The code which is responsible for this only takes up
>> 119 lines of Ruby code. This is more complex in C++ because you cannot
>> #clone arbitrary objects.
>>

> Well, if you take a look at the undo/redo code for Wily and Sam, they
> are actually not very large. Using the Command pattern is very clean
> and OO though.


I have just read the fine documentation for SAM. It covers many
interesting issues. The protocol is facinating, but I don't like its use
of the CommandPattern for undo/redo. I myself has exprienced that pitfall
of using CommandPattern this wrong way. Instead MementoPattern should be
used. Though in some cases, reverse operation can be sufficiently.


>> It would be easier for users of your editor to make changes
>> to the internals of your editor (because Ruby is intuitive).
>> If you have a testharness then they will also could test if
>> their changes has unforeseen sideeffects.
>>

> Intuitive in general, yes. But is it intuitive in this context. Are
> there any obvious winnings by using it? Can you forsee syntax
> definitions and indentation definitions easier to write in Ruby than in
> LISP? Why? How?


I know very little about emacs.. I have no clue about LISP vs Ruby.
I want the user's AEditor dotfile to be Ruby code, something like:

server> cat .aeditor
language("ruby") {
tabsize=2
fold_tags=["#[", #]"]
help = HelpRI.new # using 'ri' for context help
key(F1){|context| help.lookup(context.current_word) }
key(F9){|context| system("ruby -d #{context.filename}") }
}
language("cplusplus") {
tabsize=4
fold_tags=["//[", "//]"]
key(F9){|context| system("make"); system("a.out") }
}
server>


[snip LISP]
> guess, that, in the end I'm just pushing Lisp here because I am
> interested in it and want to give it a try. Ruby is great, but I
> already know Ruby . I'm trying to get someone to push me back into
> the Ruby camp .


I prefer StandardML over LISP. Functional languages has other kinds of
constructions which has thier advantages. StandardML is has
pattern-matching, for instance 'gcd' looks like this:

fun gcd(0,n) = n
| gcd(m,n) = gcd(n mod m,m);

First line matches on a first argument which is zero.
Second line matches otherwise.

I have implemented a few things in SML: raytracer, www-search-engine,
compiler. I like Ruby over SML (but SML is nice


>> If your editor core is written in a different language than your extension
>> language. Then you will no matter what language chosen, have to make a
>> bridge between. There are shortcuts, such as SWIG.
>> SWIG can generate wrappers for *many* script languages.
>> My vote would be Ruby
>>

> Yeah, but I want the language that makes it simpler to move as much out
> to the extension language as possible.


I don't think the choise of a extension-language has any impact on how
many lines of code in the core.


>> > * Is Ruby good enough for the task at the moment, performance wise?

>>
>> You can try out AEditor, to feel if Ruby is fast enough.
>> On a 100MHz machine AEditor feels quite Okay.
>> On a 33MHz 486 it can be slow.
>> I can live with this hardware requirements, thats why I choose to write
>> everything in Ruby
>>

> Yeah, I tried opening this rather large text file (In The Beginning Was
> The Command Line) and it started thrashing my hard-drive (just loading
> it (a file of perhaps 200K?) since it required 130MB to load it started
> swapping.


Yes it consumes much memory. AEditor works acceptable with relativ small
files. I am in the process of designing a new better/flexible/smarter/
faster/... datastructure.


>> What features do you plan for your editor ?
>> Is it a programmers editor, or a propertional font editor ?

> It's a general editor, of course aimed at programming. Proportional
> text is for whimps


Agree.. Same goals here.

What features do you plan: word-wrap, folding, refactoring ?

--
Simon Strandgaard
 
Reply With Quote
 
Ryan Pavlik
Guest
Posts: n/a
 
      10-10-2003
On Fri, 10 Oct 2003 02:36:25 +0900
Nikolai Weibull <(E-Mail Removed)> wrote:

> * Ryan Pavlik <(E-Mail Removed)> [Oct, 09 2003 09:10]:
> [stuff about Emacs and Vim]
> > Well, whichever, just be aware that emacs is designed as an extensible
> > editor, and vim is not, even though such things have crept in with
> > varying degrees of usefulness.


> Yes, that, as I see it, is Emacs biggest win. The big problem I see
> with Vim is that it hasn't undergone a major overhaul. It is basically
> Emacs written in C now.


Not really. It's vi with lots of hacks to do more stuff added. So
much for being a tiny, bloat-free editor.

> Vim is, in my opinion, probably the best editor that exists right
> now. It is, however, going to reach a point where adding new
> features will demand some sort of rewrite. With Emacs, things like
> these are easy to alter. Anyway, Vim is extensible, it is, however,
> not _changable_. By that I mean that, if you want to change the way
> folding works, you must rewrite the core of Vim.


Actually that'd be the other way around. vim is changeable... you can
alter the C core... but it's not extensible: you can't really add
extensions. _This_ is what causes feature creep and bloat. Not
having 20 million extensions that do everything imaginable. Being
able to add extensions means you're able to _remove_ them. Rolling
stuff into the core means you've got a bloated editor.

Somewhat ironic.

Now, I don't want to start an editor war here. This could very easily
turn into one, and that would totally defeat the point. Therefore,
let's look at emacs and vim in terms of the interface concepts they
embody, such as interactivity, modality, extensibility, etc, rather
than implementation faults. Implementation is irrelevant since you're
implementing something new.

So basically, if you like a modal editor or not, go for editor of form
of your choice. I've seriously considered switching to vim simply
because of the ruby support. (A few things have kept me from doing
this, but they were merely technical issues.)

> And, as Bram pointed out in some interview, that means altering
> basically every file in the Vim distribution. To Vim's salvation
> comes the ability to easily define new syntax definitions and
> indentation definitions, which one has to agree, are a lot easier to
> create and alter than with Emacs (Emacs being perhaps more powerful
> though).


Not really, the emacs syntax bits are pretty trivial to do. They look
worse than they are; I was hacking around on the ruby-mode, and it was
much easier to modify than it appears.

Now, this isn't really emacs vs vim; it's just a matter of philosphy.
You could trivially add code in emacs to do vim-ish syntax
descriptions, and I'm sure you could add code in vim to do more
scripted syntax.

The point to note is that it'd be a lot less work to convert
simplified syntax into complex syntax than it is to add scripted
syntax later.

> [stuff about Ruby libraries and such]
> > Right. They're there, people can write extensions that interface to
> > the web, or whatever.


> Yes, but I don't want an Operating System. I guess, to a certain degree
> the library you get helps you, but it can also detract you from the
> central topic, namely editing text.


I know it's a typical joke to say "emacs isn't an editor, it's an OS",
but remember---it's a joke. Don't build your editor based on jokes.

In truth the emacs core is very tight: it provides a buffer-oriented
language and interface elements. Because it's general, people have
written lots of stuff, some of which is quite silly (tetris, web
browser, etc.), but is also a testament to flexibility. You can be
sure that if you can make it play tetris, you can also make it edit
text in any conceivable way.

Of course this isn't limited to emacs-style editing. Plenty of
editors are scriptable; you could implement scripting capabilities and
provide any interface you want. Same deal. Flexibilty, however, is
something worth considering.

> > See http://ogmo.mephle.org/tabular-alignment.org for the Lisp
> > version. The ruby one I deleted, as it was pretty simple to
> > reproduce, I'm sure someoone can whip up an example.


> Yeah, OK. I see your point. It is, however, very easy to alter to fit
> your own needs. Change some global variables and you can make it work
> for almost anything. I can't tell, but I'm guessing your code in Ruby
> wouldn't allow for this?


Actually the ruby version and the lisp version are almost identical,
API-wise. I just wrote a function in ruby that took a string and a
regexp, and returned the aligned string. The fact the emacs one goes
through and replaces buffer text is the only real difference.

> I'm not trying to contract you, only point out that Emacs extensions
> are, as oposed to Vim extensions, very flexible and well thought
> out. This does, of course, not mean that it can't be done in Ruby.
> I just get the feeling that Lisp excels at this.


Well. I definitely agree about the emacs extensions vs vim ones.
This is mostly philosophical IMO, as stated above. What makes
extensions more flexible is not the language, exactly, but the
philosophy you have for extensions. If it's "you can run a script on
the text" (like the ruby vim module), you don't get a lot to work
with. If it's "you can hook into every conceivable part of the
editor", or (like the sawfish window manager) "all higher-level
functionality is implemented in the scripting language", you have
extreme flexibility.

That said, one of the nice things about ruby is that it has taken a
_lot_ of direction from Lisp. There are _many_ little things that
just make it more convenient to use (closures, for instance).
Convenience when writing extensions is greatly appreciated by
users.

> [stuff about functional vs. OO being more well suited for editing
> text]


> > I don't really find that. I don't think functional programming is any
> > easier for editor-related tasks. I'm not even sure how you would come
> > up with such an assumption.


> My real point was that having OO around doesn't really help either. It
> doesn't add anything. Sure, you can make classes like Buffer and Window,
> were is the real gain?


The first gain is elegance. Uniformity. You know where to look when
you want a method to alter Window; you look in the Window class. You
don't look for all the functions that may or may not have "-window" in
them. (This is a major issue I've had with both sawfish and emacs;
the nomenclature is not uniform. This may be considered purely
implementational, but people tend to be lazy, or they've approached
something from an unusual angle, and things break down.)

The second is extensibility. If I want to alter how the buffer is
handled, I have to look for hooks (if they're provided) and make sure
to set all the right global variables (ugh) and change the keys, etc.
With the object-oriented approach, I just subclass Buffer and override
what I need. (Or perhaps I merely make a new interface class.) It's
much more straightforward, and again, more elegant.

> I have tried to envision some OO structure for implementing Emacs
> like Major/Minor Modes and such, but I haven't been able to come to
> any satisfactory results. I mean, how is a Major Mode an object?
> Really?


This is because you're trying to do a direct transliteration of emacs
to OOP. This doesn't work. Step back and see first what you're
trying to accomplish, and then design an object structure that handles
it, while sticking to the _philosophy_ of emacs ("script everything").

Just off the top of my head, you don't want modes, first off. They're
too constraining. The major problem is that you can't have multiple
"major" modes without a lot of hackery (if at all). What you ask
yourself is: what do modes provide? The answer: buffer behavior.

What might be better: behavior objects. You have a class hierarchy to
modify various aspects, and you put these together to build your
favorite buffer behavior. This way you could have multiple syntaxes
per buffer, for instance.

Configuration would simply be changing the object properties. For
instance, if you get a hilighter object as 'syntax', you might:

:
syntax.comment_color = BLUE;
syntax.variable_color = RED;
:

The 'syntax' object could be a subclass of a more general Formatter,
and you may even have a subclass per language, where you have the
ability to implement specifics if necessary. A basic SyntaxHilighter
could provide simple regexp hilights that everyone would use anyway.

> I guess it has a syntax definition, a separate keybinding mapping,
> an indentation callback, maybe something else? I just don't feel it
> adds anything though. I am, of course open to suggestions .


The main thing I'd suggest is to look at what things _mean_, and what
they _could_ be... don't necessarily mimic the way things are
implemented right now.

> > Right, tiny C core like emacs, everything higher-level in the language
> > of choice. Ruby is highly suited for this task.


> Yeah, this is true. Ruby would be well suited for this I do
> believe. But note that Emacs C core isn't very small


The emacs C core includes elisp, which isn't exactly fair; count all
the lines of vim and perl, and you won't find it too small either.

> > People could even write high-performance ruby extensions in C...


> Yeah, this would be easy to do as well. There is, of course, the
> inherent risk of not being portable enough. Vim supports this in a way,
> and I have never seen it used to date.


True, but ruby extensions tend to be fairly portable. Don't worry
about enforcing this. If people want it, they'll port it. It'd
likely be a rare occurance it happens at all. (Maybe some really fast
text munger; I dunno.)

> [stuff about regular expressions]
> > 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.


Better? Perhaps. I would first want to know what is wrong with
existing regular expressions. (Now, I dislike the overuse of regexps,
and tend to avoid them in my code, but when you're writing editor code
or parsers it's a different story.) Consider:

1. Do you feel they could be improved in form alone, or
functionality?

2. What form should they take, it not the current form?

3. What function should they accomplish, that they do not
currently accomplish?

4. Is the action you're trying to take actually something you
should be using regexps for, or is there a better way?

> 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 +.


Just because something is old doesn't mean it's bad. Text is text.
That hasn't changed since 1968 or 1908 or 1809 or long before.
Only the content.

The method of handling it has gotten more complex, because we've gone
from purely academic uses to actual everyday useful uses.

> There has to be a simpler syntax that can be useful for
> interactive text search-and-replaces.


There might be. There are simpler syntaxes, but they usually trade
off on functionality. There are GUI regexp builders.

I'm definitely a fan of throwing things out the window when they need
to be. But the first thing to determine is what you're trying to
accomplish, and how throwing things away lets you accomplish it.

> 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. <snip more obscure things>


There are really two things at play here. The first is commonality.
Everyone uses backslashes for escaping, from C to bash. You need to
escape things, so backslash is as good as any, and everyone is
familiar with it. This is good.

Obscure feature creep is less good. I am not a fan of Perl's "a
kitchen sink for every occasion" philosophy (don't get me started
here), but if you start getting tons of special cases, maybe your
instincts are right: maybe we need something new. But maybe it's not
regular expressions, either.

> > That isn't to say people won't use them, especially if they're
> > simpler, but it probably won't be the main selling point of your
> > editor to _other people_.


> 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
> 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 .


Actually this is good, I think. If you're writing an editor to be
popular, it probably won't. If you're writing it to be useful to you,
it'll probably be popular with others who have similar needs.

> 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
> would not impede the command language I'm contemplating. If you take a
> look at the Sam editor[2], this is its main selling point, and this is
> another one I want to include.


Not sure what you're getting at here, but it seems interesting...

<snip>
> > I'm not sure how that's a problem. The same applies to // regexps.
> > They're just basically strings, except stored in a different type of
> > object with a few flags.


> Nono, they don't do string escapes. \n in a regex (//) means match a
> newline, not substitute this for 0x0a. So, you don't have to quote it
> with an extra backslash to get that meaning.

<snip>

Hmm, I think I see what you mean. You could just use '' though, which
does it for you:

irb> s = '\n'
=> "\\n"

<snip>
> and to match a backslash itself:
> "\\\\"
> which is horrendous. In a Ruby regex, /\\/ suffices.


Yes, this is a problem I've had with elisp regexps. Too many \\'s.
I've seen lines like \\\\\\\\\\\\\\\\\\\\ before. Really painful to
read.

ttyl,

--
Ryan Pavlik <(E-Mail Removed)>

"That's the first pratical line of thinking to
come out of your word hole since we first met." - 8BT

 
Reply With Quote
 
Robert Klemme
Guest
Posts: n/a
 
      10-10-2003

"Nikolai Weibull" <(E-Mail Removed)> schrieb im Newsbeitrag
news:(E-Mail Removed) t.se...
> * Robert Klemme <(E-Mail Removed)> [Oct, 09 2003 18:42]:
> > Since others have commented on various aspects of your posting I'll

only
> > throw my 2c at this:
> > > Also, is there any way of redefining the // operator for

constructing
> > > regular expression objects? I'm planning on implementing a new

regex
> > > syntax for the editor (to make searches/substitutions easier to
> > > describe).

> > Why do you want to change it? I find it quite flexible and expressive
> > (especially when using flag "x"). And especially if you want to

attract
> > rubyists to use TREC (The Ruby Editor to Come), then you should ensure
> > that their knowledge of ruby regexps is not obsoleted, since rx's will
> > likely play an important role in user defined extensions!


> Hehe. Yeah, that is true. So we'd need two separate constructs.


Yes, that might be better.

> > You can always define methods in Kernel like this:
> >
> > irb(main):002:0* module Kernel
> > irb(main):003:1> def rx(str)
> > irb(main):004:2> puts "building rx from '#{str}'"
> > irb(main):005:2> end
> > irb(main):006:1> end
> > => nil
> > irb(main):007:0>
> > irb(main):008:0* rx %q{(foo)+ \s+ (\w+)}
> > building rx from '(foo)+ \s+ (\w+)'
> > => nil
> > irb(main):009:0> rx '(foo)+ \s+ (\w+)'
> > building rx from '(foo)+ \s+ (\w+)'
> > => nil
> > irb(main):010:0>
> >
> > Which isn't too bad IMHO.
> >

> No, it isn't actually. Thank you for pointing this out. This could
> actually be the answer to my question. I'll have to think about this.
> I had totally forgot that we had very restrictive single-quoting
> contexts (and even the %q{}). Thanks,
> nikolai


You're welcome.

> P.S.
> I realize now that that last part may seem a bit sarcastic, but it
> isn't, I promise.
> D.S.


No offense taken.

Kind regards

robert

 
Reply With Quote
 
Robert Klemme
Guest
Posts: n/a
 
      10-10-2003

"Nikolai Weibull" <(E-Mail Removed)> schrieb im Newsbeitrag
news:(E-Mail Removed) t.se...
> To Vim's salvation comes the ability to easily
> define new syntax definitions and indentation definitions, which one has
> to agree, are a lot easier to create and alter than with Emacs (Emacs
> being perhaps more powerful though).


Which is a usual tradeoff: more flexibility typically introduces greater
complexity.

> My real point was that having OO around doesn't really help either. It
> doesn't add anything. Sure, you can make classes like Buffer and

Window,
> were is the real gain? I have tried to envision some OO structure for
> implementing Emacs like Major/Minor Modes and such, but I haven't been
> able to come to any satisfactory results. I mean, how is a Major Mode
> an object? Really? I guess it has a syntax definition, a separate
> keybinding mapping, an indentation callback, maybe something else? I
> just don't feel it adds anything though. I am, of course open to
> suggestions .


Well, the real power comes into play if you find a *reasonable* definition
of an abstract major mode class whose interface provides everything you
need from a major mode. Then you can introduce a clean separation of
concerns between the modes and the framework, i.e. the framework can deal
with modes in a uniform way and the modes encapsulate those things that
are special for them. These could be among others, indentation algorithms
(IMHO a classes in their own right), coloring schemes (maybe as well a
whole set of classes), tab conversion rules (think of makefiles which
don't like their tabs converted ), mode documentation (short and long),
mode keybindings... You can have a mode instance per file storing current
file related status. All these seem to me to obviously point to modes as
a class hierarchy (possibly with related class hierarchies).

> As useful? Please, my dear sir, there has to be something better than
> the way we describe regular expressions now.


Well, there might be. But consider, that many people are used to defining
regular expressions the way we do it today (apart from those that have to
use Word regular expressions ) that any other format could indeed be
worse for the sole reason of habituation.

> having to move my hand to the upper right corner of my
> keyboard all the time is a real pain.


? I have a key named "Esc" at that place. What kind keyboard do you
have? ))

> Even notepad has its uses. It can, for example, tell you if a file is
> smaller or greater than 65535 bytes very easily .


))

Anyway, I whish you good luck for this project. To me it sounds
promising.

Regards

robert

 
Reply With Quote
 
Frank Schmitt
Guest
Posts: n/a
 
      10-10-2003
"Simon Strandgaard" <none> writes:

> Frank Schmitt <(E-Mail Removed)> skrev i en
> nyhedsmeddelelse:4cfzi2lod6.fsf@scxw21.4sc...
>
> > class Base {
> > virtual Base* clone() = 0;
> > };
> >
> > class Derived1: public Base {
> > virtual Base* clone() { return new Derived1(*this); }
> > };

>
> This method requires typecasting if you want to do something like this:
>
> Derived *a = new Derived1();
> Derived *b = dynamic_cast<Derived*>(a->clone());
>
>
> Covariant return types is unfortunatly a relative new thing in the C++
> world.
>
> class Derived1: public Base {
> virtual Derived1* clone() { return new Derived1(*this); }
> };
>
> Derived *a = new Derived1();
> Derived *b = a->clone();


Arg. Yes, of course I meant clone() to have covariant return types.

>
> > > unittesting: AEditor has about 440 testcases and 1400 assertions.
> > > unittesting is annoying in C++. In Ruby its easy.

> >
> > Why is unittesting in C++ annoying? I have an application with 200+
> > testcases and 400+ assertions, written completely in C++.
> > The only thing that annoys me is that I can't easily add/remove tests
> > without recompiling - some day I'll have to write a ruby wrapper to do

> this
>
> Compiling is expensive on my Pentium350 which is the fastest machine I have.
> GCC2.96 was quite fast... I have not yet seen any fast result with GCC3.


Ah.. yes. GCC3 is definitely quite slow - but the Intel compiler is even
slower

> I like templates, I like many things in C++. If I had a faster machine, then
> there would be no problems


At work I use a 2.0 GHz P4, and even on that machine compile times are
annoying.

Thanks for your insights
frank

--
Frank Schmitt
4SC AG phone: +49 89 700763-0
e-mail: frankNO DOT SPAMschmitt AT 4sc DOT com
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
ANN: New low-cost XML Editor, XSLT Editor, XSLT Debugger, DTD/Schema Editor Stylus Studio Java 0 08-03-2004 03:53 PM
ANN: New low-cost XML Editor, XSLT Debugger, DTD/Schema Editor Stylus Studio XML 0 08-03-2004 03:21 PM
I need a text editor written with text draw calls Mark Hahn Python 0 09-01-2003 04:57 PM
XML Editor WYSIWYG Word processor-like validating XML Editor ?! Hatem KNANI XML 2 08-04-2003 03:22 PM



Advertisments