Forum: Ruby Scriptable text editor with Ruby?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
37aa3ec65ec47c5a3f9e2a80534837f3?d=identicon&s=25 Dolazy (Guest)
on 2007-01-03 17:17
(Received via mailing list)
Hi all!

Vim and emacs are text editor that can be scripted using internal
script languages. I'm thinking of writing a platform independent text
editor myself that uses the ruby language for executing scripts. The
host application would be written in C++ (+Qt) and it would somehow be
able to interact with ruby.

I think there are basically two ways of implementing this interaction:
- using IPC
- command line interaction (host executes the ruby script with
parameters and catches the output)

IPC is the most powerful I think, but then again I have various options
to achieve this communication:
- TCP
- XmlRpc
- shared memory

I'm very new to the concept of inter-process-communication and I would
greatly appreciate your insights on how I would best proceed to achieve
this interaction.

Or maybe there is a more obvious and straightforward approach that I
overlooked?

Best regards,
Francis
9a4ae17201525474ec26e5d89b66477e?d=identicon&s=25 Michael P. Soulier (Guest)
on 2007-01-03 17:45
(Received via mailing list)
On 1/3/07, Dolazy <francis.rammeloo@gmail.com> wrote:
> Hi all!
>
> Vim and emacs are text editor that can be scripted using internal
> script languages. I'm thinking of writing a platform independent text
> editor myself that uses the ruby language for executing scripts. The
> host application would be written in C++ (+Qt) and it would somehow be
> able to interact with ruby.

Vim runs everywhere. Are you sure that this is necessary?

Mike
83ca41657a99b65d99889abe712ba5e2?d=identicon&s=25 Jason Roelofs (Guest)
on 2007-01-03 17:45
(Received via mailing list)
Embed the Ruby interpreter in the text editor itself? Then just make
certain
functions available to Ruby and script away.

Jason
37aa3ec65ec47c5a3f9e2a80534837f3?d=identicon&s=25 Dolazy (Guest)
on 2007-01-03 18:01
(Received via mailing list)
Michael P. Soulier schreef:

> Vim runs everywhere. Are you sure that this is necessary?
>
> Mike

Are you sure Vim was necessary? Emacs runs everywhere... :p
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2007-01-03 18:19
(Received via mailing list)
On 1/3/07, Dolazy <francis.rammeloo@gmail.com> wrote:
>
> Michael P. Soulier schreef:
>
> > Vim runs everywhere. Are you sure that this is necessary?
> >
> > Mike
>
> Are you sure Vim was necessary? Emacs runs everywhere... :p

but vi *must* run everywhere (According to POSIX). :)

To the OP:

Both editors run everywhere and in my opinion, if you're not planning
on building a cross platform TextMate clone that is at least 95% as
good, you won't pry anyone from vim, emacs, *or* TextMate.

But if you're looking to try something different, or build the perfect
editor for you, have fun.  I know I'd at least play around with yet
another Ruby enabled editor.  (Though QT is yucky)
Ff9e18f0699bf079f1fc91c8d4506438?d=identicon&s=25 James Britt (Guest)
on 2007-01-03 18:29
(Received via mailing list)
Dolazy wrote:
> Hi all!
>
> Vim and emacs are text editor that can be scripted using internal
> script languages. I'm thinking of writing a platform independent text
> editor myself that uses the ruby language for executing scripts.

Vim can do that now.  Build it with Ruby support and you can drive the
editor with Ruby.


--
James Britt

"I was born not knowing and have had only a little
  time to change that here and there."
  - Richard P. Feynman
37aa3ec65ec47c5a3f9e2a80534837f3?d=identicon&s=25 Dolazy (Guest)
on 2007-01-03 18:31
(Received via mailing list)
Gregory Brown schreef:

> but vi *must* run everywhere (According to POSIX). :)
>
> To the OP:
>
> Both editors run everywhere and in my opinion, if you're not planning
> on building a cross platform TextMate clone that is at least 95% as
> good, you won't pry anyone from vim, emacs, *or* TextMate.
>
> But if you're looking to try something different, or build the perfect
> editor for you, have fun.  I know I'd at least play around with yet
> another Ruby enabled editor.  (Though QT is yucky)

Thanks :-)

This is really a pet project and I develop it in the first place to
deal with some of my specific needs (gdb integration). And also because
I want to learn Qt.

