Consider getting rid of the @ sign in templatetag

[nerdoc]

I think that the {% @ snake_case / %} notation is a bit cumbersome.

• At least Pycharm does not recognize the "@" as valid identifier, and underlines it.
  
• Too many of the special characters lowers readability: {% @ foo / %} is a bit much of those special chars.
• libraries like django-component-tags do that much easier. A component named ChangePassword does look like {% ChangePassword user=request.user %} - FQN {% common.default.ChangePassword user=request.user %}

So I'd like you maybe to consider moving away from the @ to "normal" names - even the CamelCase2snake_case conversion is not necessary IMHO.

Maybe you have had a good plan when designing it, and I don't know about that. And yes, the end tag must be done somehow. ATM this is done with /@ - which is another special sign....
I know that e.g. {% endcomponent %} is blunt. Even if Django does something with {% endblocktranslate %}.
{% /Changepassword %} Could be another option.

The ratio for that is: If you use Tetra for more than interactive components, but for building a bigger website out of it, especially BasicComponents, you soon find all the special chars unreadable.

@samwillis but I can understand if you tell me that this is too much work... 😄

[nerdoc]

It is even impossible to use syntax highlighting with e.g. highlightjs or pygments for the documentation. E.g. in component-tag docs there is the @ sign not identified as name, but the following name is taken as templatetag.

So while @ is a short way to initiate component block names, and it is not forbidden in the docs that names of template tags are not valid python identifiers, it is not used anywhere else and leads more to problems than it helps. Even if it's short, you can't use your IDE to navigate via click to the component (an IDE feature which I rely much during development).

• There is a long discussion on a django-components templatetag naming issue which is quite interesting to read.
• I am not quite sure, and I definitely like the way an "inline" component can be declared with the /at the end, but it lacks IDE support.
• But besides the verbosity, a "component" templatetag could make sense, as it's commonly used, comprehensive, but it's long to write.

There are a few options available, how other frameworks like django-components, django-web-components, django-unicorn do it.

The last one would be short too

what	simple	short	djangoish	comprehensive	IDE support
current approach {% @ my_component foo bar %}...{% /@ endmy_component %}	X	X			bad.
{% component "my_component" foo bar %}...{% endmy_component %}			X	X	X
{% component my_component foo bar %}...{% endmy_component %}	X		X	X	X
{% my_component foo bar %}...{% endmy_component %}	X	X	X	X	X (not navigateable*)
{% MyComponent foo bar %}...{% endMyComponent %}	X	X		X	X (not navigateable*)
{% MyComponent foo bar %}...{% /MyComponent %}	X	X		X	bad.
{% x my_component foo bar %}...{% endx %}	X	X	X		X
{% c my_component foo bar %}...{% endc %}	X	X	X		X

*not navigateable means, the IDE doesn't find the templatetag source, as it is dynamic.

Especially @samwillis, @ksdme, @almahdi404 Please write your opinions & feedback here, if you find time.