Should we introduce { and } in tags, if it's possible, technically?

It would be useful to mark environments, like {itemize}, {center}, {table}. We could distinguish {table} environment questions from such regarding tables like tabular constructs.

Would it be meaningful to see when a tag means an environment (center, quotation, quote) instead of a concept (centering, quoting)?

As some other questions show, I'm thinking about a clear understanding if a tag means a concept, class, package, environment or command - a lot of names are very similar. I made separate questions because a feature request like \ in tags is different than just to agree in tag names like [book-class] or discussing how environments should be handled.

Another drastic way would be tagging like book-cls, cite-pkg, center-env, cite-cmd, ...

Any other ideas or sugegstions?

  • 1
    Tag characters: a-z 0-9 + # - . Commented Aug 21, 2010 at 21:56
  • Developers could extend that if they were convinced or charged with.
    – Stefan Kottwitz Mod
    Commented Aug 21, 2010 at 22:17
  • Although I like the idea of \tags and kind of agree with book-class, this one I think is too much. Do we really need to distinguish all of these at the tag level? Commented Aug 25, 2010 at 15:34
  • Not necessarily. The idea came with the question how to see wether a tag name means a concept or it's a code word/ control sequence.
    – Stefan Kottwitz Mod
    Commented Aug 25, 2010 at 15:49
  • It looks like { and } in tags is now out of the question -- it would conflict badly with the way tags are displayed in the new style.
    – SamB
    Commented Nov 30, 2010 at 0:07
  • @SamB: That's right.
    – Stefan Kottwitz Mod
    Commented Nov 30, 2010 at 0:28

3 Answers 3


The {..} would be a Good Thing if it worked, although I don't particularly care about well-typed tags: do we really care about distinguishing questions that use the tag matching the package alltt from the questions that use the tag matching the environment alltt? Generally, we don't need the kind of indexing scheme that make librarians happy, but having {..} available, perhaps for both packages and environments, would be useful.

I think the question should be asked on meta.SO about possible issues with {..} tags. The dev team might be planning to use {} in search operators, for all we know.

  • I think we should discuss first whether the feature makes sense and, as a community, we like it, before even thinking about technical issues or getting the developers involved. Commented Aug 25, 2010 at 15:36
  • With the current design, { in tags would look rather strange.
    – Caramdir
    Commented Nov 30, 2010 at 16:51

An idea, which doesn't touch input, handling or links of tags would be just a visual tag shape. I introduced the idea in Backslash in tags.

That means, environment tags have { } on the tag symbol, command tags have a \ written before the command name. Does it seem too strange?

The first idea came because commands without backslash look really strange to me. Besides commands, all other code-tags concern environments I guess. So, we would get correct commands on tags and even further all code tags (\centering, center-environment, \draw etc.) are distinguished from concept-tags (centering, drawing). packages names may remain like normal tags.


Would it be meaningful to see when a tag means an environment (center, quotation, quote) instead of a concept (centering, quoting)?

Yes, absolutely – but I think the separation is already clear. Consider your example: center vs. centering, quote vs. quoting, etc.

Furthermore, there’s the convention of using plurals where it helps, e.g. “tables” vs. table etc. This should probably go in the FAQ.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .