feature request : format block of text

[rundis]

I'm excited about this project ! I was wondering if it would be possible to also support formatting of a block of text. Why would you need that you might ask ? Well I've created a editor plugin for elm and one of the features is a repl integration. When working in a repl context in the editor, there is no file backing the editor however it would be really nice to be able to format expressions when you are repl'ing away so to speak.

Let me illustrate:

[avh4]

I think there are two parts to this: one is being able to send elm-format input on stdin instead of in a file, and the other is to be able to parse and format inputs that are not complete files. (In your example, you have a definition selected.)

What editor is your plugin for?

[rundis]

True !

Light Table: https://github.com/rundis/elm-light
There is already some very (very) lightweight support for auto formatting since Light Table is based on http://codemirror.net/ . However writing an elm language mode for CodeMirror that supports proper formatting (indentation and such) would be a pretty substantial effort, that's why I'm hoping for some sort of support from elm-format beyond a whole file format based on saved files. I can imagine that would be interesting to other editors too :)

cheers
Magnus

[avh4]

How can we break this down to implement incrementally? Would being able to format declarations be enough to start with? What other smaller pieces would you expect to want to format? (expressions, types, patterns, ...?)

[rundis]

• Starting with top-level function declarations would be a big win.
• Then any other top-level declaration

Anything beyond that goes into the nice-to-have category

[avh4]

We've added the --stdin command line option. (#82)

@rundis can you give more details about how your plugin would use this? Is it that in your repl buffer you are going to format the statement at the same time that you execute it in the repl?

[rundis]

Great news !

I should build from source to test this or have the distributions been updated ?

@avh4 Nah formatting and executing doesn't/shouldn't depend on each other. I wasn't planning on limiting this to just the repl btw.. But to any elm buffer/file in Light Table.

Let me outline a few scenarios:

• I set of experimenting with a repl (buffer), after trying some things out I start making some functions. Hey it would be nice to read them if they were properly formatted.. elm-format to the rescue just select the top-level expression and invoke some keyboard incantation and voila nice and proper. Move on to more repl'ing add another top level expression... and so on. Eventually I might have a module in my hands, save it (and as part of save, automatically do elm-format on the whole thing)
• At some point I might add simple refactoring features to elm-light (introduce let-in or move to let etc). With the cursor somewhere in a top level expression I invoke a refactoring command, somehow(lightweight parsing perhaps) I've managed to gain enough context to do a refactor), when completed I wish to format the expression and hopefully position the cursor somewhere reasonable so that I can carry on if I'm content with the refactoring. Unless I'm happy, I don't really want to save. That's why stdin sounds like a great option !
• Light Table already has a snippet plugin, when I insert some snippet you'd obviously want it to be nicely formatted (say I have a let - in snippet I want to use inside a top level function). Again I don't really want to save unless I'm happy with the results. Elm format stdin to the rescue ? :-)

[avh4]

Thanks for the extra comments @rundis .

For the latter two cases, the hope is that elm-format --stdin will be fast enough to format the entire file after inserting a snippet or performing a refactoring. The goal is also that people will want to use elm-format for their entire files, and not selectively use it for only parts of their code (at this stage, I want people to be giving feedback if that's not the case).

For the repl case, do we know exactly what types of things the repl accepts? It must accept both top-level definitions, and expressions. Would you know in advance which it is? I'm guessing you'd probably want elm-format to figure it out.

[rundis]

My biggest fear is that there will be too strict requirements on always having your entire working file in a completely valid state for partial changes to be workable/usable. I might be uncessarily worried but I remember that was one of the reasons I switched from Eclipse to Intellij back in the day. Eclipse depended on everything compiling nicely for things too work, a few errors and it was totally thrown off.
I guess I'll have to try it out before making any judgements though.

With regards to the repl, it accepts a lot of things I'm afraid. I mean you can write 1 and get 1 back. Or just enter a function name and it will return the function signature, but formatting for that isn't very interesting, it's when you enter top level declarations that makes most sense to support imho. But then again .... :)

[ilkka]

Chiming in as a Vim user — elm-format is quite fast enough to format the entire file, but sometimes I feel like "attaching" comments to blocks of code by having a comment on e.g. an immediately preceding line. Formatting the entire file breaks this, of course, but Vim has formatprg which essentially means that I can set that to elm-format --stdin and pass any bit of code I care through that program, then back into my editor.

However, since elm-format inserts a module definition if it finds none, this causes spurious module Main (..) where lines in my code. So @avh4, how would you feel about having a flag to suppress inserting a module definition?

[avh4]

@ilkka I'd like to first focus on making the full-file formatting work properly so that people don't have a need to format small pieces of their code. I think this is the relevant issue to the behavior you described about comments: #137

[ilkka]

Fair enough :) I didn't know about {-| either, that makes things easier. Allowing line end comments would probably then solve all my problems.