Btw I use Vim as primary editor.
37aa3ec65ec47c5a3f9e2a80534837f3?d=identicon&s=25 Dolazy (Guest)
on 2007-01-03 18:53
(Received via mailing list)
> Embed the Ruby interpreter in the text editor itself? Then just make certain
> functions available to Ruby and script away.
>
> Jason

That would be one of those obvious approaches that I couldn't think of
myself.. Thanks!
3bb23e7770680ea44a2d79e6d10daaed?d=identicon&s=25 M. Edward (Ed) Borasky (Guest)
on 2007-01-03 18:55
(Received via mailing list)
Dolazy wrote:
> Hi all!
>
> Vim and emacs are text editor that can be scripted using internal
> script languages. I'm thinking of writing a platform independent text
> editor myself that uses the ruby language for executing scripts. The
> host application would be written in C++ (+Qt) and it would somehow be
> able to interact with ruby.
>
Well, given QtRuby, you probably don't really need C++ at all -- you
could do it all in Ruby. But I'm not sure what the most recent status of
QtRuby is, and there is always the licensing gotcha -- you have to use
Qt 4 for open source Windows projects. If you use another GUI toolkit,
there are a number with Ruby bindings. For that matter, most of them
have some kind of text editor widget built in, which makes life even
easier.
>
> I'm very new to the concept of inter-process-communication and I would
> greatly appreciate your insights on how I would best proceed to achieve
> this interaction.
>
> Or maybe there is a more obvious and straightforward approach that I
> overlooked?
>
Two comments:

1. As a number of folks have pointed out, "vim" has an excellent Ruby
scripting facility already.
2. Rather than delving into issues of low-level implementation,
interprocess communication vs. shelling out to a command like vs.
whatever, I'd recommend a more agile and pragmatic approach. Pick a
toolkit, find a Windows user, a Mac user and a Linux user, set up a
project on RubyForge and start building the thing!


--
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/

If God had meant for carrots to be eaten cooked, He would have given
rabbits fire.
896cfc242a7762467c2a0b2af86598e5?d=identicon&s=25 Simon Strandgaard (Guest)
on 2007-01-03 20:14
(Received via mailing list)
On 1/3/07, Dolazy <francis.rammeloo@gmail.com> wrote:
[snip stuff about ruby/c++]
> Or maybe there is a more obvious and straightforward approach that I
> overlooked?

have you considered writing the entire editor in ruby and
then use ruby qt.. so you don't use any c++?

Ruby is good at string manipulation, so its possible
to do the entire syntax coloring in ruby. I think
this task is pretty big in c++.
Cf5cd6ae06288f4e19748871ee90f5f0?d=identicon&s=25 Thomas Mueller (Guest)
on 2007-01-03 23:16
(Received via mailing list)
Hi,

You might want to have a look at Java 6. I have just installed that
yesterday and haven't played around with it at all yet, but from what
I read on the website it's integration with scripting languages might
make it relatively easy to include Ruby scripting in your text editor.

I realise there would be quite a few disadvantages to this approach
(need the runtime, need a brand new runtime, cannot code it in
Ruby...) but it might be worth looking into this.

Thomas


2007/1/4, Simon Strandgaard <neoneye@gmail.com>:
Ea24c17719a975fb38c107a60f4b3802?d=identicon&s=25 Vincent Fourmond (Guest)
on 2007-01-03 23:56
(Received via mailing list)
M. Edward (Ed) Borasky wrote:
> could do it all in Ruby.
I can only agree to that. For what I experience, Qt4 1.4.7 is pretty
stable, much more than its predecessors. But I think you'll need a bit
of practice with the C++ classes before coding direcly with Qt/Ruby.

  Well, have fun !

	Vince
6ab5d790020776e4d4843b8f38ab4c69?d=identicon&s=25 Jeroen Budts (Guest)
on 2007-01-04 00:03
(Received via mailing list)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2007-01-03 23:15, Thomas Mueller wrote:
> You might want to have a look at Java 6. I have just installed that
> yesterday and haven't played around with it at all yet, but from what
> I read on the website it's integration with scripting languages might
> make it relatively easy to include Ruby scripting in your text editor.

I would suggest to have a look at jEdit: http://jedit.org

It's a very nice and open source editor, written in java and has
powerful support for macro's (amongst other nice features such as
plugins etc). By default macro's are written in BeanShell (one of the
scripting languages for the JVM), but if you install the
SuperScript-plugin and combine it with JRuby you can write macro's in
Ruby.

