So far I really love Haml, but I have an issue with it where it comes
to preformatted text.I have a fairly large amount of preformatted text
(generated on the fly by a Rails helper) that I'm trying to include
into my page. Using the :preserve filter, it /looks/ fine, but in the
source it's all on one line, word-wrapped to about thirty, and
completely indecipherable.
I discussed this briefly with Nex3 on IRC, but he had to run. While
writing this message, though, I did have an idea: would it be possible
to add another tag prefix, using either a _ (underscore) or a |
(pipe), to tell Haml that the tag's indentation (or at least its
content) should be reset? Nex3 had mentioned that Haml couldn't
determine when it was safe to perserve the literal newlines because it
automatically indents text, but if you used | to reset indentation, it
seems like it would be safer for Haml to do. If that was possible, I
think "%pre|<" would work perfectly for my purposes.
Otherwise, some advice would be very much appreciated! Thanks in
advance,
~Jonathan Castello
First of all, filters like :preserve aren't meant for handling
dynamically-generated text; they're meant for handling literal, in-template
text with maybe some dynamic stuff sprinkled in. If you're dynamically
generating text, it's better to use the #preserve helper (or ~, which is a
shortcut for same).
As for the source code aesthetics, as I mentioned on IRC, there's really no
good way to tell when it's possible to not use newline entities. Declaring
it in the template won't work, because it's *not* safe in that template -
the template still needs to be included in the layout, which will re-indent
it and cause the whitespace to go wrong. The only potential solution is to
have some way of declaring "this template is never going to be included in
another template", something that might be added in the future.
On Sat, Oct 24, 2009 at 12:47 PM, Twisol <solu...@hotmail.com> wrote:
> Hello,
> So far I really love Haml, but I have an issue with it where it comes
> to preformatted text.I have a fairly large amount of preformatted text
> (generated on the fly by a Rails helper) that I'm trying to include
> into my page. Using the :preserve filter, it /looks/ fine, but in the
> source it's all on one line, word-wrapped to about thirty, and
> completely indecipherable.
> I discussed this briefly with Nex3 on IRC, but he had to run. While
> writing this message, though, I did have an idea: would it be possible
> to add another tag prefix, using either a _ (underscore) or a |
> (pipe), to tell Haml that the tag's indentation (or at least its
> content) should be reset? Nex3 had mentioned that Haml couldn't
> determine when it was safe to perserve the literal newlines because it
> automatically indents text, but if you used | to reset indentation, it
> seems like it would be safer for Haml to do. If that was possible, I
> think "%pre|<" would work perfectly for my purposes.
> Otherwise, some advice would be very much appreciated! Thanks in
> advance,
> ~Jonathan Castello
Can't haml have some concept of a pre-formatted bit that gets set and then
is sticky for the rest of the handling of that template? If the bit is set,
haml layouts wouldn't re-indent those strings. This decision could be made
dynamically and helpers could be made to help manage the formatting bit.
chris
(Implementation suggestion: haml can return an extended string object for
tracking the state of preformatting)
On Sat, Oct 24, 2009 at 1:10 PM, Nathan Weizenbaum <nex...@gmail.com> wrote:
> First of all, filters like :preserve aren't meant for handling
> dynamically-generated text; they're meant for handling literal, in-template
> text with maybe some dynamic stuff sprinkled in. If you're dynamically
> generating text, it's better to use the #preserve helper (or ~, which is a
> shortcut for same).
> As for the source code aesthetics, as I mentioned on IRC, there's really no
> good way to tell when it's possible to not use newline entities. Declaring
> it in the template won't work, because it's *not* safe in that template -
> the template still needs to be included in the layout, which will re-indent
> it and cause the whitespace to go wrong. The only potential solution is to
> have some way of declaring "this template is never going to be included in
> another template", something that might be added in the future.
> On Sat, Oct 24, 2009 at 12:47 PM, Twisol <solu...@hotmail.com> wrote:
>> Hello,
>> So far I really love Haml, but I have an issue with it where it comes
>> to preformatted text.I have a fairly large amount of preformatted text
>> (generated on the fly by a Rails helper) that I'm trying to include
>> into my page. Using the :preserve filter, it /looks/ fine, but in the
>> source it's all on one line, word-wrapped to about thirty, and
>> completely indecipherable.
>> I discussed this briefly with Nex3 on IRC, but he had to run. While
>> writing this message, though, I did have an idea: would it be possible
>> to add another tag prefix, using either a _ (underscore) or a |
>> (pipe), to tell Haml that the tag's indentation (or at least its
>> content) should be reset? Nex3 had mentioned that Haml couldn't
>> determine when it was safe to perserve the literal newlines because it
>> automatically indents text, but if you used | to reset indentation, it
>> seems like it would be safer for Haml to do. If that was possible, I
>> think "%pre|<" would work perfectly for my purposes.
>> Otherwise, some advice would be very much appreciated! Thanks in
>> advance,
>> ~Jonathan Castello
Potentially, yes, but that would dramatically increase the cost of string
concatenation, which is something we desperately want to avoid, since string
concatenation happens a lot during the rendering of a Haml template.
On Sat, Oct 24, 2009 at 1:19 PM, Chris Eppstein <ch...@eppsteins.net> wrote:
> Can't haml have some concept of a pre-formatted bit that gets set and then
> is sticky for the rest of the handling of that template? If the bit is set,
> haml layouts wouldn't re-indent those strings. This decision could be made
> dynamically and helpers could be made to help manage the formatting bit.
> chris
> (Implementation suggestion: haml can return an extended string object for
> tracking the state of preformatting)
> On Sat, Oct 24, 2009 at 1:10 PM, Nathan Weizenbaum <nex...@gmail.com>wrote:
>> First of all, filters like :preserve aren't meant for handling
>> dynamically-generated text; they're meant for handling literal, in-template
>> text with maybe some dynamic stuff sprinkled in. If you're dynamically
>> generating text, it's better to use the #preserve helper (or ~, which is a
>> shortcut for same).
>> As for the source code aesthetics, as I mentioned on IRC, there's really
>> no good way to tell when it's possible to not use newline entities.
>> Declaring it in the template won't work, because it's *not* safe in that
>> template - the template still needs to be included in the layout, which will
>> re-indent it and cause the whitespace to go wrong. The only potential
>> solution is to have some way of declaring "this template is never going to
>> be included in another template", something that might be added in the
>> future.
>> On Sat, Oct 24, 2009 at 12:47 PM, Twisol <solu...@hotmail.com> wrote:
>>> Hello,
>>> So far I really love Haml, but I have an issue with it where it comes
>>> to preformatted text.I have a fairly large amount of preformatted text
>>> (generated on the fly by a Rails helper) that I'm trying to include
>>> into my page. Using the :preserve filter, it /looks/ fine, but in the
>>> source it's all on one line, word-wrapped to about thirty, and
>>> completely indecipherable.
>>> I discussed this briefly with Nex3 on IRC, but he had to run. While
>>> writing this message, though, I did have an idea: would it be possible
>>> to add another tag prefix, using either a _ (underscore) or a |
>>> (pipe), to tell Haml that the tag's indentation (or at least its
>>> content) should be reset? Nex3 had mentioned that Haml couldn't
>>> determine when it was safe to perserve the literal newlines because it
>>> automatically indents text, but if you used | to reset indentation, it
>>> seems like it would be safer for Haml to do. If that was possible, I
>>> think "%pre|<" would work perfectly for my purposes.
>>> Otherwise, some advice would be very much appreciated! Thanks in
>>> advance,
>>> ~Jonathan Castello
I've converted the offending preformatted partials back to ERb, since
this seems like a good place for it. Now my only issue is the
indentation, because the layout file is still Haml. If the | mark I
suggested was added, to reset indentation, it would make it easier to
include ERb partials like this, and my problem would be duly solved.
On Oct 24, 1:21 pm, Nathan Weizenbaum <nex...@gmail.com> wrote:
> Potentially, yes, but that would dramatically increase the cost of string
> concatenation, which is something we desperately want to avoid, since string
> concatenation happens a lot during the rendering of a Haml template.
> On Sat, Oct 24, 2009 at 1:19 PM, Chris Eppstein <ch...@eppsteins.net> wrote:
> > Can't haml have some concept of a pre-formatted bit that gets set and then
> > is sticky for the rest of the handling of that template? If the bit is set,
> > haml layouts wouldn't re-indent those strings. This decision could be made
> > dynamically and helpers could be made to help manage the formatting bit.
> > chris
> > (Implementation suggestion: haml can return an extended string object for
> > tracking the state of preformatting)
> > On Sat, Oct 24, 2009 at 1:10 PM, Nathan Weizenbaum <nex...@gmail.com>wrote:
> >> First of all, filters like :preserve aren't meant for handling
> >> dynamically-generated text; they're meant for handling literal, in-template
> >> text with maybe some dynamic stuff sprinkled in. If you're dynamically
> >> generating text, it's better to use the #preserve helper (or ~, which is a
> >> shortcut for same).
> >> As for the source code aesthetics, as I mentioned on IRC, there's really
> >> no good way to tell when it's possible to not use newline entities.
> >> Declaring it in the template won't work, because it's *not* safe in that
> >> template - the template still needs to be included in the layout, which will
> >> re-indent it and cause the whitespace to go wrong. The only potential
> >> solution is to have some way of declaring "this template is never going to
> >> be included in another template", something that might be added in the
> >> future.
> >> On Sat, Oct 24, 2009 at 12:47 PM, Twisol <solu...@hotmail.com> wrote:
> >>> Hello,
> >>> So far I really love Haml, but I have an issue with it where it comes
> >>> to preformatted text.I have a fairly large amount of preformatted text
> >>> (generated on the fly by a Rails helper) that I'm trying to include
> >>> into my page. Using the :preserve filter, it /looks/ fine, but in the
> >>> source it's all on one line, word-wrapped to about thirty, and
> >>> completely indecipherable.
> >>> I discussed this briefly with Nex3 on IRC, but he had to run. While
> >>> writing this message, though, I did have an idea: would it be possible
> >>> to add another tag prefix, using either a _ (underscore) or a |
> >>> (pipe), to tell Haml that the tag's indentation (or at least its
> >>> content) should be reset? Nex3 had mentioned that Haml couldn't
> >>> determine when it was safe to perserve the literal newlines because it
> >>> automatically indents text, but if you used | to reset indentation, it
> >>> seems like it would be safer for Haml to do. If that was possible, I
> >>> think "%pre|<" would work perfectly for my purposes.
> >>> Otherwise, some advice would be very much appreciated! Thanks in
> >>> advance,
> >>> ~Jonathan Castello
Converting the partials to ERB isn't going to help, since (as you noted) the
issue comes from the Haml layout re-indenting the code. I don't see how a
syntactic marker could help this, unless you want the entire partial to be
un-indented. A better solution would be to make an unpreserve helper that
you wrap your partial calls in in the layout that converts newline entities
into actual newlines.
On Sat, Oct 24, 2009 at 1:24 PM, Twisol <solu...@hotmail.com> wrote:
> I've converted the offending preformatted partials back to ERb, since
> this seems like a good place for it. Now my only issue is the
> indentation, because the layout file is still Haml. If the | mark I
> suggested was added, to reset indentation, it would make it easier to
> include ERb partials like this, and my problem would be duly solved.
> On Oct 24, 1:21 pm, Nathan Weizenbaum <nex...@gmail.com> wrote:
> > Potentially, yes, but that would dramatically increase the cost of string
> > concatenation, which is something we desperately want to avoid, since
> string
> > concatenation happens a lot during the rendering of a Haml template.
> > On Sat, Oct 24, 2009 at 1:19 PM, Chris Eppstein <ch...@eppsteins.net>
> wrote:
> > > Can't haml have some concept of a pre-formatted bit that gets set and
> then
> > > is sticky for the rest of the handling of that template? If the bit is
> set,
> > > haml layouts wouldn't re-indent those strings. This decision could be
> made
> > > dynamically and helpers could be made to help manage the formatting
> bit.
> > > chris
> > > (Implementation suggestion: haml can return an extended string object
> for
> > > tracking the state of preformatting)
> > > On Sat, Oct 24, 2009 at 1:10 PM, Nathan Weizenbaum <nex...@gmail.com
> >wrote:
> > >> First of all, filters like :preserve aren't meant for handling
> > >> dynamically-generated text; they're meant for handling literal,
> in-template
> > >> text with maybe some dynamic stuff sprinkled in. If you're dynamically
> > >> generating text, it's better to use the #preserve helper (or ~, which
> is a
> > >> shortcut for same).
> > >> As for the source code aesthetics, as I mentioned on IRC, there's
> really
> > >> no good way to tell when it's possible to not use newline entities.
> > >> Declaring it in the template won't work, because it's *not* safe in
> that
> > >> template - the template still needs to be included in the layout,
> which will
> > >> re-indent it and cause the whitespace to go wrong. The only potential
> > >> solution is to have some way of declaring "this template is never
> going to
> > >> be included in another template", something that might be added in the
> > >> future.
> > >> On Sat, Oct 24, 2009 at 12:47 PM, Twisol <solu...@hotmail.com> wrote:
> > >>> Hello,
> > >>> So far I really love Haml, but I have an issue with it where it comes
> > >>> to preformatted text.I have a fairly large amount of preformatted
> text
> > >>> (generated on the fly by a Rails helper) that I'm trying to include
> > >>> into my page. Using the :preserve filter, it /looks/ fine, but in the
> > >>> source it's all on one line, word-wrapped to about thirty, and
> > >>> completely indecipherable.
> > >>> I discussed this briefly with Nex3 on IRC, but he had to run. While
> > >>> writing this message, though, I did have an idea: would it be
> possible
> > >>> to add another tag prefix, using either a _ (underscore) or a |
> > >>> (pipe), to tell Haml that the tag's indentation (or at least its
> > >>> content) should be reset? Nex3 had mentioned that Haml couldn't
> > >>> determine when it was safe to perserve the literal newlines because
> it
> > >>> automatically indents text, but if you used | to reset indentation,
> it
> > >>> seems like it would be safer for Haml to do. If that was possible, I
> > >>> think "%pre|<" would work perfectly for my purposes.
> > >>> Otherwise, some advice would be very much appreciated! Thanks in
> > >>> advance,
> > >>> ~Jonathan Castello
That's exactly what I'd like to do: make the entire partial
unindented. I envision a | mark resetting the indentation level for
the tag it's used on; if there are nested tags, they would still be
indented, but relative to the reset level. When used with my ERb
partials, I'm basically saying that I'm taking indentation into my own
hands, which is precisely what I require for my preformatted text.
I'll look into writing an unpreserve helper, but I still like the
(perceived) elegance of my | suggestion. Thanks for your time.
On Oct 24, 1:59 pm, Nathan Weizenbaum <nex...@gmail.com> wrote:
> Converting the partials to ERB isn't going to help, since (as you noted) the
> issue comes from the Haml layout re-indenting the code. I don't see how a
> syntactic marker could help this, unless you want the entire partial to be
> un-indented. A better solution would be to make an unpreserve helper that
> you wrap your partial calls in in the layout that converts newline entities
> into actual newlines.
> On Sat, Oct 24, 2009 at 1:24 PM, Twisol <solu...@hotmail.com> wrote:
> > I've converted the offending preformatted partials back to ERb, since
> > this seems like a good place for it. Now my only issue is the
> > indentation, because the layout file is still Haml. If the | mark I
> > suggested was added, to reset indentation, it would make it easier to
> > include ERb partials like this, and my problem would be duly solved.
> > On Oct 24, 1:21 pm, Nathan Weizenbaum <nex...@gmail.com> wrote:
> > > Potentially, yes, but that would dramatically increase the cost of string
> > > concatenation, which is something we desperately want to avoid, since
> > string
> > > concatenation happens a lot during the rendering of a Haml template.
> > > On Sat, Oct 24, 2009 at 1:19 PM, Chris Eppstein <ch...@eppsteins.net>
> > wrote:
> > > > Can't haml have some concept of a pre-formatted bit that gets set and
> > then
> > > > is sticky for the rest of the handling of that template? If the bit is
> > set,
> > > > haml layouts wouldn't re-indent those strings. This decision could be
> > made
> > > > dynamically and helpers could be made to help manage the formatting
> > bit.
> > > > chris
> > > > (Implementation suggestion: haml can return an extended string object
> > for
> > > > tracking the state of preformatting)
> > > > On Sat, Oct 24, 2009 at 1:10 PM, Nathan Weizenbaum <nex...@gmail.com
> > >wrote:
> > > >> First of all, filters like :preserve aren't meant for handling
> > > >> dynamically-generated text; they're meant for handling literal,
> > in-template
> > > >> text with maybe some dynamic stuff sprinkled in. If you're dynamically
> > > >> generating text, it's better to use the #preserve helper (or ~, which
> > is a
> > > >> shortcut for same).
> > > >> As for the source code aesthetics, as I mentioned on IRC, there's
> > really
> > > >> no good way to tell when it's possible to not use newline entities.
> > > >> Declaring it in the template won't work, because it's *not* safe in
> > that
> > > >> template - the template still needs to be included in the layout,
> > which will
> > > >> re-indent it and cause the whitespace to go wrong. The only potential
> > > >> solution is to have some way of declaring "this template is never
> > going to
> > > >> be included in another template", something that might be added in the
> > > >> future.
> > > >> On Sat, Oct 24, 2009 at 12:47 PM, Twisol <solu...@hotmail.com> wrote:
> > > >>> Hello,
> > > >>> So far I really love Haml, but I have an issue with it where it comes
> > > >>> to preformatted text.I have a fairly large amount of preformatted
> > text
> > > >>> (generated on the fly by a Rails helper) that I'm trying to include
> > > >>> into my page. Using the :preserve filter, it /looks/ fine, but in the
> > > >>> source it's all on one line, word-wrapped to about thirty, and
> > > >>> completely indecipherable.
> > > >>> I discussed this briefly with Nex3 on IRC, but he had to run. While
> > > >>> writing this message, though, I did have an idea: would it be
> > possible
> > > >>> to add another tag prefix, using either a _ (underscore) or a |
> > > >>> (pipe), to tell Haml that the tag's indentation (or at least its
> > > >>> content) should be reset? Nex3 had mentioned that Haml couldn't
> > > >>> determine when it was safe to perserve the literal newlines because
> > it
> > > >>> automatically indents text, but if you used | to reset indentation,
> > it
> > > >>> seems like it would be safer for Haml to do. If that was possible, I
> > > >>> think "%pre|<" would work perfectly for my purposes.
> > > >>> Otherwise, some advice would be very much appreciated! Thanks in
> > > >>> advance,
> > > >>> ~Jonathan Castello
After attempting to write an 'unpreserve' helper (which merely gsub's
HTML-entity newlines into literal newlines), I'm still suffering the
exact same indentation issues. It seems like, currently, there's just
no way to stop indentation -and- preserve literal newlines. :perserve
does the former, and ~ the latter, but I can't for the life of me
produce both effects.
On Oct 24, 2:15 pm, Twisol <solu...@hotmail.com> wrote:
> That's exactly what I'd like to do: make the entire partial
> unindented. I envision a | mark resetting the indentation level for
> the tag it's used on; if there are nested tags, they would still be
> indented, but relative to the reset level. When used with my ERb
> partials, I'm basically saying that I'm taking indentation into my own
> hands, which is precisely what I require for my preformatted text.
> I'll look into writing an unpreserve helper, but I still like the
> (perceived) elegance of my | suggestion. Thanks for your time.
> On Oct 24, 1:59 pm, Nathan Weizenbaum <nex...@gmail.com> wrote:
> > Converting the partials to ERB isn't going to help, since (as you noted) the
> > issue comes from the Haml layout re-indenting the code. I don't see how a
> > syntactic marker could help this, unless you want the entire partial to be
> > un-indented. A better solution would be to make an unpreserve helper that
> > you wrap your partial calls in in the layout that converts newline entities
> > into actual newlines.
> > On Sat, Oct 24, 2009 at 1:24 PM, Twisol <solu...@hotmail.com> wrote:
> > > I've converted the offending preformatted partials back to ERb, since
> > > this seems like a good place for it. Now my only issue is the
> > > indentation, because the layout file is still Haml. If the | mark I
> > > suggested was added, to reset indentation, it would make it easier to
> > > include ERb partials like this, and my problem would be duly solved.
> > > On Oct 24, 1:21 pm, Nathan Weizenbaum <nex...@gmail.com> wrote:
> > > > Potentially, yes, but that would dramatically increase the cost of string
> > > > concatenation, which is something we desperately want to avoid, since
> > > string
> > > > concatenation happens a lot during the rendering of a Haml template.
> > > > On Sat, Oct 24, 2009 at 1:19 PM, Chris Eppstein <ch...@eppsteins.net>
> > > wrote:
> > > > > Can't haml have some concept of a pre-formatted bit that gets set and
> > > then
> > > > > is sticky for the rest of the handling of that template? If the bit is
> > > set,
> > > > > haml layouts wouldn't re-indent those strings. This decision could be
> > > made
> > > > > dynamically and helpers could be made to help manage the formatting
> > > bit.
> > > > > chris
> > > > > (Implementation suggestion: haml can return an extended string object
> > > for
> > > > > tracking the state of preformatting)
> > > > > On Sat, Oct 24, 2009 at 1:10 PM, Nathan Weizenbaum <nex...@gmail.com
> > > >wrote:
> > > > >> First of all, filters like :preserve aren't meant for handling
> > > > >> dynamically-generated text; they're meant for handling literal,
> > > in-template
> > > > >> text with maybe some dynamic stuff sprinkled in. If you're dynamically
> > > > >> generating text, it's better to use the #preserve helper (or ~, which
> > > is a
> > > > >> shortcut for same).
> > > > >> As for the source code aesthetics, as I mentioned on IRC, there's
> > > really
> > > > >> no good way to tell when it's possible to not use newline entities.
> > > > >> Declaring it in the template won't work, because it's *not* safe in
> > > that
> > > > >> template - the template still needs to be included in the layout,
> > > which will
> > > > >> re-indent it and cause the whitespace to go wrong. The only potential
> > > > >> solution is to have some way of declaring "this template is never
> > > going to
> > > > >> be included in another template", something that might be added in the
> > > > >> future.
> > > > >> On Sat, Oct 24, 2009 at 12:47 PM, Twisol <solu...@hotmail.com> wrote:
> > > > >>> Hello,
> > > > >>> So far I really love Haml, but I have an issue with it where it comes
> > > > >>> to preformatted text.I have a fairly large amount of preformatted
> > > text
> > > > >>> (generated on the fly by a Rails helper) that I'm trying to include
> > > > >>> into my page. Using the :preserve filter, it /looks/ fine, but in the
> > > > >>> source it's all on one line, word-wrapped to about thirty, and
> > > > >>> completely indecipherable.
> > > > >>> I discussed this briefly with Nex3 on IRC, but he had to run. While
> > > > >>> writing this message, though, I did have an idea: would it be
> > > possible
> > > > >>> to add another tag prefix, using either a _ (underscore) or a |
> > > > >>> (pipe), to tell Haml that the tag's indentation (or at least its
> > > > >>> content) should be reset? Nex3 had mentioned that Haml couldn't
> > > > >>> determine when it was safe to perserve the literal newlines because
> > > it
> > > > >>> automatically indents text, but if you used | to reset indentation,
> > > it
> > > > >>> seems like it would be safer for Haml to do. If that was possible, I
> > > > >>> think "%pre|<" would work perfectly for my purposes.
> > > > >>> Otherwise, some advice would be very much appreciated! Thanks in
> > > > >>> advance,
> > > > >>> ~Jonathan Castello
I guess you'd need unpreserve along with some way of not indenting the
partial. Or you could simply run #unpreserve on the finished template once
it's rendered. In any case, I don't want to add new syntax to Haml for what
amounts to a relatively minor, purely aesthetic issue.
On Sat, Oct 24, 2009 at 5:13 PM, Twisol <solu...@hotmail.com> wrote:
> After attempting to write an 'unpreserve' helper (which merely gsub's
> HTML-entity newlines into literal newlines), I'm still suffering the
> exact same indentation issues. It seems like, currently, there's just
> no way to stop indentation -and- preserve literal newlines. :perserve
> does the former, and ~ the latter, but I can't for the life of me
> produce both effects.
> On Oct 24, 2:15 pm, Twisol <solu...@hotmail.com> wrote:
> > That's exactly what I'd like to do: make the entire partial
> > unindented. I envision a | mark resetting the indentation level for
> > the tag it's used on; if there are nested tags, they would still be
> > indented, but relative to the reset level. When used with my ERb
> > partials, I'm basically saying that I'm taking indentation into my own
> > hands, which is precisely what I require for my preformatted text.
> > I'll look into writing an unpreserve helper, but I still like the
> > (perceived) elegance of my | suggestion. Thanks for your time.
> > On Oct 24, 1:59 pm, Nathan Weizenbaum <nex...@gmail.com> wrote:
> > > Converting the partials to ERB isn't going to help, since (as you
> noted) the
> > > issue comes from the Haml layout re-indenting the code. I don't see how
> a
> > > syntactic marker could help this, unless you want the entire partial to
> be
> > > un-indented. A better solution would be to make an unpreserve helper
> that
> > > you wrap your partial calls in in the layout that converts newline
> entities
> > > into actual newlines.
> > > On Sat, Oct 24, 2009 at 1:24 PM, Twisol <solu...@hotmail.com> wrote:
> > > > I've converted the offending preformatted partials back to ERb, since
> > > > this seems like a good place for it. Now my only issue is the
> > > > indentation, because the layout file is still Haml. If the | mark I
> > > > suggested was added, to reset indentation, it would make it easier to
> > > > include ERb partials like this, and my problem would be duly solved.
> > > > On Oct 24, 1:21 pm, Nathan Weizenbaum <nex...@gmail.com> wrote:
> > > > > Potentially, yes, but that would dramatically increase the cost of
> string
> > > > > concatenation, which is something we desperately want to avoid,
> since
> > > > string
> > > > > concatenation happens a lot during the rendering of a Haml
> template.
> > > > > On Sat, Oct 24, 2009 at 1:19 PM, Chris Eppstein <
> ch...@eppsteins.net>
> > > > wrote:
> > > > > > Can't haml have some concept of a pre-formatted bit that gets set
> and
> > > > then
> > > > > > is sticky for the rest of the handling of that template? If the
> bit is
> > > > set,
> > > > > > haml layouts wouldn't re-indent those strings. This decision
> could be
> > > > made
> > > > > > dynamically and helpers could be made to help manage the
> formatting
> > > > bit.
> > > > > > chris
> > > > > > (Implementation suggestion: haml can return an extended string
> object
> > > > for
> > > > > > tracking the state of preformatting)
> > > > > > On Sat, Oct 24, 2009 at 1:10 PM, Nathan Weizenbaum <
> nex...@gmail.com
> > > > >wrote:
> > > > > >> First of all, filters like :preserve aren't meant for handling
> > > > > >> dynamically-generated text; they're meant for handling literal,
> > > > in-template
> > > > > >> text with maybe some dynamic stuff sprinkled in. If you're
> dynamically
> > > > > >> generating text, it's better to use the #preserve helper (or ~,
> which
> > > > is a
> > > > > >> shortcut for same).
> > > > > >> As for the source code aesthetics, as I mentioned on IRC,
> there's
> > > > really
> > > > > >> no good way to tell when it's possible to not use newline
> entities.
> > > > > >> Declaring it in the template won't work, because it's *not* safe
> in
> > > > that
> > > > > >> template - the template still needs to be included in the
> layout,
> > > > which will
> > > > > >> re-indent it and cause the whitespace to go wrong. The only
> potential
> > > > > >> solution is to have some way of declaring "this template is
> never
> > > > going to
> > > > > >> be included in another template", something that might be added
> in the
> > > > > >> future.
> > > > > >> On Sat, Oct 24, 2009 at 12:47 PM, Twisol <solu...@hotmail.com>
> wrote:
> > > > > >>> Hello,
> > > > > >>> So far I really love Haml, but I have an issue with it where it
> comes
> > > > > >>> to preformatted text.I have a fairly large amount of
> preformatted
> > > > text
> > > > > >>> (generated on the fly by a Rails helper) that I'm trying to
> include
> > > > > >>> into my page. Using the :preserve filter, it /looks/ fine, but
> in the
> > > > > >>> source it's all on one line, word-wrapped to about thirty, and
> > > > > >>> completely indecipherable.
> > > > > >>> I discussed this briefly with Nex3 on IRC, but he had to run.
> While
> > > > > >>> writing this message, though, I did have an idea: would it be
> > > > possible
> > > > > >>> to add another tag prefix, using either a _ (underscore) or a |
> > > > > >>> (pipe), to tell Haml that the tag's indentation (or at least
> its
> > > > > >>> content) should be reset? Nex3 had mentioned that Haml couldn't
> > > > > >>> determine when it was safe to perserve the literal newlines
> because
> > > > it
> > > > > >>> automatically indents text, but if you used | to reset
> indentation,
> > > > it
> > > > > >>> seems like it would be safer for Haml to do. If that was
> possible, I
> > > > > >>> think "%pre|<" would work perfectly for my purposes.
> > > > > >>> Otherwise, some advice would be very much appreciated! Thanks
> in
> > > > > >>> advance,
> > > > > >>> ~Jonathan Castello
Pardon my naiveté, but could you give me an example of how to go about
doing that? I've tried using my homemade unpreserve helper at many
points along the chain of partials, with no real success.
On Oct 25, 12:28 pm, Nathan Weizenbaum <nex...@gmail.com> wrote:
> I guess you'd need unpreserve along with some way of not indenting the
> partial. Or you could simply run #unpreserve on the finished template once
> it's rendered. In any case, I don't want to add new syntax to Haml for what
> amounts to a relatively minor, purely aesthetic issue.
> On Sat, Oct 24, 2009 at 5:13 PM, Twisol <solu...@hotmail.com> wrote:
> > After attempting to write an 'unpreserve' helper (which merely gsub's
> > HTML-entity newlines into literal newlines), I'm still suffering the
> > exact same indentation issues. It seems like, currently, there's just
> > no way to stop indentation -and- preserve literal newlines. :perserve
> > does the former, and ~ the latter, but I can't for the life of me
> > produce both effects.
> > On Oct 24, 2:15 pm, Twisol <solu...@hotmail.com> wrote:
> > > That's exactly what I'd like to do: make the entire partial
> > > unindented. I envision a | mark resetting the indentation level for
> > > the tag it's used on; if there are nested tags, they would still be
> > > indented, but relative to the reset level. When used with my ERb
> > > partials, I'm basically saying that I'm taking indentation into my own
> > > hands, which is precisely what I require for my preformatted text.
> > > I'll look into writing an unpreserve helper, but I still like the
> > > (perceived) elegance of my | suggestion. Thanks for your time.
> > > On Oct 24, 1:59 pm, Nathan Weizenbaum <nex...@gmail.com> wrote:
> > > > Converting the partials to ERB isn't going to help, since (as you
> > noted) the
> > > > issue comes from the Haml layout re-indenting the code. I don't see how
> > a
> > > > syntactic marker could help this, unless you want the entire partial to
> > be
> > > > un-indented. A better solution would be to make an unpreserve helper
> > that
> > > > you wrap your partial calls in in the layout that converts newline
> > entities
> > > > into actual newlines.
> > > > On Sat, Oct 24, 2009 at 1:24 PM, Twisol <solu...@hotmail.com> wrote:
> > > > > I've converted the offending preformatted partials back to ERb, since
> > > > > this seems like a good place for it. Now my only issue is the
> > > > > indentation, because the layout file is still Haml. If the | mark I
> > > > > suggested was added, to reset indentation, it would make it easier to
> > > > > include ERb partials like this, and my problem would be duly solved.
> > > > > On Oct 24, 1:21 pm, Nathan Weizenbaum <nex...@gmail.com> wrote:
> > > > > > Potentially, yes, but that would dramatically increase the cost of
> > string
> > > > > > concatenation, which is something we desperately want to avoid,
> > since
> > > > > string
> > > > > > concatenation happens a lot during the rendering of a Haml
> > template.
> > > > > > On Sat, Oct 24, 2009 at 1:19 PM, Chris Eppstein <
> > ch...@eppsteins.net>
> > > > > wrote:
> > > > > > > Can't haml have some concept of a pre-formatted bit that gets set
> > and
> > > > > then
> > > > > > > is sticky for the rest of the handling of that template? If the
> > bit is
> > > > > set,
> > > > > > > haml layouts wouldn't re-indent those strings. This decision
> > could be
> > > > > made
> > > > > > > dynamically and helpers could be made to help manage the
> > formatting
> > > > > bit.
> > > > > > > chris
> > > > > > > (Implementation suggestion: haml can return an extended string
> > object
> > > > > for
> > > > > > > tracking the state of preformatting)
> > > > > > > On Sat, Oct 24, 2009 at 1:10 PM, Nathan Weizenbaum <
> > nex...@gmail.com
> > > > > >wrote:
> > > > > > >> First of all, filters like :preserve aren't meant for handling
> > > > > > >> dynamically-generated text; they're meant for handling literal,
> > > > > in-template
> > > > > > >> text with maybe some dynamic stuff sprinkled in. If you're
> > dynamically
> > > > > > >> generating text, it's better to use the #preserve helper (or ~,
> > which
> > > > > is a
> > > > > > >> shortcut for same).
> > > > > > >> As for the source code aesthetics, as I mentioned on IRC,
> > there's
> > > > > really
> > > > > > >> no good way to tell when it's possible to not use newline
> > entities.
> > > > > > >> Declaring it in the template won't work, because it's *not* safe
> > in
> > > > > that
> > > > > > >> template - the template still needs to be included in the
> > layout,
> > > > > which will
> > > > > > >> re-indent it and cause the whitespace to go wrong. The only
> > potential
> > > > > > >> solution is to have some way of declaring "this template is
> > never
> > > > > going to
> > > > > > >> be included in another template", something that might be added
> > in the
> > > > > > >> future.
> > > > > > >> On Sat, Oct 24, 2009 at 12:47 PM, Twisol <solu...@hotmail.com>
> > wrote:
> > > > > > >>> Hello,
> > > > > > >>> So far I really love Haml, but I have an issue with it where it
> > comes
> > > > > > >>> to preformatted text.I have a fairly large amount of
> > preformatted
> > > > > text
> > > > > > >>> (generated on the fly by a Rails helper) that I'm trying to
> > include
> > > > > > >>> into my page. Using the :preserve filter, it /looks/ fine, but
> > in the
> > > > > > >>> source it's all on one line, word-wrapped to about thirty, and
> > > > > > >>> completely indecipherable.
> > > > > > >>> I discussed this briefly with Nex3 on IRC, but he had to run.
> > While
> > > > > > >>> writing this message, though, I did have an idea: would it be
> > > > > possible
> > > > > > >>> to add another tag prefix, using either a _ (underscore) or a |
> > > > > > >>> (pipe), to tell Haml that the tag's indentation (or at least
> > its
> > > > > > >>> content) should be reset? Nex3 had mentioned that Haml couldn't
> > > > > > >>> determine when it was safe to perserve the literal newlines
> > because
> > > > > it
> > > > > > >>> automatically indents text, but if you used | to reset
> > indentation,
> > > > > it
> > > > > > >>> seems like it would be safer for Haml to do. If that was
> > possible, I
> > > > > > >>> think "%pre|<" would work perfectly for my purposes.
> > > > > > >>> Otherwise, some advice would be very much appreciated! Thanks
> > in
> > > > > > >>> advance,
> > > > > > >>> ~Jonathan Castello
On Sun, Oct 25, 2009 at 3:48 PM, Twisol <solu...@hotmail.com> wrote:
> Pardon my naiveté, but could you give me an example of how to go about
> doing that? I've tried using my homemade unpreserve helper at many
> points along the chain of partials, with no real success.
> On Oct 25, 12:28 pm, Nathan Weizenbaum <nex...@gmail.com> wrote:
> > I guess you'd need unpreserve along with some way of not indenting the
> > partial. Or you could simply run #unpreserve on the finished template
> once
> > it's rendered. In any case, I don't want to add new syntax to Haml for
> what
> > amounts to a relatively minor, purely aesthetic issue.
> > On Sat, Oct 24, 2009 at 5:13 PM, Twisol <solu...@hotmail.com> wrote:
> > > After attempting to write an 'unpreserve' helper (which merely gsub's
> > > HTML-entity newlines into literal newlines), I'm still suffering the
> > > exact same indentation issues. It seems like, currently, there's just
> > > no way to stop indentation -and- preserve literal newlines. :perserve
> > > does the former, and ~ the latter, but I can't for the life of me
> > > produce both effects.
> > > On Oct 24, 2:15 pm, Twisol <solu...@hotmail.com> wrote:
> > > > That's exactly what I'd like to do: make the entire partial
> > > > unindented. I envision a | mark resetting the indentation level for
> > > > the tag it's used on; if there are nested tags, they would still be
> > > > indented, but relative to the reset level. When used with my ERb
> > > > partials, I'm basically saying that I'm taking indentation into my
> own
> > > > hands, which is precisely what I require for my preformatted text.
> > > > I'll look into writing an unpreserve helper, but I still like the
> > > > (perceived) elegance of my | suggestion. Thanks for your time.
> > > > On Oct 24, 1:59 pm, Nathan Weizenbaum <nex...@gmail.com> wrote:
> > > > > Converting the partials to ERB isn't going to help, since (as you
> > > noted) the
> > > > > issue comes from the Haml layout re-indenting the code. I don't see
> how
> > > a
> > > > > syntactic marker could help this, unless you want the entire
> partial to
> > > be
> > > > > un-indented. A better solution would be to make an unpreserve
> helper
> > > that
> > > > > you wrap your partial calls in in the layout that converts newline
> > > entities
> > > > > into actual newlines.
> > > > > On Sat, Oct 24, 2009 at 1:24 PM, Twisol <solu...@hotmail.com>
> wrote:
> > > > > > I've converted the offending preformatted partials back to ERb,
> since
> > > > > > this seems like a good place for it. Now my only issue is the
> > > > > > indentation, because the layout file is still Haml. If the | mark
> I
> > > > > > suggested was added, to reset indentation, it would make it
> easier to
> > > > > > include ERb partials like this, and my problem would be duly
> solved.
> > > > > > On Oct 24, 1:21 pm, Nathan Weizenbaum <nex...@gmail.com> wrote:
> > > > > > > Potentially, yes, but that would dramatically increase the cost
> of
> > > string
> > > > > > > concatenation, which is something we desperately want to avoid,
> > > since
> > > > > > string
> > > > > > > concatenation happens a lot during the rendering of a Haml
> > > template.
> > > > > > > On Sat, Oct 24, 2009 at 1:19 PM, Chris Eppstein <
> > > ch...@eppsteins.net>
> > > > > > wrote:
> > > > > > > > Can't haml have some concept of a pre-formatted bit that gets
> set
> > > and
> > > > > > then
> > > > > > > > is sticky for the rest of the handling of that template? If
> the
> > > bit is
> > > > > > set,
> > > > > > > > haml layouts wouldn't re-indent those strings. This decision
> > > could be
> > > > > > made
> > > > > > > > dynamically and helpers could be made to help manage the
> > > formatting
> > > > > > bit.
> > > > > > > > chris
> > > > > > > > (Implementation suggestion: haml can return an extended
> string
> > > object
> > > > > > for
> > > > > > > > tracking the state of preformatting)
> > > > > > > > On Sat, Oct 24, 2009 at 1:10 PM, Nathan Weizenbaum <
> > > nex...@gmail.com
> > > > > > >wrote:
> > > > > > > >> First of all, filters like :preserve aren't meant for
> handling
> > > > > > > >> dynamically-generated text; they're meant for handling
> literal,
> > > > > > in-template
> > > > > > > >> text with maybe some dynamic stuff sprinkled in. If you're
> > > dynamically
> > > > > > > >> generating text, it's better to use the #preserve helper (or
> ~,
> > > which
> > > > > > is a
> > > > > > > >> shortcut for same).
> > > > > > > >> As for the source code aesthetics, as I mentioned on IRC,
> > > there's
> > > > > > really
> > > > > > > >> no good way to tell when it's possible to not use newline
> > > entities.
> > > > > > > >> Declaring it in the template won't work, because it's *not*
> safe
> > > in
> > > > > > that
> > > > > > > >> template - the template still needs to be included in the
> > > layout,
> > > > > > which will
> > > > > > > >> re-indent it and cause the whitespace to go wrong. The only
> > > potential
> > > > > > > >> solution is to have some way of declaring "this template is
> > > never
> > > > > > going to
> > > > > > > >> be included in another template", something that might be
> added
> > > in the
> > > > > > > >> future.
> > > > > > > >> On Sat, Oct 24, 2009 at 12:47 PM, Twisol <
> solu...@hotmail.com>
> > > wrote:
> > > > > > > >>> Hello,
> > > > > > > >>> So far I really love Haml, but I have an issue with it
> where it
> > > comes
> > > > > > > >>> to preformatted text.I have a fairly large amount of
> > > preformatted
> > > > > > text
> > > > > > > >>> (generated on the fly by a Rails helper) that I'm trying to
> > > include
> > > > > > > >>> into my page. Using the :preserve filter, it /looks/ fine,
> but
> > > in the
> > > > > > > >>> source it's all on one line, word-wrapped to about thirty,
> and
> > > > > > > >>> completely indecipherable.
> > > > > > > >>> I discussed this briefly with Nex3 on IRC, but he had to
> run.
> > > While
> > > > > > > >>> writing this message, though, I did have an idea: would it
> be
> > > > > > possible
> > > > > > > >>> to add another tag prefix, using either a _ (underscore) or
> a |
> > > > > > > >>> (pipe), to tell Haml that the tag's indentation (or at
> least
> > > its
> > > > > > > >>> content) should be reset? Nex3 had mentioned that Haml
> couldn't
> > > > > > > >>> determine when it was safe to perserve the literal newlines
> > > because
> > > > > > it
> > > > > > > >>> automatically indents text, but if you used | to reset
> > > indentation,
> > > > > > it
> > > > > > > >>> seems like it would be safer for Haml to do. If that was
> > > possible, I
> > > > > > > >>> think "%pre|<" would work perfectly for my purposes.
> > > > > > > >>> Otherwise, some advice would be very much appreciated!
> Thanks
> > > in
> > > > > > > >>> advance,
> > > > > > > >>> ~Jonathan Castello
|
