New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add flag attribute to control case sensitivity of attribute resolution #509

Open
mojavelinux opened this Issue Jul 17, 2013 · 6 comments

Comments

Projects
None yet
5 participants
@mojavelinux
Member

mojavelinux commented Jul 17, 2013

By design, AsciiDoc treats all attribute names as lowercase, both when storing them and when resolving them. This is not always desirable. Introduce a document attribute flag that controls whether case sensitivity is honored in attribute names. The default should be compliant with AsciiDoc, which is to treat all attribute names as lowercase.

Example:

:name: 1
:NAME: 2
:case-sensitive-attrs:

{name} != {NAME}

Normally, the two attributes would resolve to the same value of 2.

@ghost ghost assigned mojavelinux Jul 17, 2013

@shahryareiv

This comment has been minimized.

Show comment
Hide comment
@shahryareiv

shahryareiv Jun 22, 2015

Contributor

This should probably cover first-letter or full-word capitalization options also. I use attributes for highly used phrases (e.x. {hit} for health information technology), and acronyms.
In latex (through glossaries package), we can use \gls{hit}, \Gls{hit}, \GLS{hit} for different capitalization needs. In asciidoc I use {hit}, {hit-cap}, {hit-allcap} but probably {hit}, {Hit}, {HIT} should be a better solution (?)
Maybe related: the automatic expansion of an acronym in the first encounter is another issue. We do can it manually but it is error prone and also problematic for file inclusions. This is done in Latex through the same macro, ie \gls.

Contributor

shahryareiv commented Jun 22, 2015

This should probably cover first-letter or full-word capitalization options also. I use attributes for highly used phrases (e.x. {hit} for health information technology), and acronyms.
In latex (through glossaries package), we can use \gls{hit}, \Gls{hit}, \GLS{hit} for different capitalization needs. In asciidoc I use {hit}, {hit-cap}, {hit-allcap} but probably {hit}, {Hit}, {HIT} should be a better solution (?)
Maybe related: the automatic expansion of an acronym in the first encounter is another issue. We do can it manually but it is error prone and also problematic for file inclusions. This is done in Latex through the same macro, ie \gls.

@mojavelinux

This comment has been minimized.

Show comment
Hide comment
@mojavelinux

mojavelinux Jul 4, 2015

Member

Being able to turn off case insensitivity will allow you to define multiple variants like hit, Hit and HIT. This is another great justification for why we should have this control.

I think the expansion use case is best handled through a custom inline macro (e.g., abbr:HIT[]) instead of an attribute (or, in the future, a custom namespace for attributes like {abbr:HIT}). It could also be done with a Preprocessor. Extensions FTW!

Member

mojavelinux commented Jul 4, 2015

Being able to turn off case insensitivity will allow you to define multiple variants like hit, Hit and HIT. This is another great justification for why we should have this control.

I think the expansion use case is best handled through a custom inline macro (e.g., abbr:HIT[]) instead of an attribute (or, in the future, a custom namespace for attributes like {abbr:HIT}). It could also be done with a Preprocessor. Extensions FTW!

@mojavelinux mojavelinux modified the milestones: v1.6.0, v1.7.0 Dec 21, 2015

@GeraldLoeffler

This comment has been minimized.

Show comment
Hide comment
@GeraldLoeffler

GeraldLoeffler Aug 12, 2017

Has an expansion macro similar to the mentioned abbr been written?

GeraldLoeffler commented Aug 12, 2017

Has an expansion macro similar to the mentioned abbr been written?

@oddhack

This comment has been minimized.

Show comment
Hide comment
@oddhack

oddhack Sep 9, 2017

I'd also find this useful - just got bitten by accidentally having two attributes in different case which I expected to be different.

oddhack commented Sep 9, 2017

I'd also find this useful - just got bitten by accidentally having two attributes in different case which I expected to be different.

@rockyallen

This comment has been minimized.

Show comment
Hide comment
@rockyallen

rockyallen Oct 13, 2017

If this is to be the new preferred behaviour, the flag will have to be in every document forever. Would it be better to make it a breaking change, and only do the old (iilogical) behaviour in compatibility mode? I doubt that many people deliberately "used" the old style.

rockyallen commented Oct 13, 2017

If this is to be the new preferred behaviour, the flag will have to be in every document forever. Would it be better to make it a breaking change, and only do the old (iilogical) behaviour in compatibility mode? I doubt that many people deliberately "used" the old style.

@rockyallen

This comment has been minimized.

Show comment
Hide comment
@rockyallen

rockyallen Oct 13, 2017

Whatever the resolution, can you make it the same for counters?

rockyallen commented Oct 13, 2017

Whatever the resolution, can you make it the same for counters?

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