You might also want to have a look at the Ruby plugin for jEdit:
http://rubyjedit.org/

greetz,
Jeroen


- --
<TeRanEX/>
 --- e-mail:   jeroen@lightyear.be - jid: teranex@jabber.org
 --- blog: http://budts.be/weblog/ - cv:  http://budts.be/jeroen/
 --- projects: http://lightyear.be - pgp: 0x8B7B774A

___________________________________
GetFirefox.com - rediscover the web

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFnDXuH04wF4t7d0oRAhLUAJ9DfzWru8CXazwTQsulNfG6uy0PbwCffTZz
uL40zRVH3jPItSgRtYOPY4s=
=cISC
-----END PGP SIGNATURE-----
Cb48ca5059faf7409a5ab3745a964696?d=identicon&s=25 unknown (Guest)
on 2007-01-04 00:17
(Received via mailing list)
On Thu, 4 Jan 2007, Dolazy wrote:

> - command line interaction (host executes the ruby script with
> parameters and catches the output)

- using vim

it already does all this!  check out the man pages.

regards.

-a
3bb23e7770680ea44a2d79e6d10daaed?d=identicon&s=25 M. Edward (Ed) Borasky (Guest)
on 2007-01-04 04:47
(Received via mailing list)
Vincent Fourmond wrote:
>>> able to interact with ruby.
>   Well, have fun !
>
> 	Vince
>
>
I jumped right into QtRuby (3, though, on Linux) using Caleb Tennis'
book from Pragmatic. I can't begin to even *read* C++, much less write
it! :) If QT4/QT4-Ruby are "upward compatible", it shouldn't be too
difficult. I just wish the bigger brothers of QTRuby, Korundum and
Kommander, were available on Macs and Windows. It's *almost* worth
putting up with "KDE bloat" for them. :)

--
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/

If God had meant for carrots to be eaten cooked, He would have given
rabbits fire.
8ae46ae3170a36a0f79ea109ef0ee2e7?d=identicon&s=25 Tim X (Guest)
on 2007-01-04 05:21
(Received via mailing list)
"Dolazy" <francis.rammeloo@gmail.com> writes:

> - command line interaction (host executes the ruby script with
> this interaction.
>
> Or maybe there is a more obvious and straightforward approach that I
> overlooked?
>

Although I've not looked at it in any detail, there is an emacs->ruby
interface
which allows you to extend emacs functionality with ruby code in a
similar way
to how functionality is extended with elisp.

I would strongly recommend leveraging an existing editor - writing an
editor is
a non-trivial task and many many code years have been put into vim and
emacs.
Take advantage of this to allow you time to concentrate on the bits you
really
want to achieve.

Note that if you don't like emacs (many don't) I believe vim has the
ability to
achieve what you want. A few people from the common lisp community have
been
working on an interface between vim and common lisp to provide a more
high
level development environment (similar to emacs + slime). You can
probably
steal ^H^H^H^H^H borrow some of their ideas to provide a way of
interfacing/extending vim with ruby scripts/code.

HTH

Tim
8ae46ae3170a36a0f79ea109ef0ee2e7?d=identicon&s=25 Tim X (Guest)
on 2007-01-04 05:31
(Received via mailing list)
"Simon Strandgaard" <neoneye@gmail.com> writes:

> Ruby is good at string manipulation, so its possible
> to do the entire syntax coloring in ruby. I think

syntax highlighting can be non-trivial to get right, paticularly with
larger
files (see some of the debates in emacs and xemacs community as an
example).

What I think would be really good is semantic highlighting rather than
syntax
highlighting - this may sound crazy, but I find syntax problems to be
the more
trivial bugs to squash. Highlighting which gave more information on the
"meaning" of what you are coding would probably provide more valuable
information. The problem of course is that the editor wold then need to
understand more than the basic syntax rules of the language you are
coding in -
essentially, it would need an interpreter, either built-in or closely
integrated.

I've not really given a lot of thought to this, it just strikes me that
nearly
every editor does syntax highlighting and maybe its time to re-evaluate
the
paradigm and see if, given faster cpus, greater memory and larger
storage, it
might not be time to look at doing things differently.

