I know its a pain, but so is having to deal with spaces and tabs.  How about
telling the editor to convert tabs to spaces when entering text? Better than
leaving tabs in there.

Robert

On Jun 29, 2010 12:52 PM, "B Smith-Mannschott" <[email protected]>
wrote:

On Tue, Jun 29, 2010 at 17:08, Robert Casto <[email protected]> wrote:
> Can't we just move on ...
A few (fairly random) thoughts:

Wirth's Oberon system supplied a rich text editor with fonts/styles
and embedded images. All source was written in this editor, giving one
the option of embedding images in comments, choosing tab stops etc.
Later iterations ("Oberon System 3") also provided a compound-document
based GUI ("Gadgets"). But, alas while you could embed images and
indeed arbitrary chunks of GUI into your source code, say for
documentation, all this was ignored by the compiler. It'd have been
cool if you could have said something like:

myGui := [ actual, live functioning GUI embedded in source right here ]
myGui.doSomething;

"cool", but not really useful since Oberon's approach to GUI was such
that this kind of code-driven GUI programming was unheard of. The GUI
was a document you created interactively, it was not something you
wrote a boat-load of ugly unmaintainable code to produce (a'la Swing).

Didn't IBM's Visual Age (for Smalltalk, later for Java, a fore-runner
of Eclipse) store project source in some kind of a database? Didn't
that suck?

Sure, you could store augmented parse trees in place of source, but
diff/merge of tree-like structures is monumentally more difficult than
diff/merge of textual lines (which is nothing more than a flat
sequence). Witness, for example, the memory consumption of XML-aware
diff tools. Witness how few of them exist.

There has been quite a bit of research on structured editors: i.e.
editors where you manipulate your program at the level of the parse
tree, not as raw text. The results have been mixed. If you'd like to
experiment with the idea, you could try paredit.el, which provides
syntax-driven editing for lisp-like languages in emacs. Some people
even like it.

Speaking of Lisp... a Lisp would make this kind of thing so much
easier to experiment with. After all *code is data* is one of the
central concepts of Lisp-like languages.  For full editor
round-tripping, however, you'd have to figure out some way of working
comments into said data structure.


// ben


> On Tue, Jun 29, 2010 at 10:50 AM, Lyle <[email protected]> wrote:
>>
>> Reinier's Rules (ha!) are...
> --

> You received this message because you are subscribed to the Google Groups
> "The Java Posse" group...

-- 
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Reply via email to