Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Support interpolated CoffeeKup #16

Closed
pyrotechnick opened this Issue · 8 comments

3 participants

@pyrotechnick
h2 -> "Spinning the #{span -> 'Real-time'} Web"

currently compiles to

<h2><span>Real-time</span>Spinning the null Web</h2>

It would be nice to support this as I often find myself wanting to "span" things up within long paragraphs without breaking it up too much.

@mauricemach
Owner

It'd be nice indeed. But that would require a different implementation model I think. Currently when you execute a method like "span" you're writing to a buffer. To get the output in the order you expect we should change to a model based on return values instead, which I'm not sure is feasible. Do you have an idea on how this could work?

@colinta

a proposal, and a pull request!

h2 -> "Spinning the #{span.inline 'Real-time'} Web"

my implementation adds a 'buffers' array, and pushes/pops buffers using __ck.start and __ck.stop. __ck.stop returns old_buffer.join(''), which in a round-about way gets pushed onto the old buffer.

see gist 1213040 or commit dc175e2a03

@mauricemach
Owner

Insteresting approach!

I experimented further with your idea and ended up just this in the skeleton:

inline = (f) ->
  temp = []
  old = __ck.buffer
  __ck.buffer = temp
  f()
  __ck.buffer = old
  temp.join ''

Then we can write:

p "This text could use #{inline -> strong -> a href: '/', 'a link'}."

In other words, with inline you can get the output of a template chunk as a return value instead of having it write to the buffer.

What do you think?

I'm still not happy with the name "inline", I'd prefer something shorter and closer to the meaning of what's being done (returning instead of writing to the buffer).

@colinta

I dig it! I was at a loss as to how one could avoid #{strong.inline -> a.inline ...}. I was thinking that a lot of use cases would be for just one or two tags, so the .inline repetition wouldn't be a big deal. But it doesn't have the taste of "solution that works for all situations". Better, I think, to have one function that does that, rather than a bunch of .inline fn's (though, I do love to opportunity to treat functions like objects).

AFA the name... well, it's funny & annoying how often naming gets in the way of all the fun...

p "#{embed->strong->em 'What'} would go well there?"
p "#{here->strong->em 'What'} would go well there?"
p "#{plant->strong->em 'What'} would go well there?"
p "#{o->strong->em 'What'} would go well there?"

Good luck with that decision! I can't say I like any of these (or dislike one more than another). I just wanted to see what they looked like in code.

@mauricemach
Owner

I love function.function too, and I'll surely exploit it more in the future with coffeekup and zappa.

Yes, most use cases will be really short, and I think even the function -> chunk solution is still too bloated for that. But I guess the only room for improvement here is picking a shorter name.

Ditto, naming is freaking annoying... but I can't help it. :) I need meaningful, short names to compensate for my limited brain.

BTW, I'll put your git username and email in the contributors list, if you don't mind.

@mauricemach
Owner

Hey, you're jj's author! :) I found it today and it seems very interesting, though I wasn't able to have a closer look yet (npm has been acting funny today).

@colinta

I am indeed! It's exciting to have it noticed so quickly after its inception. Soon here I'm going to spend a hefty chunk of time getting some more packages in there.

And of course I'd be honored to be mentioned on the contributors list :-)

@mauricemach
Owner

Thanks to @smathy for the name.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.