Tim
245cfab887781bdf3f53178b794c42dc?d=identicon&s=25 Alexandru E. Ungur (Guest)
on 2007-01-04 12:24
(Received via mailing list)
>>> sender: "Dolazy" date: "Thu, Jan 04, 2007 at 02:30:10AM +0900" <<<EOQ
> [..]
>
> This is really a pet project and I develop it in the first place to
> deal with some of my specific needs (gdb integration). And also because
> I want to learn Qt.
>
> Btw I use Vim as primary editor.
For vim+gdb integration, you can check out:
http://clewn.sourceforge.net/

Cheers,
Alex
4299e35bacef054df40583da2d51edea?d=identicon&s=25 James Gray (bbazzarrakk)
on 2007-01-04 14:16
(Received via mailing list)
On Jan 3, 2007, at 10:30 PM, Tim X wrote:

> What I think would be really good is semantic highlighting rather
> than syntax highlighting - this may sound crazy, but I find syntax
> problems to be the more trivial bugs to squash. Highlighting which
> gave more information on the "meaning" of what you are coding would
> probably provide more valuable information.

This is pretty much how TextMate works.

Language grammars divide the document you are editing into "scopes,"
which might be something like "entity.name.type.class.ruby."  Themes
then color these elements for syntax highlighting.

But they are used in many other places by the editor.  You can write
commands that work only inside certain scopes, change editor
behaviors when working with certain scopes, etc.

It's quite powerful.

James Edward Gray II
Bc368ef524130e8d0deb386de961e24a?d=identicon&s=25 Suraj Kurapati (snk)
on 2007-01-04 20:53
Dolazy wrote:
> I'm thinking of writing a platform independent text
> editor myself that uses the ruby language for executing scripts. The
> host application would be written in C++ (+Qt) and it would somehow be
> able to interact with ruby.

Why start from scratch? Take over an existing, defunct open source
project:

  http://aeditor.rubyforge.org/
896cfc242a7762467c2a0b2af86598e5?d=identicon&s=25 Simon Strandgaard (Guest)
on 2007-01-06 19:18
(Received via mailing list)
On 1/3/07, Dolazy <francis.rammeloo@gmail.com> wrote:
[snip out of context]
> I'm thinking of writing a platform independent text
> editor myself that uses the ruby language for executing scripts.
[snip]

I don't know what exactly your goal is for this editor,
but if you want it to be great then take a look at
what other great editors is doing.

IMO TextMate is the best editor I have ever tried,
and was the reason I abandoned my own editor
project: http://aeditor.rubyforge.org/


btw: Know your enemy (maybe I should this one day)
http://en.wikipedia.org/wiki/The_Art_of_War
37aa3ec65ec47c5a3f9e2a80534837f3?d=identicon&s=25 Dolazy (Guest)
on 2007-01-06 19:30
(Received via mailing list)
Simon Strandgaard wrote:

> I don't know what exactly your goal is for this editor,
> but if you want it to be great then take a look at
> what other great editors is doing.
>
> IMO TextMate is the best editor I have ever tried,
> and was the reason I abandoned my own editor
> project: http://aeditor.rubyforge.org/

Well TextMate has two important drawbacks: it's Mac only and it's not
free. I'll give the evaluation version a try on my Mac at work to see
if I it can inspire me (hopefully not discourage me if it's too
good!)..

> btw: Know your enemy (maybe I should this one day)
> http://en.wikipedia.org/wiki/The_Art_of_War

Hah, thanks ;)
45196398e9685000d195ec626d477f0e?d=identicon&s=25 Trans (Guest)
on 2007-01-06 19:30
(Received via mailing list)
Suraj Kurapati wrote:
> Dolazy wrote:
> > I'm thinking of writing a platform independent text
> > editor myself that uses the ruby language for executing scripts. The
> > host application would be written in C++ (+Qt) and it would somehow be
> > able to interact with ruby.
>
> Why start from scratch? Take over an existing, defunct open source
> project:
>
>   http://aeditor.rubyforge.org/

+1

Simon?

T.
37aa3ec65ec47c5a3f9e2a80534837f3?d=identicon&s=25 Dolazy (Guest)
on 2007-01-06 19:30
(Received via mailing list)
Simon Strandgaard wrote:

> have you considered writing the entire editor in ruby and
> then use ruby qt.. so you don't use any c++?
>
> Ruby is good at string manipulation, so its possible
> to do the entire syntax coloring in ruby. I think
> this task is pretty big in c++.

:) Syntax coloring could be implemented as a ruby plugin.
And all these advanced concepts I will try to delegate to libraries as
much as I can.
37aa3ec65ec47c5a3f9e2a80534837f3?d=identicon&s=25 Dolazy (Guest)
on 2007-01-06 19:30
(Received via mailing list)
Thanks for your suggestions Edward, Vince (+others).

However, running a complete text editor application as a ruby script;
wouldn't that be slow?

The idea of having a C++ skeleton application with lot's of ruby
plugins seems more appealing to me. It would be faster and still
strongly customizable. However, if you think differently then please
share your insights on this..
896cfc242a7762467c2a0b2af86598e5?d=identicon&s=25 Simon Strandgaard (Guest)
on 2007-01-06 19:30
(Received via mailing list)
On 1/5/07, Trans <transfire@gmail.com> wrote:
> >   http://aeditor.rubyforge.org/
>
> +1
>
> Simon?

I will grant admin if anyone feels like continuing aeditor.
Actually I did the same yesterday with http://ros.rubyforge.org/
after talk in the ros forum.

The reason I stopped working on these things was that
I got a job that took up all my available time.
Only profesional work, no focus on the social side.
So I quit that job and started my own company,
hoping to do it better. I have plenty of time now,
but its allocated for the company beast.

If someone payed food/rent then I would have
been happy working entirely on ruby projects.

The person(s) that has interest in the aeditor project,
is free to do whatever she likes. Change website,
license, code. Write a entirely new aeditor. Add code,
licenses, websites, etc. I don't mind as long as its
for a good purpose.
Bc368ef524130e8d0deb386de961e24a?d=identicon&s=25 Suraj Kurapati (snk)
on 2007-01-07 01:30
Dolazy wrote:
> However, running a complete text editor application as a ruby script;
> wouldn't that be slow?
>
> The idea of having a C++ skeleton application with lot's of ruby
> plugins seems more appealing to me. It would be faster

You cannot assume that things will be faster just because you use a
low-level language. If this were true, then all 3D games would be
written in straight machine code... forget about assembler!

Efficiency comes *primarily* from good choice of data structures and
algorithms which are best suited to tackle the problem at hand. Whether
or not the programming language being used is "close to the metal" is,
at best, of secondary importance.

> and still strongly customizable.

Good, it seems you are implicitly seeking a higher level language so
that you can better manage complexity. (Google "No Silver Bullet" for
details.)
37aa3ec65ec47c5a3f9e2a80534837f3?d=identicon&s=25 Dolazy (Guest)
on 2007-01-07 02:18
(Received via mailing list)
I still think an application written entirely in ruby would be slow.
Eclipse is slower than Visual Studio, Azureus is slower than
ĀµTorrent.. Higher level languages are slower, even if they use optimal
data structures. I know that this doesn't have to be this way
theoretically, and that higher-level languages allow more compiler
optimization and all. But still you see that programs written in C/C++
are almost always faster than those written in Java, or other
high-level languages (esp ruby!).

I'm in favor of higher level languages, but wanting to make my
application customizable using external scripts does not mean my
language is too low-level. It just means that I want to make my program
programmable.
Cd3312ac93f768b1b449af457c0fca06?d=identicon&s=25 Daniel Finnie (Guest)
on 2007-01-07 02:29
(Received via mailing list)
I don't know much about Eclipse and VS so I won't comment on those;
however, uT and Azureus aren't both trying to be lightweight so, IMO, it
is unfair to compare them like that.

Also, I think you have to remember that you are coding a text editor.
On any modern computer it honestly won't matter what language you do it
in.

dan
37aa3ec65ec47c5a3f9e2a80534837f3?d=identicon&s=25 Dolazy (Guest)
on 2007-01-07 03:15
(Received via mailing list)
Yeah, you could be right..

I didn't want to go off-topic, but I couldn't resist writing my
previous post. I hope I didn't open pandora's box now.

Francis
37aa3ec65ec47c5a3f9e2a80534837f3?d=identicon&s=25 Dolazy (Guest)
on 2007-01-07 03:27
(Received via mailing list)
I have taken a look at embedding and Swig.

Hmm... I'm very unsure about them.

Swig seems to assume that you want to take away the main() method and
treat the C++ code as a shared library. It's not really the same as
interprocess communication.

The embedding solution also provides one way interaction. The C++
program calls ruby, but not the other way around. There might be ways
around this, using callbacks or so. I'd like to learn more...

I suspect that IPC using XmlRpc is the most powerful solution (and easy
to implement).

