Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Support interpolated CoffeeKup #16

pyrotechnick opened this Issue Jan 2, 2011 · 8 comments


None yet
3 participants
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 commented Jan 5, 2011

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 commented Sep 13, 2011

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 commented Sep 14, 2011

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
  __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 commented Sep 14, 2011

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 commented Sep 14, 2011

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 commented Sep 14, 2011

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 commented Sep 14, 2011

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 commented Sep 14, 2011

Thanks to @smathy for the name.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment