To be honest I think that all the whitespace retaining approaches kinda miss the point. The reason code is mannually formatted is only because it consists of characters in a grid aka text. To me manual formatting is a chore, most of the time I rely on paredits or codemirrors auto formatting capabilities anyways.
The ability to have a consistent idiomatic visual source structure enforced is a feature to me not a bug. cheers Jan > On 17.11.2014, at 20:19, Thomas Huber <th0mas.hu...@googlemail.com> wrote: > > Yes that s ounds quite reasonable to me > > Am Freitag, 14. November 2014 18:01:04 UTC+1 schrieb Jan-Paul Bultmann: >> >> Yeah this would be awesome, but sadly representing Clojure code as data is >> as hard as representing Java. >> All the reader macros make it a nightmare, and the closest thing you'll get >> is tools.analyzer AST nodes. >> >> Session is certainly a step in the right direction, and I wish more people >> would embrace it, >> but it works on text as well. Same pretty much goes for codeq, if that is >> not dead. >> >> One could define a Clojure subset that is valid EDN though, >> which would make everything from serialisable functions to a nano-pass >> compiler a lot easier. >> This has to be the first step imho. >> >> Cheers Jan >> >>> On 14 Nov 2014, at 17:09, atucker <agjf....@gmail.com> wrote: >>> re >>> As I understand it, Session and codeq are tools that somehow keep your code >>> in a database instead of plain text. >>> >>>> 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 clo...@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+u...@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+u...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. > > -- > 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. -- 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.