I am eager to learn your (anyone's) insights.
Bc368ef524130e8d0deb386de961e24a?d=identicon&s=25 Suraj Kurapati (snk)
on 2007-01-07 03:35
Dolazy wrote:
> Swig seems to assume that you want to take away the main() method and
> treat the C++ code as a shared library. It's not really the same as
> interprocess communication.
>
> The embedding solution also provides one way interaction. The C++
> program calls ruby, but not the other way around. There might be ways
> around this, using callbacks or so. I'd like to learn more...
>
> I suspect that IPC using XmlRpc is the most powerful solution (and easy
> to implement).

There is an easier way than having ruby in a separate process and having
to do IPC via RPC. Simply run ruby within a pthread and give it a SWIG
interface to your C++ app.


== Option1

If you cannot allow the Ruby thread to asynchronously use your C++ app,
then you can set up a mutual exclusion scheme where either (1) the C++
app or (2) the Ruby thread is active at a time. You would then have to
provide a way to transfer/relay control between them.

In fact, this is how my Ruby-VPI project works. It embeds a Ruby
interpreter into a C program that runs within a Verilog.

  http://ruby-vpi.rubyforge.org


== Option2

If that's not the kind of interaction you want, then see:

  http://metaeditor.sourceforge.net/embed/
37aa3ec65ec47c5a3f9e2a80534837f3?d=identicon&s=25 Dolazy (Guest)
on 2007-01-07 03:55
(Received via mailing list)
Java is attractive for several reasons. A powerful gui, speed is very
good, and there's JRuby... But I want to explore new territory. That's
why I want to choose Qt, because it's something new for me. Also
because I am a C++ developer I want to improve my cv a bit ;)

Francis
B780ee0ee1480454a85df58536702f63?d=identicon&s=25 Alder Green (alder)
on 2007-01-07 04:40
(Received via mailing list)
On 1/3/07, Dolazy <francis.rammeloo@gmail.com> wrote:
> ...

As you probably already told by numerous people, Vim does that already.

Emacs is supposed to have something like that as well, but it hardly
works.

Whereas I managed to get Vim's Ruby support running out of the box on
several flavours of Linux and even freaking Windows...!  Respect.

-Alder
A0ff85672de505e7bfa2fe17e85581cc?d=identicon&s=25 Paulus Esterhazy (Guest)
on 2007-01-07 20:02
(Received via mailing list)
Dolazy schrieb:
> Java is attractive for several reasons. A powerful gui, speed is very
> good, and there's JRuby... But I want to explore new territory. That's
> why I want to choose Qt, because it's something new for me. Also
> because I am a C++ developer I want to improve my cv a bit ;)
>
> Francis

Be sure to look at http://software.jessies.org/Evergreen/ for some
insipiration. (Also remember, Java isn't evil anymore now!)

Paulus
7b4707f974af261f71943e1f2046c9ee?d=identicon&s=25 SonOfLilit (Guest)
on 2007-01-07 21:56
(Received via mailing list)
When embedding, you can add an extention that implements a ruby API to
your editor and thus the communication will be both ways.
37aa3ec65ec47c5a3f9e2a80534837f3?d=identicon&s=25 Dolazy (Guest)
on 2007-01-19 16:30
(Received via mailing list)
That's attractive of course. I will check out this editor thoroughly
and let you know something.
3cb4fdcf13aad6a7dcae83876b0e784e?d=identicon&s=25 Josef 'Jupp' Schugt (Guest)
on 2007-01-19 16:30
(Received via mailing list)
* Gregory Brown, 01/03/2007 06:17 PM:
> but vi *must* run everywhere (According to POSIX). :)

line-mode ex is scriptable. The TUI that can be started using
':visual' (hence its commonly known name 'vi') isn't. ex's ancestor
ed is scriptable as well. I sometimes use the latter for shell script
controlled in-place editing of files to avoid unnecessary security
issues resulting from the creation and deletion of temporary files
(that is one of the largest source of harmful security holes known to
authors of shell scripts). It is a pity that many people only know
sed (wich is nothing but a stripped-down version of ed only being
capable to handle streams) because they are doomed to introduce such
problems.

Jupp
37aa3ec65ec47c5a3f9e2a80534837f3?d=identicon&s=25 Dolazy (Guest)
on 2007-01-19 16:31
(Received via mailing list)
Qt provides lots of functionality for free that you had to implement in
your editor. I think I will continue on my own path.
This topic is locked and can not be replied to.