New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A different approach for all delimiters ]}) #1

Closed
shaunlebron opened this Issue Sep 19, 2015 · 11 comments

Comments

Projects
None yet
3 participants
@shaunlebron

shaunlebron commented Sep 19, 2015

Thanks for making this experiment. Had a new idea to run by you:

  • Opening delimiters required.
  • Closing delimiters at the end of each line not allowed.
  • Closing delimiters inferred before the first line whose x falls behind its own.
  • Closing delimiters required for strings since whitespace is significant there.
(defn component
  "a hiccup style component.
  second line of docstring."
  [image-source
  (html
    [:div
     (if image-source
       [:img {:src image-source
              :on-click #(swap! app-state
                           update-in [:counter] inc
       [:span "no image"
     (for [[i msg] (map-indexed vector messages
       [:div {:style {:background (lookup-color i
        msg

This would allows us to remove most ]}) delimiters, not just ):

screen shot 2015-09-19 at 1 41 04 pm

Not sure how practical it would be for writing, but I think it reads okay.

@boxed

This comment has been minimized.

Show comment
Hide comment
@boxed

boxed Sep 20, 2015

Owner

I actually did try this, but I found it to be less readable.

Owner

boxed commented Sep 20, 2015

I actually did try this, but I found it to be less readable.

@darwin

This comment has been minimized.

Show comment
Hide comment
@darwin

darwin Sep 20, 2015

Interesting ideas. I've been hacking on Plastic Editor for ClojureScript for past couple weeks. It is not in good shape yet. But I would like to experiment with inferred parenthesis at some point. I would like to experiment with use of full retina pixel resolution and power of CSS to somehow display this structural information, while editor would not force you to do delimiter baby-sitting.

I'm open for (crazy) ideas :)

darwin commented Sep 20, 2015

Interesting ideas. I've been hacking on Plastic Editor for ClojureScript for past couple weeks. It is not in good shape yet. But I would like to experiment with inferred parenthesis at some point. I would like to experiment with use of full retina pixel resolution and power of CSS to somehow display this structural information, while editor would not force you to do delimiter baby-sitting.

I'm open for (crazy) ideas :)

@shaunlebron

This comment has been minimized.

Show comment
Hide comment
@shaunlebron

shaunlebron Sep 20, 2015

@boxed cool you thought of it too, did you notice its relation to Haskell's $ operator?

putStrLn (show (1 + 1)) -> putStrLn $ show $ 1 + 1

I think there's an applicable idea in here somewhere, maybe for better editing like in @darwin's editor. I'll keep thinking about it.

shaunlebron commented Sep 20, 2015

@boxed cool you thought of it too, did you notice its relation to Haskell's $ operator?

putStrLn (show (1 + 1)) -> putStrLn $ show $ 1 + 1

I think there's an applicable idea in here somewhere, maybe for better editing like in @darwin's editor. I'll keep thinking about it.

@boxed

This comment has been minimized.

Show comment
Hide comment
@boxed

boxed Sep 20, 2015

Owner

@darwin I think there are some things that will give you a huge bang for the buck compared to my inferred paren thing. First is: any ( on the first column of a line means that's a new form. Meaning you can close anything before, or create an error message there. This is hugely useful. Much much better than missing a ) and ending up with an error message at the end of the file.

Another thing is to just check that the indent matches the structure of the code. I've found this to be difficult because people (including Rich) format their code... let's say "creatively", and Clojure contains way too little information to be able to know if (foo x y z) means "call foo with x and then y and z are a pair" or "call foo, x and y is a pair and z is something else" or any of the other variants which you need to know to validate the indents :( I've done some work on this at https://github.com/boxed/clojure-validate-indent

Owner

boxed commented Sep 20, 2015

@darwin I think there are some things that will give you a huge bang for the buck compared to my inferred paren thing. First is: any ( on the first column of a line means that's a new form. Meaning you can close anything before, or create an error message there. This is hugely useful. Much much better than missing a ) and ending up with an error message at the end of the file.

Another thing is to just check that the indent matches the structure of the code. I've found this to be difficult because people (including Rich) format their code... let's say "creatively", and Clojure contains way too little information to be able to know if (foo x y z) means "call foo with x and then y and z are a pair" or "call foo, x and y is a pair and z is something else" or any of the other variants which you need to know to validate the indents :( I've done some work on this at https://github.com/boxed/clojure-validate-indent

@darwin

This comment has been minimized.

Show comment
Hide comment
@darwin

darwin Sep 20, 2015

@boxed my editor will be structural only, so that the user cannot run into unbalanced parens. My comment was more related to the display of the inherent structural information which is normally encoded as parens and the intent is communicated to the reader with line-breaks and indentation. I'm interested in new ways how display/communicate this information. Inferred parens is an approach which replaces some explicit parens with conventions (e.g. some of those map to line-break/indentation rules). Which I believe is promising and can lower cognitive load for a trained eye.

But I would like to go beyond text representation. I have zillions of pixels at my disposal. I would like to map that information to some clever graphical representation. Maybe even in 3d.

darwin commented Sep 20, 2015

@boxed my editor will be structural only, so that the user cannot run into unbalanced parens. My comment was more related to the display of the inherent structural information which is normally encoded as parens and the intent is communicated to the reader with line-breaks and indentation. I'm interested in new ways how display/communicate this information. Inferred parens is an approach which replaces some explicit parens with conventions (e.g. some of those map to line-break/indentation rules). Which I believe is promising and can lower cognitive load for a trained eye.

But I would like to go beyond text representation. I have zillions of pixels at my disposal. I would like to map that information to some clever graphical representation. Maybe even in 3d.

@darwin

This comment has been minimized.

Show comment
Hide comment
@darwin

darwin Sep 20, 2015

FYI, this is my two months old brain dump:
https://gist.github.com/darwin/d8fc8556e6fbdc7dee11

Note that some technical stuff is not relevant anymore, I have switched to Atom and wrote a replacement for rewrite-cljs from scratch.

darwin commented Sep 20, 2015

FYI, this is my two months old brain dump:
https://gist.github.com/darwin/d8fc8556e6fbdc7dee11

Note that some technical stuff is not relevant anymore, I have switched to Atom and wrote a replacement for rewrite-cljs from scratch.

@boxed

This comment has been minimized.

Show comment
Hide comment
@boxed

boxed Sep 21, 2015

Owner

Ah. Yea I agree that going beyond text mode is probably a good idea if you're going to go full on structural editor anyway.

Owner

boxed commented Sep 21, 2015

Ah. Yea I agree that going beyond text mode is probably a good idea if you're going to go full on structural editor anyway.

@shaunlebron

This comment has been minimized.

Show comment
Hide comment
@shaunlebron

shaunlebron Sep 22, 2015

@boxed @darwin thanks for all your thoughts on this. enjoyed reading your brain dump as well. I've started some further work on this inferred paren idea here: https://github.com/shaunlebron/parinfer I hope to have a working demo soon

shaunlebron commented Sep 22, 2015

@boxed @darwin thanks for all your thoughts on this. enjoyed reading your brain dump as well. I've started some further work on this inferred paren idea here: https://github.com/shaunlebron/parinfer I hope to have a working demo soon

@shaunlebron

This comment has been minimized.

Show comment
Hide comment
@shaunlebron

shaunlebron commented Nov 11, 2015

working demo and explanations: http://shaunlebron.github.io/parinfer/

@darwin

This comment has been minimized.

Show comment
Hide comment
@darwin

darwin Nov 11, 2015

Awesome work. I'm 100% sure this is going to be #1 on HackerNews tomorrow :) Congratulations Shaun!

darwin commented Nov 11, 2015

Awesome work. I'm 100% sure this is going to be #1 on HackerNews tomorrow :) Congratulations Shaun!

@boxed

This comment has been minimized.

Show comment
Hide comment
@boxed

boxed Nov 11, 2015

Owner
Owner

boxed commented Nov 11, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment