feat(engine): support shorthand notation inside ~H sigil #278

katafrakt · 2025-12-23T22:04:56Z

Closes #269

The full-module notation (<MyMod.button>) was already supported in "go to definition", because when passed to ElixirSense, it correctly recognized the form and found the appropriate module and the function. However, with a shorthand notation it was not so simple, because .button is not valid Elixir and ElixirSense was not able to make anything of it.

This implements the support for shorthand notation by doing a preliminary step before sending the code to ElixirSense. It modifies the AST and the Document of ForgeAnalysis and replaces all the calls to <.button> with < button(assigns) so that ElixirSense can correctly interpret it as a local function call with arity 1. This only happens when phoenix_live_view is added as a dependency¹.

This works for functions defined in the same module, but also for imported functions. Support for ending tag is also included.

While this might seem as a hacky solution, it makes handling shorthand notation as close as possible to handling the full-module notation, making sure these two stay conceptually close.

I looked into making a more detailed check here, basically checking if Phoenix.Component is imported into current module, but there's just too many ways to do so. I don't think the code analysis can do that, we would need to actually compile the code (using ElixirSense?). But I settled for a much simpler condition in this case. ↩

doorgan

Thank you!

This is working, I only have some minor comments so far. One thing I could not get to work was Hover, I get logs saying the entity was resolved to the right thing, but no hover docs show.

Another note but I think this is more of an ElixirSense issue, I get the logs spammed with this sometimes when I trigger go to definition:

18:44:25.258 [warning] ** (RuntimeError) ~H requires a variable named "assigns" to exist and be set to a map
    (phoenix_live_view 0.20.7) lib/phoenix_component.ex:791: Phoenix.Component."MACRO-sigil_H"/3
    (xp_elixir_sense 2.0.0) lib/elixir_sense/core/normalized/macro/env.ex:54: anonymous fn/5 in XPElixirSense.Core.Normalized.Macro.Env.wrap_expansion/7
    (xp_elixir_sense 2.0.0) lib/elixir_sense/core/compiler.ex:2144: XPElixirSense.Core.Compiler.expand_macro_callback/7
    (xp_elixir_sense 2.0.0) lib/elixir_sense/core/compiler.ex:117: XPElixirSense.Core.Compiler.expand/3
    (xp_elixir_sense 2.0.0) lib/elixir_sense/core/compiler.ex:2055: XPElixirSense.Core.Compiler.expand_macro/7
    (xp_elixir_sense 2.0.0) lib/elixir_sense/core/compiler.ex:117: XPElixirSense.Core.Compiler.expand/3
    (xp_elixir_sense 2.0.0) lib/elixir_sense/core/compiler.ex:2165: XPElixirSense.Core.Compiler.expand_macro_callback/7
    (xp_elixir_sense 2.0.0) lib/elixir_sense/core/compiler.ex:117: XPElixirSense.Core.Compiler.expand/3

doorgan · 2025-12-23T22:47:37Z

apps/engine/lib/engine/code_intelligence/heex_normalizer.ex

+  end
+
+  defp phoenix_component_available? do
+    Code.ensure_loaded?(Phoenix.Component)


We probably want Engine.Module.Loader.ensure_loaded? here. Code.ensure_loaded?/1 can be quite slow, so we have a cache for it

Suggested change

Code.ensure_loaded?(Phoenix.Component)

Engine.Module.Loader.ensure_loaded?(Phoenix.Component)

done, thanks

doorgan · 2025-12-23T23:44:07Z

apps/engine/lib/engine/code_intelligence/heex_normalizer.ex

+  # (i.e., phoenix_live_view is in the dependencies).
+  @spec maybe_normalize(Analysis.t(), Position.t()) :: Analysis.t()
+  def maybe_normalize(analysis, position) do
+    if phoenix_component_available?() do


If possible, I think we also need to check in the analysis scopes if sigil_H from Phoenix.Component is imported

I tried to do that, but I'm not sure if this can be done reliably. For example, I find it hard to detect things like use MyAppWeb, :live_component, which imports sigil_H, not to mention some potential more elaborate metaprogramming resulting in an import.

doorgan · 2025-12-23T23:45:21Z

apps/engine/lib/engine/code_intelligence/heex_normalizer.ex

+      |> Zipper.zip()
+      |> Zipper.find(&(&1 == sigil))
+      |> case do
+        nil -> analysis.ast
+        zipper -> zipper |> Zipper.replace(new_sigil) |> Zipper.root()


In case we need to speed this up for large files, there's also Sourceror.FastZipper

changed to FastZipper

The full-module notation (`<MyMod.button>`) was already supported in "go to definition", because when passed to ElixirSense, it correctly recognized the form and found the appropriate module and the function. However, with a shorthand notation it was not so simple, because `.button` is not valid Elixir and ElixirSense was not able to make anything of it. This implements the support for shorthand notation by doing a preliminary step before sending the code to ElixirSense. It modifies the AST and the Document of ForgeAnalysis and replaces all the calls to `<.button>` with `< button(assigns)` so that ElixirSense can correctly interpret it as a local function call with arity 1. This works for functions defined in the same module, but also for imported functions. Support for ending tag is also included. While this might seem as a hacky solution, it makes handling shorthand notation as close as possible to handling the full-module notation, making sure these two stay conceptually close.

…deps

The testing happens in Engine and there the presence of LiveView is mocked.

katafrakt · 2026-01-05T11:40:23Z

@doorgan thank you for the review!

Admittedly, I didn't really focus on Hover while working on this. I can have a look, if you think this is in the scope here.

As for error logs, I haven't really seen these errors yet, but I would like to look into this. Where do they appear for you? In the project.log?

doorgan · 2026-01-05T11:47:50Z

@katafrakt

Admittedly, I didn't really focus on Hover while working on this. I can have a look, if you think this is in the scope here.

I think it's in scope for this feature, but also feel free to do it in a follow up. If this gets merged and you decide to tackle that in another PR, let's open an issue to track it.

As for error logs, I haven't really seen these errors yet, but I would like to look into this. Where do they appear for you? In the project.log?

They appear in expert.log
But again this may be an ElixirSense quirk, like it happens sometimes for module attributes

I think this is good to go, but I'll defer to @mhanberg on merging. I want to make sure we're good with this approach in the short term vs revamping the plugin system first.

katafrakt · 2026-01-05T15:47:33Z

I'm trying to understand if there's something special about this OTP 27.3.4.1 / Elixir 1.18.4 version combination, where tests for this fail on a seemingly unrelated test case, given that is passes with this elixir version and higher/lower OTP. I'm able to reproduce this locally, so it's not a CI issue.

UPDATE: I traced it to the ElixirSense.definition call in Engine.CodeIntelligence.Definition, so I think it's a problem there.

katafrakt changed the title ~~Support jump to definition in HEEx templates~~ feat(engine): support shorthand notation inside ~H sigil Dec 23, 2025

doorgan reviewed Jan 2, 2026

View reviewed changes

katafrakt added 7 commits January 5, 2026 11:49

Fix regex for opening and closing tags

8b8f0e0

Only trigger HEEx normalization when phoenix_live_view is present in …

beb5615

…deps

Rename call as maybe_normalize

fe22b39

Delete fixture app (not used in tests)

c599772

The testing happens in Engine and there the presence of LiveView is mocked.

Revert unnecessary test change

e166a3f

More test cases

2eea4c5

katafrakt force-pushed the support-h-sigil-shorthand branch from 36d2efd to 2eea4c5 Compare January 5, 2026 10:50

Use Engine.Module.Loader for faster lookups

d89b1d8

Use Sourceror.FastZipper

5158ee6

katafrakt force-pushed the support-h-sigil-shorthand branch from be21465 to 5158ee6 Compare January 5, 2026 11:51

Simplify tests

072753e

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

feat(engine): support shorthand notation inside ~H sigil #278

feat(engine): support shorthand notation inside ~H sigil #278

katafrakt commented Dec 23, 2025

Uh oh!

doorgan left a comment

Uh oh!

doorgan Dec 23, 2025

Uh oh!

katafrakt Jan 5, 2026

Uh oh!

doorgan Dec 23, 2025

Uh oh!

katafrakt Jan 5, 2026

Uh oh!

doorgan Dec 23, 2025

Uh oh!

katafrakt Jan 5, 2026

Uh oh!

katafrakt commented Jan 5, 2026

Uh oh!

doorgan commented Jan 5, 2026

Uh oh!

katafrakt commented Jan 5, 2026 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

2 participants

	Code.ensure_loaded?(Phoenix.Component)
	Engine.Module.Loader.ensure_loaded?(Phoenix.Component)

Uh oh!

feat(engine): support shorthand notation inside ~H sigil #278

Are you sure you want to change the base?

feat(engine): support shorthand notation inside ~H sigil #278

Conversation

katafrakt commented Dec 23, 2025

Footnotes

Uh oh!

doorgan left a comment

Choose a reason for hiding this comment

Uh oh!

doorgan Dec 23, 2025

Choose a reason for hiding this comment

Uh oh!

katafrakt Jan 5, 2026

Choose a reason for hiding this comment

Uh oh!

doorgan Dec 23, 2025

Choose a reason for hiding this comment

Uh oh!

katafrakt Jan 5, 2026

Choose a reason for hiding this comment

Uh oh!

doorgan Dec 23, 2025

Choose a reason for hiding this comment

Uh oh!

katafrakt Jan 5, 2026

Choose a reason for hiding this comment

Uh oh!

katafrakt commented Jan 5, 2026

Uh oh!

doorgan commented Jan 5, 2026

Uh oh!

katafrakt commented Jan 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

2 participants

katafrakt commented Jan 5, 2026 •

edited

Loading