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?
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?
Vim runs everywhere. Are you sure that this is necessary?
Mike
Are you sure Vim was necessary? Emacs runs everywhere…
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)
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 B.
“I was born not knowing and have had only a little
time to change that here and there.”
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.
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:
As a number of folks have pointed out, “vim” has an excellent Ruby
scripting facility already.
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!
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.
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.
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.
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/
I jumped right into QtRuby (3, though, on Linux) using Caleb T.’
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.
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.
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.
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.
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.
