> I might take a whack at that, if I can put together a PR to mix that passes column metadata about a sigil into a custom formatter's opts (alongside file and line no) as I think this is required for them to take indentation into consideration.
At first glance, this looks like this is tantamount to tracking column metadata in all Elixir AST nodes, which is well beyond me. Unless I stumble into something clever I probably won't get too far. The default formatter has the luxury of passing the entire document to Code.format_string, which can leverage Inspect.Algebra.format to be context-aware about indentation when rendering the AST. The "sigil-specific" custom formatters only get to operate on the sigil string itself, and the options passed to them come from the entire formatter run's configuration + the sigil AST node's metadata, neither of which currently know about columns. On Thursday, December 29, 2022 at 12:54:02 AM UTC-6 Christopher Keele wrote: > > the Elixir formatter does not change the AST by default > > Ah, this makes sense. The whitespace in a sigil is part of the AST > (unlike, say, a list literal) so it must stay put. > > It feels like that this soft guarantee is *not* exactly upheld by the > formatter's treatment of heredoc strings, which it does rewrite; but on the > other hand the compiler does emit warnings about misdented heredoc lines, > and other subtleties, so that kind of makes sense. > > > Elixir could add rules to format its own sigils, but they would have to > be opt-in. > > In that case, it feels effectively equivalent to just publish some stdlib > sigil formatters outside core as a library, then "opt in" by adding to > one's deps and .formatter.exs plugins list. I might take a whack at that, > if I can put together a PR to mix that passes column metadata about a sigil > into a custom formatter's opts (alongside file and line no) as I think this > is required for them to take indentation into consideration. > > > A pipeline is always indented according to the argument it applies to. > > > But we added a rule that, if the right side of operators or the last > argument of a function call is a list (or a map, or a fn, etc), we can skip > the newline and the indentation. > > I do view the result of applying these two rules to module attributes > pipelines as unfortunate, but internally consistent... > > > but it leads to two different formats in cases you have a pipeline and > so on. > > Are there other common cases where this happens, off the top of your head? > I might investigate what it'd take to special-case them, if there is a > sensible way to do so for reasonable gain. > -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/8faa1216-7db4-4038-9e9b-89eb3d32d684n%40googlegroups.com.
