Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 16 12:02
    mojavelinux labeled #3914
  • Jan 16 12:02
    mojavelinux closed #3914
  • Jan 16 11:03
    john-cj edited #3914
  • Jan 16 11:03
    john-cj edited #3914
  • Jan 16 11:02
    john-cj opened #3914
  • Jan 16 00:36
    mojavelinux closed #3912
  • Jan 16 00:35
    mojavelinux closed #3913
  • Jan 14 18:24
    Mogztter opened #3913
  • Jan 14 18:19
    Mogztter opened #3912
  • Jan 11 18:41
    mojavelinux transferred #3911
  • Jan 11 18:41
    mojavelinux closed #3911
  • Jan 11 14:43
    harshmadhani opened #3911
  • Jan 11 13:09
    pstueck edited #3910
  • Jan 11 13:05
    pstueck edited #3910
  • Jan 11 13:03
    pstueck opened #3910
  • Jan 09 22:34
    djencks synchronize #3898
  • Jan 09 20:48
    djencks synchronize #3898
  • Jan 09 18:25
    djencks synchronize #3898
  • Jan 09 17:00
    djencks synchronize #3898
  • Jan 09 06:29
    djencks synchronize #3898
Dan Allen
@mojavelinux
there are still small quirks with the scroll offset that we cannot resolve because the browser just won't give us the information we need. but those would be hard to detect unless you were really pushing it to the limits.
djencks
@djencks
That will take some study :-)
Dan Allen
@mojavelinux
basically, what it does is determine what height it wants to have (based on the nav container size, which is fixed). then it figures out how much of the screen the footer is occupying. if that number is > 0, then it resizes the nav to compensate. otherwise, it lets the nav inherit the height from the container.
the scroll offset is preserved, though that isn't required for it to function
I still think the nav needs a redesign, but this logic will likely carry through no matter what we put inside that container
djencks
@djencks
if (window.getComputedStyle(navContainer).position === 'fixed') return means that if the navContainer is fixed there is no need to resize it?
(line 168)
djencks
@djencks
I only glanced at your gulp release task for the UI.... could everything be done with isomorphic git or is some of that really github specific?
Dan Allen
@mojavelinux
@djencks that's how we detect the mobile view (where the nav overlays onto the page)
@djencks it's github specific because we are tying into their release screen
to be clear, on mobile, the nav doesn't fit between the header and the footer, it sits on top of the screen
Dan Allen
@mojavelinux
reviewed. almost there. I'll admit even I am realizing my knowledge about the attribute parsing rules was not accurate. but I think we've got it now.
djencks
@djencks
@mojavelinux There's still a problem.... see comments. I'm going to eat dinner and if I still have awareness investigate more. I can't see why my example is a positional attribute from looking at the attribute list parser, I'll have to step through it.
Dan Allen
@mojavelinux
After thinking about it more, I realized there's a simpler explanation.
if the linked text contains an equal sign, and the text that precedes that equals sign (ignoring spaces that immediately precede the equals sign) is a valid attribute name (letters and numbers only), then it will be parsed as an attribute and the linked text will be empty.
Guillaume Grossetie
@Mogztter
I'm a bit torn on the Kroki preprocessing to resolve relative data, should we resolve them relative from the AsciiDoc file (doc.getBaseDir()) or from the diagram file?
[vegalite]
....
{
  "data": {"url": "data/seattle-weather.csv"},
  "mark": "tick",
  "encoding": {
    "x": {"field": "precipitation", "type": "quantitative"}
  }
}
....

[vegalite]
....
include::diagrams/weather.vlite[]
....

vegalite::diagrams/weather.vlite[]
the main "issue" is that if we resolve them relative to the diagram file then if we are using the include directive or if we inline the diagram in the document then we need to adjust the path
but at the same time, it seems more "logical" if the path is relative to the diagram file
(it can be used in different context, not just in an AsciiDoc file)
djencks
@djencks
Your first two examples, relative to the adoc file. The third, relative to the diagram.
Guillaume Grossetie
@Mogztter

Your first two examples, relative to the adoc file. The third, relative to the diagram.

Thanks

So you don't mind having to update the path to seattle-weather.csv depending on how the diagram is included/read from the AsciiDoc file?
Pepijn Van Eeckhoudt
@pepijnve
I had to do something similar for PlantUML already @Mogztter. I went for what @djencks suggested IIRC. Let me double check the code.
John
@john-cj

