4 ms·

I would call the fixed indentation just plain wrong in the examples. No lisp-aware editor will indent it like that. They specify a couple core forms that have a

by bjoli 6y ago

I would call the fixed indentation just plain wrong in the examples. No lisp-aware editor will indent it like that. They specify a couple core forms that have a body, which is indented "semantically" and the rest is treated like functions where new lines are indented to the first argument. Outside (apparently) clojurespace there has never been any bigger disagreement whatsoever regarding this. The article mentions this. But why was there ever a discussion? The hoards of non-lispers going to clojure?

lispm 6y ago
Actually the Lisp tradition has provided extensive support for formatting code. Common Lisp has this built in, in the form of pretty printing. Various IDEs have some degree of formatting rule support built-in. See for example: https://dspace.mit.edu/bitstream/handle/1721.1/6503/AIM-1102.pdf https://dspace.mit.edu/bitstream/handle/1721.1/6503/AIM-1102... XP, A Common Lisp Pretty Printing System, 1989 by Richard C. Waters Interlisp dealt with code formatting for its support of true structure editing.
morelisp 6y ago
> No lisp-aware editor will indent it like that. Emacs Lisp has an entire form for controlling macro indenting like that. https://www.gnu.org/software/emacs/manual/html_node/elisp/Indenting-Macros.html https://www.gnu.org/software/emacs/manual/html_node/elisp/In...
- bjoli 6y ago
  No. That is a macro specifying how it should be indented, which is a great idea. Say if I as a macro writer could specify semantically what the macro arguments are. if I were to invent the let form, I would have (name binding-form body...) And have the editor properly indenting the body 2 spaces in (or whatever the editor specified). it would remove the little manual indenting I have to do myself (mostly because I haven't told Emacs how to indent some rarely seen forms).
kazinator 6y ago
Your comment is a bit unclear. Can you give an example of what you think no Lisp-aware editor will produce? > They specify a couple core forms that have a body, which is indented "semantically" and the rest is treated like functions where new lines are indented to the first argument. Your "they" looks like it refers to "examples", which is the first (actually, only) plural word that we encounter in a leftward scan from the pronoun. I think it's actually supposed to refer to "lisp-aware editors". Firstly, that is not quite right. There is no fixed core of forms that have a body, because user-defined macros extend that repertoire. You have to teach that to your editor, in the light of what projects you are editing. For instance, in Vi, the ":set lisp" mode has an associated "lispwords" variable which holds a list of the symbol names that are to be treated as operators that have a body rather than functions. But the code in the Semantic Clojure Formatting page linked to by the submission is in fact exemplifying this formatting. It shows operators that have a body being indented, and function calls exhibiting argument alignment. Can you cite an example of what you think is wrong? The only exception I see is the "narrow format" for function calls. But that's not an invention from the Clojure world. I've resorted to that narrow format myself, in code that is deeply nested and hitting the maximum column limit of the surrounding coding convention. (deeply (nested |___|___| ......................... (aargh |__|___|__ too |___|___| brick wall cramped |_|___|__ here |___|___| I don't like it very much; I prefer to refactor the code to avoid it, if possible. But if you put a line break immediately after the function name, then that is realy the only sensible indentation you can follow.

by bjoli 6y ago

lispm 6y ago

Actually the Lisp tradition has provided extensive support for formatting code. Common Lisp has this built in, in the form of pretty printing. Various IDEs have some degree of formatting rule support built-in. See for example: https://dspace.mit.edu/bitstream/handle/1721.1/6503/AIM-1102.pdf https://dspace.mit.edu/bitstream/handle/1721.1/6503/AIM-1102... XP, A Common Lisp Pretty Printing System, 1989 by Richard C. Waters Interlisp dealt with code formatting for its support of true structure editing.

morelisp 6y ago

> No lisp-aware editor will indent it like that. Emacs Lisp has an entire form for controlling macro indenting like that. https://www.gnu.org/software/emacs/manual/html_node/elisp/Indenting-Macros.html https://www.gnu.org/software/emacs/manual/html_node/elisp/In...

bjoli 6y ago
No. That is a macro specifying how it should be indented, which is a great idea. Say if I as a macro writer could specify semantically what the macro arguments are. if I were to invent the let form, I would have (name binding-form body...) And have the editor properly indenting the body 2 spaces in (or whatever the editor specified). it would remove the little manual indenting I have to do myself (mostly because I haven't told Emacs how to indent some rarely seen forms).

kazinator 6y ago

Your comment is a bit unclear. Can you give an example of what you think no Lisp-aware editor will produce? > They specify a couple core forms that have a body, which is indented "semantically" and the rest is treated like functions where new lines are indented to the first argument. Your "they" looks like it refers to "examples", which is the first (actually, only) plural word that we encounter in a leftward scan from the pronoun. I think it's actually supposed to refer to "lisp-aware editors". Firstly, that is not quite right. There is no fixed core of forms that have a body, because user-defined macros extend that repertoire. You have to teach that to your editor, in the light of what projects you are editing. For instance, in Vi, the ":set lisp" mode has an associated "lispwords" variable which holds a list of the symbol names that are to be treated as operators that have a body rather than functions. But the code in the Semantic Clojure Formatting page linked to by the submission is in fact exemplifying this formatting. It shows operators that have a body being indented, and function calls exhibiting argument alignment. Can you cite an example of what you think is wrong? The only exception I see is the "narrow format" for function calls. But that's not an invention from the Clojure world. I've resorted to that narrow format myself, in code that is deeply nested and hitting the maximum column limit of the surrounding coding convention. (deeply (nested |___|___| ......................... (aargh |__|___|__ too |___|___| brick wall cramped |_|___|__ here |___|___| I don't like it very much; I prefer to refactor the code to avoid it, if possible. But if you put a line break immediately after the function name, then that is realy the only sensible indentation you can follow.