Skip to content

Always evaluate active templates at the insertion point#200

Closed
martenlienen wants to merge 1 commit intominad:mainfrom
martenlienen:evaluation-point
Closed

Always evaluate active templates at the insertion point#200
martenlienen wants to merge 1 commit intominad:mainfrom
martenlienen:evaluation-point

Conversation

@martenlienen
Copy link
Copy Markdown

At the moment, tempel--templates is evaluated without fixing point to a consistent location. This means that tempel-expand and tempel-insert have different expansions available at the same "mental" location if their :when relies on point. This PR evaluates available templates (and thus :when conditions) at the potential insertion points for the template. I chose this as the canonical evaluation point because it does not depend on the template prefix and it ensures that the following template is available at the beginning of line as I would intuitively expect:

org-mode :when (bolp)
(caption "#+caption: ")

The one limitation of this change is that it required me to revert 46d4f54. Evaluating available templates at the insertion point requires us to move point there, which means that we have to know the potential prefix that we are expanding. This precludes the prefix from depending on the templates. However, I looked through issues and pull requests and did not find any explanation for this change in the first place. In my opinion, making prefix checking configurable in other ways would be more robust and evaluating conditions with a consistent point seems more important (see intuitive example above) than expansion prefixes depending on templates.

I have an FSF copyright assignment for Emacs and ELPA packages.

This ensures that :when conditions are evaluated at consistent positions between prefix
expansion and template insertion with ~tempel-insert~.
@minad
Copy link
Copy Markdown
Owner

minad commented Feb 28, 2026

This makes sense, however I don't want to revert 46d4f54. It originates from #192. In case a template name with spaces or special characters is used, the point might not be correct. But we can still jump to the beginning of the prefix around the :when evaluation.

@martenlienen
Copy link
Copy Markdown
Author

With the current architecture, this is a circular requirement, I believe. :when is evaluated inside tempel--templates, which would require knowledge of the prefix to expand to put point at the correct place (and in the case of tempel-insert, there is no prefix). However, determining the prefix requires us to already know the possible templates.

One solution that I see would be to change tempel--templates to return all possible templates including their :when and mode conditions and then to separate template collection via sources from template filtering according to conditions. Then the flow would be collect-templates -> match possible prefixes -> filter templates.

@minad
Copy link
Copy Markdown
Owner

minad commented Feb 28, 2026

What I mean is that we could call (tempel--templates) where it makes sense, with point at the beginning of (bounds-of-thing-at-point 'symbol), to handle the common case. The point location would not be correct for non-symbol prefixes. This just means that :when and non-symbol prefixes are mutually exclusive, and we cannot rely on the exact point for non-symbol prefixes.

Another better solution might be to call tempel--prefix-bounds for every template and move point accordingly. But this is a little less efficient. (EDIT: Also it doesn't work well with the current data structure used for the templates, where :when is shared by multiple templates.)

@martenlienen
Copy link
Copy Markdown
Author

I can implement the first solution. That would be quite easy, though I don't like so much that it would introduce two different notions of prefix ((bounds-of-thing-at-point 'symbol) and tempel--prefix-bounds). I could also implement something along the lines of the better solution. I think here I would pull condition evaluation out of template collection though, so the final flow would be tempel--templates -> tempel--prefix-bounds -> tempel--filter-templates, where the last one does not exist yet. What do you think?

@martenlienen
Copy link
Copy Markdown
Author

Closing this in favor of #201, which keeps the tempo compatibility introduced in 46d4f54 and makes it more robust by always considering all possible prefixes. So if one has templates for <s and s and point is locking back at <s and both templates' conditions are fulfilled, both will be shown to the user (assuming that s is considered a symbol in the current mode) instead of "arbitrarily" preferring <s.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants