One of the ideas I was working on a while ago was building an API for querying, so you’d also have stuff like
@items.find_by_attr(title: 'blah')
(which would be faster than with
#select)
@ddfreyne I'm exploring writing a
:sprockets filter. For .js files, but in fact I believe I can use it with .scss as well
@ddfreyne In a way, it's going to be similar to what I did for
:scss and :scss_sourcemap. What I will try to achieve with sprockets is //= require /some/nanoc/item/identifier.*
@ddfreyne this approach delegates everything to
:sprockets and :sprockets_sourcemap
@ddfreyne often, I feel like that I have needs for the following:
:filter1 leaves a trail for later filters
@ddfreyne the thing is, there's no practical way to let a filter "tag" items with custom information
@ddfreyne could Nanoc allow this?
like "I've been filtered with the
:mathjax filter" which would make the "wrapping layout" inject proper css stylesheet links
even the mere list of filter names that have been applied would enable interesting features
@item#filter() would return [:filter1, :filter2, ...] and the list would augment the more filtering passes have been applied
Thoughts comments questions concerns ideas
@ddfreyne what's the rationale behind https://nanoc.ws/doc/helpers/#writing-helpers somewhat telling helpers should be placed in modules while it's not the case for filters? https://nanoc.ws/doc/filters/#writing-filters
what's nanoc-live compared to guard-nanoc?
nanoc-live will replace guard-nano eventually
# Create context
context = ::Nanoc::Core::Context.new(assigns)
# Get binding
proc = assigns[:content] ? -> { assigns[:content] } : nil
assigns_binding = context.get_binding(&proc)
Bindings and context is… confusing for sure, heh. ERB is evaluated inside a context, where you have both stuff like
@item and item available. A Context has both those instance variables (so you can do @item), as well as methods #item (so you can do item).
This bit
assigns[:content] ? -> { assigns[:content] } : nilsays that, if there is a :content available (i.e. you’re layouting), then create a proc -> { assigns[:content] } — that proc yields the content. This makes it possible to say <%= yield %> — you’re essentially calling that proc
Finally, the
get_binding thing allows the ERB template to be evaluated inside that context
I know little about ERB
I'm wondering, when using
ERB, is it possible know at which line of the input content (the one with <%= ... %> syntax lives in) we are?
In other words, with a broader statement, could I derive sourcemap info from ERB processing?
That is doable I think.
also I commented on nanoc/features#55
@ddfreyne I spent two hours the other day trying to figure out why changes to one of my layout files stopped being tracked. it has happen a couple of times before. I change a layout, compile., and save another change to the file before the compilation is done. sometimes that puts that one layout file in a weird state. no matter how many changes I make to that layout file the changes won’t get compiled in. I must either move the offending layout file out of the way, run compile, let it fail, and then move it back; OR delete the tmp/cache/. It’s the same thing I’ve done every time this has happen. Editing a layout while nanoc is compiling. But I can’t reproduce it on demand.
The source code, that is