freeride-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[FR-devel] Newbie to freeride.


From: Yohanes Santoso
Subject: [FR-devel] Newbie to freeride.
Date: 05 May 2002 17:59:45 -0700
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1

Hi all,

As the customary for a new member, I'd like to introduce myself. I
live in Seattle, working daytime as a programmer. My daytime job
requires me to use Java, elisp and ksh (korn shell for those from win
background). I myself have been in the computer industry for only 5
years. I'm versed (or used to be) in ML, Prolog, Perl, C and C++ (plus
those above). My ruby day started around 6 months ago.

My main motive in joining this team is to create an remacs. As some of
you may notice, I am the person who asked about existance of emacs in
ruby language in ruby-talk.

I feel that emacs is starting to get old with its single-threadedness
and its difficulty in incorporating external widget.

I use emacs for almost everything. I read mail, news, do calendaring,
and everyday stuff from emacs except web browsing. However, it has not
been as enjoyable as it was. I started to notice some shortcomings:
downloading mail would cause the whole process to hung, and I have to
go to a web browser to open a url.

gnus probably is to blame for causing the whole emacs to
hung. However, modifying gnus so that it performs async i/o is
counter productive because the problem is not in gnus. The problem
lies in emacs inability to do threading.

Currently w3 is the emacs' web browser. It is so oh primitive compared
to other browsers. I think the w3 team is misguided in implementing
that. It is an unnecessary work as they could have embedded the gecko
or netscape browser (w3 started before gecko, but after the
NN4). However, due to the difficulty in embedding external widget
within emacs, the w3 team decided to implement a new browser. This is
sad because the single-threadedness of emacs cause the w3 browser to
be unusable for daily basis.

I asked around in both emacs and xemacs groups for multi-threaded
support and a better way to embed external widget. The answers I have
been getting ranges from 'no way' to 'impossible' because making emacs
multi-threaded will likely break many existing libraries.

Then I came across freeride. Take a look at the doc, see the current
cvs, and I think the idea of using bus in place of emacs buffer is
nice and cleaner too.

I hope by the time rubyride is ready for release, there is already a
lisp->ruby converter so that all those rich libraries from emacs are
not wasted.

Does my motive run against Curt's and Rich's vision? 

If not then I'd like to start by creating a new plugin: BufferFactory
and Buffer. Buffer will be character-addressable, and serve as the
model in the MVC model. Modification to the content of the buffer will
result in two notifications, pre and post change notifications, to all
subscriber. The notification will be quite detailed so as to allow the
next plugin: BufferUndo.

Each Buffer can optionally be associated with a BufferUndo which will
record changes made to Buffer.

Perhaps notification is not a good name. 'Hook' seems more appropriate
as modification to content by other plugin is allowed. For example, if
there is an AutoIndent plugin, it would subscribe to the pre-change
notification of buffer A; then when A changes, it will send a
pre-change notification to the AutoIndent plugin. At that time
AutoIndent can opt to modify the nature of the changes (add/extract a
few space).

Then there can be another plugin, Mode, which associates several
plugin to the appropriate hook from Buffer. For example, editing a C
code would require CAutoIndent, CHighlighting, etc, to be associated
with Buffer.

Basically Buffer will be a 'dumb' storage with very few native
functionalities such as determining min point, max point, curr
point. Other plugins are added to provide functionalities: AutoIndent,
LineAddressable, LineCounter, Undo, Redo, Region, Rectangle, Mode,
etc.

How dumb is a Buffer? Could be so dumb that it uses array as the
storage method, or could be as smart as having virtual memory manager
so that it can handle terabytes of data. But whatever the underlying
storage method, the outside world shouldn't be too concerned.

Very emacs-ish? Well, that's the most flexible editor out there. It'd
be hard to find anything more flexible than it. Very complicated? Not
really.


YS.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]