To make sure we are all on the same page, supporting EEx in mix format has two parts:
1. Having a formatter that works on EEx files 2. Adding hooks to "mix format" that allows custom formatting. In particular, we need to hook into certain extensions and into sigils Step 1 is a huge amount of work per previous conversation. Step 2 is definitely doable and pull requests to add said hooks are welcome. On Tue, Jul 27, 2021 at 12:33 AM Max Veytsman <ma...@ontoillogical.com> wrote: > Reviving this as there has been a new development - HEEx ( > https://github.com/phoenixframework/phoenix_live_view/pull/1440) > > Phoenix LiveView is moving to HEEx templates which unlike EEx are HTML > only, and includes an HTML tokenizer & parser. > > Allen had the following concern: > > The problem is .eex can be embedded into anything: YAML, HTML, JSON, etc. > > Adding support for HEEx templates makes the problem tractable - we only > need to be formatting HTML, which is already parsed for us by the > HTMLEngine that powers HEEx. > > It would also have the added benefit of formatting code in sigils, e.g, > > def render(assigns) do > ~H""" > <div> > Format this HTML plz > </div> > """ > end > On Saturday, May 30, 2020 at 11:38:16 AM UTC-4 ad...@a-corp.co.uk wrote: > >> Yea that makes way more sense. If the formatter can ignore the stuff it’s >> being injected in that would for sure be cool. Then the usual formatters >> for html etc can probably be used anyway. >> >> >> On 30 May 2020, at 16:30, Wojtek Mach <woj...@wojtekmach.pl> wrote: >> >> In my opinion formatting non-Elixir code is definitely out of the scope >> of project. Instead of adding different backends to `mix format`, I’d do >> the opposite: find a formatter that supports multiple backends and add `mix >> format` as one of them. >> >> I thought the feature request was about formatting Elixir code _inside_ >> EEx templates and just, i.e. we leave the surrounding code as is, but >> format the inner Elixir code. That to me seems far more reasonable. >> >> Here’s a proof-of-concept for that idea: >> https://gist.github.com/wojtekmach/a1c1648b8015dbb67d35b89f2e743266 >> >> before: >> <p><%= bar( 1, 2 ) %></p> >> >> after: >> <p><%= bar(1, 2) %></p> >> >> If this looks like something worth pursuing, let me know! >> >> On 30 May 2020, at 16:26, Adam Lancaster <ad...@a-corp.co.uk> wrote: >> >> Thanks that’s interesting context. >> >> I agree supporting every format would be a lot of work. I would also have >> mixed feelings about making the formatter extensible if it would mean a >> wealth of community owned formatters, as that would defeat some of the >> purpose of having an opinionated formatter. >> >> However I think you could make the formatter extensible in architecture, >> and allow official extensions to be built one at a time. Like a html >> formatter that works only on .html.eex files and .html.leex files would add >> a lot of value on its own, even if YAML and JSON are never supported. >> >> Best >> >> Adam >> >> >> >> >> On 30 May 2020, at 14:48, Allen Madsen <allen.c...@gmail.com> wrote: >> >> Yea, I believe this has come up before. The problem is .eex can be >> embedded into anything: YAML, HTML, JSON, etc. So, in order for the >> formatter to be able to format .eex files, it would 1) have to know what >> the surrounding data is and 2) have a formatter for that specific tool in >> the language. >> >> The first problem could be solvable by some heuristic, but could only >> solve the problem for the types of files known. It's basically a problem >> with infinite surface area. The second problem would mean the code base of >> core would need to include some understanding of every surrounding format. >> So, because of those reasons, I'd expect something like this to be rejected. >> >> However, if the goal were to make the formatter extensible so that >> formatting of files other than .ex and .exs can be handled by a third party >> plugin, that might be more applicable for inclusion into core. That would >> require some proposed design for how such a thing might work though. >> >> Allen Madsen >> http://www.allenmadsen.com >> >> >> On Sat, May 30, 2020 at 8:39 AM Adam Lancaster < >> ad...@channelviewestates.co.uk> wrote: >> >>> Hello >>> >>> It would be really great if the mix formatter could be configured to >>> work with .eex templates. Would that be a bananas amount of work? >>> >>> Best >>> >>> Adam >>> >>> -- >>> 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-co...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/elixir-lang-core/3c85260b-9435-42fb-9298-c7f79b3b5f7f%40googlegroups.com >>> <https://groups.google.com/d/msgid/elixir-lang-core/3c85260b-9435-42fb-9298-c7f79b3b5f7f%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> >> -- >> 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-co...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/elixir-lang-core/CAK-y3CvELAj82crcY-6m6jdNJrXZNVQH1FgRsNQFtGV-vRZGEg%40mail.gmail.com >> <https://groups.google.com/d/msgid/elixir-lang-core/CAK-y3CvELAj82crcY-6m6jdNJrXZNVQH1FgRsNQFtGV-vRZGEg%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> >> >> -- >> 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-co...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/elixir-lang-core/D76F1C37-1593-4FD6-B63A-982CD1B155F8%40a-corp.co.uk >> <https://groups.google.com/d/msgid/elixir-lang-core/D76F1C37-1593-4FD6-B63A-982CD1B155F8%40a-corp.co.uk?utm_medium=email&utm_source=footer> >> . >> >> >> >> -- >> 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-co...@googlegroups.com. >> >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/elixir-lang-core/2EF38BB8-B6A9-47CB-943D-D4EC0C03E350%40wojtekmach.pl >> <https://groups.google.com/d/msgid/elixir-lang-core/2EF38BB8-B6A9-47CB-943D-D4EC0C03E350%40wojtekmach.pl?utm_medium=email&utm_source=footer> >> . >> >> >> -- > 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/9769e334-f3b6-4559-ab5d-f0f7458fcccan%40googlegroups.com > <https://groups.google.com/d/msgid/elixir-lang-core/9769e334-f3b6-4559-ab5d-f0f7458fcccan%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAGnRm4Lkmi-y%3DJTUS82v%2BnpEuXHJCTckV6SB2FDk9R%3DDU-4GMg%40mail.gmail.com.
