Why don't we just create a special character called a Spab. Which has qualities of both. Made from unicorn farts of course :)
On Jun 30, 5:05 am, Robert Casto <[email protected]> wrote: > 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.