Many style guides suggest to give book titles in italics. That is, you may see something like "For more information about xyz, see Some Book of Your Choice", but we never use italics for people names.

I want to keep the same pattern for quotation attributes.

[quote, John Doe]
some text goes here

[quote, _Some Book_]
some text goes here

The problem is that I don't see a way to make Some Book in the second example italic. Even +++<i>Some Book</i>+++ doesn't work. Maybe there is some trick for this?

Dan Allen
@mojavelinux
enclose the text in single quotes
the single quotes enables normal substitutions
[quote, '_Some Book_']
I wrote my first GitHub Action! I did so in order to rewrite the retry deploy preview workflow for docs.asciidoctor.org to use the Netlify API. See https://github.com/mojavelinux/retry-netlify-deploy-preview-action
djencks
@djencks
@Mogztter The first example, there's no doubt it has to be resolved from the .adoc file because that's all there is. The third example, there's no doubt (in my mind) that it has to be resolved from the vlite file because you want the same result no matter what page you have the block macro. The second example is the same as the first example because of how includes work.
@mojavelinux 👍🎉
James Elliott
@brunchboy
Woot! I wrote one (very simple) to set some environment variables based on git tags in projects where I use those to establish version number and snapshot state.
John
@john-cj
Thanks, Dan :zap: :guitar:
Dan Allen
@mojavelinux
:+1:
Guillaume Grossetie
@Mogztter
@pepijnve alright!
Pepijn Van Eeckhoudt
@pepijnve
Sorry, our local school quiz got in the way of a definitive answer
Diagram uses the adoc document for the basedir for embedded and included diagrams and the file basedir for block macro diagrams
djencks
@djencks
👍As noted, that's the only way that makes sense to me.
Guillaume Grossetie
@Mogztter
OK sounds good, I was making sure that it is the expected behavior (and the already defined behavior in other popular extensions)
Thanks I will do the same 👍
Local school quiz! Sounds fun, can I play? 😉
Andrew Janke
@apjanke
Hi folks! I just wanted to drop in to say Thank You to the Asciidoctor team for producing such nice documentation for their stuff. I'm setting up some program documentation using Jekyll and the jekyll-asciidoctor plugin, and the thorough documentation is making it really easy.
djencks
@djencks
@mojavelinux Your turn :-) I came up with something for asciidoctor/asciidoc-docs#43 and asciidoctor/asciidoc-docs#33 is waiting for you. I'm not sure I understand the gitlab interface since it says there are changes requested and I changed the relevant text AFAICT....
djencks
@djencks

@Mogztter I'm trying out Opalizing a Ruby Asciidoctor extension. Opal seems to have a problem translating this line:

                   elsif /^\d+$/ =~ cite.locator

giving an error (partial stack trace):

/Users/david/projects/asciidoctor/extensions/asciidoctor-bibtex/node_modules/opal-compiler/src/opal-builder.js:2047
          } else { throw $err; }
                   ^
ruby/asciidoctor-bibtex/lib/asciidoctor-bibtex/processor.rb:in `end'
names: undefined method `names' for /^\d+$/
    at RegExp.$$method_missing (/Users/david/projects/asciidoctor/extensions/asciidoctor-bibtex/node_modules/opal-compiler/node_modules/opal-runtime/src/opal.js:4038:56)
    at RegExp.method_missing_stub (/Users/david/projects/asciidoctor/extensions/asciidoctor-bibtex/node_modules/opal-compiler/node_modules/opal-runtime/src/opal.js:1357:35)
    at constructor.$$match_op (/Users/david/projects/asciidoctor/extensions/asciidoctor-bibtex/node_modules/opal-compiler/src/opal-builder.js:17584:24)

Is this related to opal/opal#1964
The regex looks pretty innocuous to me... do you know if there's an easy way to rewrite it so it can be translated? Should I file an issue?

Dan Allen
@mojavelinux
As we work to rework our READMEs following the docs.asciidoctor.org launch, consider this resource if you need input: https://github.com/lappleapple/feedmereadmes (i'm not sure how receptive the maintainers are, but it's promising)
Guillaume Grossetie
@Mogztter
Sorry, the stack trace does not sound familiar to me but you're probably right issue 1964 seems related
But the regular expression is not using named groups... 🤔
djencks
@djencks
I found that rather confusing too :-)