asciidoctor / atom-language-asciidoc

⚛ AsciiDoc language package for the Atom editor.
https://atom.io/packages/language-asciidoc
MIT License
42 stars 20 forks source link

refactor: styling #111

Closed ldez closed 8 years ago

ldez commented 8 years ago

New pattern:

  # Matches strong unconstrained phrases
  #
  # Examples
  #
  #   s**trong** phrase
  #
  name: 'markup.strong.unconstrained.asciidoc'
  match: '(?<!\\\\\\\\)(\\[.+?\\])?((\\*\\*)(.+?)(\\*\\*))'
  captures:
    1: name: 'markup.meta.attribute-list.asciidoc'
    2: name: 'markup.bold.strong.asciidoc'
    3: name: 'punctuation.definition.bold.asciidoc'
    5: name: 'punctuation.definition.bold.asciidoc'

I change sub and super because I have found a bug.

bug

Syntax:

.foobar
[role]**foo** bar
[role]*foo* bar
[role]__foo__ bar
[role]_foo_ bar
[role]``foo`` bar
[role]`foo` bar
[role]^foo^bar^foo^bar
[role]~foo~bar~foo~bar

Overview with different themes:

atom-dark atom-dark atom-light atom-light base16-dark base16-dark base16-light base16-light one-dark one-dark one-light one-light solarized-dark solarized-dark solarized-light solarized-light

ldez commented 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.

mojavelinux commented 8 years ago

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.

ldez commented 8 years ago

it's better ?

capture du 2016-05-11 23-04-08

  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'
mojavelinux commented 8 years ago

Borat says, "Is nice !"

(I'm assuming making the asterisks around bold text the same color is a separate change not reflect here, right?).

ldez commented 8 years ago

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:

capture du 2016-05-11 23-38-38

It's better ?

mojavelinux commented 8 years ago

Yes, the unconstrained strong is now as expected. Can you apply the same to contained strong?

mojavelinux commented 8 years ago

I'd just like to pause and say how amazing that looks. It totally crushes the syntax highlighting in VIM now.

ldez commented 8 years ago

Can you apply the same to contained strong?

Yes and clean all others redundancy.

We kill VIM :smiley_cat:

nicorikken commented 8 years ago

Any particular reason for choosing font-size 0.7 over the 0.8 as previously set for subscript and superscript?

ldez commented 8 years ago

yes because sub is placing less on the bottom.

ldez commented 8 years ago

capture du 2016-05-12 00-38-04

ldez commented 8 years ago

@nicorikken @mojavelinux give me a LGTM ? :wink:

ldez commented 8 years ago

Don't let me in trouble :cold_sweat:

mojavelinux commented 8 years ago

LGTM

@nicorikken what are your thoughts about the markup. prefix on the attribute-list?

mojavelinux commented 8 years ago

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?

nicorikken commented 8 years ago

@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.

mojavelinux commented 8 years ago

:+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.