Operate on stdin to allow integration in vim-codefmt

[TamaMcGlinn]

I would like to be able to format lua code when I save the buffer in Vim / NeoVim. This can be done with the vim-codefmt plugin, but it requires formatters to operate on stdin; this is because the file may not yet be saved, and also because you can select a range of text to format - but textrange is an optional feature we can leave disabled, as I see you have some problems with that currently.

So, can we have a flag that just takes the stdin as the entire file contents?

I've done a start on integrating to vim-codefmt here but it needs the TODO fixed. See also the issue on vim-codefmt.

[martin-eden]

Hello and thanks for interest in this project!

TL;DR: Not for streams

Background

I way playing WoW. I had like thousand Lua files with addons code. Code styles were different and hurted my feelings. In the end I reformatted them all and got readable (but still bad) code.

There was no intention to design tool for IDE.

Implementation

Code formatter is designed as file compiler. It gets chunk of text, parses to internal data structure and then compiles back. In case of formatter, it compiles back to text, not to binary code.

If you can provide data in string, you can use formatter. We don't need files, just string.

Although for in-editor formatting it's not the best tool. It expects syntactically complete chunk, not just t = {12\n which may come from clipboard.

Stream protocol

stdin is a stream. Theoretically input stream has no end and can not be moved back. It just provides next item when asked. Useful when your data is larger than your memory. And when you don't need all data to produce next result and emit it to stdout.

Example

Say we have several terabytes Lua-like file like

return{{255,0;0},{128;128,128}, ...}

We have to implement stream "formatter" for this scenario (we don't yet have terabytes of RAM).

This formatter can do neat stream printing like

return
  {
    {255, 0, 0},
    {128, 128, 128},
    ...
  }

But the point is that representation will always be the same. For

return{{255,0,0}}

it will produce

return
  {
    { 255, 0, 0 },
  }

When I want

return { { 255, 0, 0 } }

• But something like this is rugged and suitable for plugging in IDEs.

Multiple representers

That's not what I wanted my program to do. I wanted to see best representation that fits in given width.

So when representing table, several variants are tried. One tries to represent in one line, another is fallback to multi-lines. And we need that whole table before trying.

And that principle applied to other syntax elements too.

Any list is something with variable length. Like lists in declarations, in assignments, in paramenters: local a, b, c = 10, 20, 30, DoSomething(arg_1, arg_2, ...). They are represented differently according to current indentation level, maximum text width and whether we are allowed to use multi-line representation.

[TamaMcGlinn]

"completed" ? From your text it seemed like "won't fix" but maybe I've misunderstood. Did you make any change?

[martin-eden]

Formatters are compilers. Generally compilers do not operate on streams. They need all data. Imo that's wrong interface design from vim-codefmt side.

"Won't fix" assumes something may be "fixed". So something is "broken". I don't see anything broken.

It's like asking for steam locomotive to swim underwater.

[TamaMcGlinn]

Okay, so "not planned" then.