I wrote a couple of blog-posts on this topic - On Editing, and Clojure <http://blog.journeyman.cc/2013/09/on-editing-and-clojure.html>, and Editing and clojure revisited: this time, with structure! <http://blog.journeyman.cc/2013/09/yesterday-i-blogged-on-editing-clojure.html> I also wrote a bit of (very simple) code here <https://github.com/simon-brooke/fedit>.
The big lisp systems of the past often used in-core editors - the little toy editor I wrote is based on the editor in BBC Lisp, which in turn was based on the editor in Portable Standard Lisp. InterLisp had a much more powerful, graphical in-core editor called dedit. You might also find this document <http://www.ics.uci.edu/~andre/ics228s2006/teitelmanmasinter.pdf> interesting. On Friday, 14 November 2014 12:42:57 UTC, Thomas Huber wrote: > > Hi, here is an idea that has been in my mind for a while. I wonder what > you think about it. > > > In Clojure code is data, right? But when we program we manipulate flat > text files, not the data directly. > > Imagine your source code where a data structure (in memory). And > programming is done by manipulating this data structure. No text editor and > text files involved. > > Your editor directly manipulates the source data and later saves it on > disk (maybe as a text file). > > > These are the benefits I can think of: > > - It enables you to use any Clojure function to manipulate your source > „code“. Giving you hole new opportunities for refactoring.This functions > can be provides as library. > > > - Really nice auto complete. > > > - Visual programming. Source code can be represented in many different > ways (not just text) . The easiest example I can think of is color. It can > be represented as text of course (#23FF02) > > but that’s a quite bad interface for humans. Why not display the actual > color and provide a color picker? Or what about music notes? Or Math > formulars? Or what about a tree view to move and rename functions like > files? > > This could all be implemented in a way that every library can ship there > own „views“. I think this „views“ are basically macros that are not limited > to text. > > > - You don’t have to worry that you text files are in the same state as > your JVM (when developing interactive). You only work on your sourcedata > and it gets loaded into the JVM automatically. > > > - Answer questions about your source code. What is the most called > function? Who depends on this namespace? Where is this function used? What > is the biggest function? Thinks like that become easy. Again you can ship > this queries as a library. > > > > > The drawback is you can’t simply program using any text editor. You need a > special tool. But we have that anyway (syntax highlighting, paredit etc.). > Nobody programs using a bare text editor. > > > Maybe this idea is not new? What do you think? > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
