Support interpolated CoffeeKup about coffeekup

[mauricemach]

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]

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]

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]

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]

Thanks to @smathy for the name.