Closed ldez closed 8 years ago
See sub
and sup
with Atom Dark, Atom Light, Solarized Dark and Solarized Light to see why custom CSS style not a good idea.
I think the attribute list for sup and sub should shift to match the formatted text. In other words, the attribute list should also be super and subscript, respectively.
it's better ?
name: 'markup.subscript.asciidoc'
match: '(?<!\\\\)(\\[.+?\\])?((~)(\\S+?)(~))'
captures:
1: name: 'markup.meta.sub.attribute-list.asciidoc'
2: name: 'markup.sub.subscript.asciidoc'
3: name: 'punctuation.definition.sub.asciidoc'
5: name: 'punctuation.definition.sub.asciidoc'
Borat says, "Is nice !"
(I'm assuming making the asterisks around bold text the same color is a separate change not reflect here, right?).
I'm assuming making the asterisks around bold text the same color is a separate change not reflect here, right?
If I do that:
name: 'markup.strong.unconstrained.asciidoc'
match: '(?<!\\\\\\\\)(\\[.+?\\])?((\\*\\*).+?(\\*\\*))'
captures:
1: name: 'markup.meta.attribute-list.asciidoc'
2: name: 'markup.bold.asciidoc'
3: name: 'punctuation.definition.asciidoc'
4: name: 'punctuation.definition.asciidoc'
I have:
It's better ?
Yes, the unconstrained strong is now as expected. Can you apply the same to contained strong?
I'd just like to pause and say how amazing that looks. It totally crushes the syntax highlighting in VIM now.
Can you apply the same to contained strong?
Yes and clean all others redundancy.
We kill VIM :smiley_cat:
Any particular reason for choosing font-size 0.7 over the 0.8 as previously set for subscript and superscript?
yes because sub is placing less on the bottom.
@nicorikken @mojavelinux give me a LGTM ? :wink:
Don't let me in trouble :cold_sweat:
LGTM
@nicorikken what are your thoughts about the markup. prefix on the attribute-list?
Btw, I think we should add "inline" to "attribute-list" so that we can distinguish this attribute list from the block attribute list. Or do you think that "markup" provides that qualifier already?
@ldez I didn't get to it up until. The rendering is as intended, and the code has been cleaned up drastically, so merging this looks good to me. Maybe some naming would shift, as that seems to be an ongoing learning effort, but I don't think that should hold off on a merge (and release 😉 )
@nicorikken what are your thoughts about the markup. prefix on the attribute-list?
At this very moment I couldn't care less, the structure has been improved, it looks good based on our current understanding of style, and we can ship with this version. I do recognize it is a worthwhile discussion to have, and improvements can be made. I'll have to find me some quiet time the coming days to analyze this issue and come up with better solutions.
:+1:
It's important to give ourselves credit that we're solving a very difficult "information architecture" task. There are people that have spent decades trying to master this skill. What's important is that we agree on a naming system that allows us to apply the patterns over and over. In my mind, the biggest value of information architecture is consistency. It's tedious, for sure, but also very important.
New pattern:
I change
sub
andsuper
because I have found a bug.Syntax:
Overview with different themes:
atom-dark
atom-light
base16-dark
base16-light
one-dark
one-light
solarized-dark
solarized-light
![solarized-light](https://cloud.githubusercontent.com/assets/5674651/15192461/8cb37ac8-17b9-11e6-9209-85f851d50927.png)