–Ilkka

On 14 Mar 2016, at 03:30, Ɛərɪn VonderHaar notifications@github.com wrote:

@ilkka I'd like to first focus on making the full-file formatting work properly so that people don't have a need to format small pieces of their code. I think this is the relevant issue to the behavior you described about comments: #137

—
Reply to this email directly or view it on GitHub.

[kachkaev]

Glad to find this discussion! I began to work on a new feature in atom-beautify, the idea of which is to format fenced code blocks inside markdown files.

Because elm-format assumes that any block of text it formats is a proper module, it fails at least in two ways:

• module Main exposing (..) is prepended to any code block that has no syntax issues
• empty code blocks or those that only contain import XYZ exposing (..) fail because they contain no statements.

What would be ideal in my scenario is if elm-format had a flag e.g. --fragment (or --stdin as mentioned above). How difficult does this sound in the current elm-format architecture?

[kachkaev]

Seems like Atom's beautify package also has an option to format the selected code:

Doing so adds module Main exposing (..) to the beginning of the selection if formatting succeeds.

[kachkaev]

I started a PR in atom-beautify, which should make it possible to format elm fragments correctly if elm-format supports something like --fragment or --stdin. Would love to see this! Unfortunately, I'm too new to elm to be able to implement this flag for elm-format myself, but I'm happy to help with something else if I can.

Who could have a look at solving this issue please?

[avh4]

#369 is a feature on the 0.7.1 backlog that will pave the way for this to happen. We also need to finalize a design on how this should work: what should the command line argument(s) be, and can it be possible to detect this mode automatically based on the input?

[kachkaev]

Meanwhile, I managed to solve an issue with formatting code fragments in markdown by implementing Elm plugin for Prettier. It calls elm-format, but then trims module Main exosing (..) if that's needed (see comments in src/parser.js). Hope that fragments are support natively by elm-format one day!

[avh4]

This is sort of implemented internally now for when elm-format formats pieces of code in doc comments. The logic is here:

elm-format/src/ElmFormat/Render/Box.hs

Lines 671 to 678 in 0fae81f

	parse :: String -> Maybe ElmCodeBlock
	parse source =
	source
	|> firstOf
	[ fmap DeclarationsCode . Result.toMaybe . Parse.parseDeclarations
	, fmap ExpressionsCode . Result.toMaybe . Parse.parseExpressions
	, fmap ModuleCode . Result.toMaybe . Parse.parseModule
	]

I guess the question now is how should this be exposed to external tools?

[kachkaev]

@avh4 something like --input-type=fragment? This option may be useful for both stdin and files, (the latter when fragments are stored in cache for example).

[rlefevre]

One way could be to add a flag, but another one with a simpler design would be to stop adding the module Main ... line when it was not present at first.

Is this feature useful to some? I fail to see much use cases for it but it may be only because I'm not used to it. Maybe uses cases have been listed somewhere or a poll could be done on slack or something to evaluate the usefulness of this feature?