should be able to pass empty results to a tag and have it stay on same line.

[cortfritz]

consider:

    - sum = fn (a, b) -> a + b end
    - has_value = sum.(2, 3)
    - is_empty = nil
    p= has_value
    p= is_empty

I would expect

  <p>5</p>
  <p></p>

instead i get

  <p>
    5
  </p>
  <p>

  </p>

...which seems wrong. Is there a mode to turn off the unintended newlines?

[rstacruz]

Hey there, sorry there isn't any! There are newlines going to be inserted; p= xyz will translate to <p><%= "\n" %><%= xyz %><%= "\n" %></p>.

This feature was never planned in Expug, unfortunately.

[cortfritz]

if you point me at the right spot i would attempt a PR

On Jul 26, 2019, at 2:38 AM, Rico Sta. Cruz notifications@github.com wrote:

Hey there, sorry there isn't any! There are newlines going to be inserted; p= xyz will translate to

<%= "\n" %><%= xyz %><%= "\n" %>

.

This feature was never planned in Expug, unfortunately.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[thepeoplesbourgeois]

Oh cool, this issue's still open.

It's disappointing to hear this isn't considered a bug, and won't be fixed being that it was not a planned feature. It implies having to either accept visual artifacts on an expug-rendered page when no data is available for a given variable or function return, or having to incorporate kludgy if statements anywhere there is the potential for data to not be returned to the template.

As an example of what I mean, this is the standard Phoenix Framework templates/layout/app.html rendered after being converted from .eex to .pug

The blue and red boxes are info and error alert boxes, rendering because no text is returned via the get_flash/2 calls inside of those elements. I wasn't able to prevent these from appearing by wrapping the get_flash calls inside of an interpolated string, like I had hoped, nor was I able to make the if statement a one-liner within the p.alert elements. Instead, I had to nest the entire p element inside of an if which checked for the value before rendering its corresponding alert, like so:

main.container(role="main")
  = if get_flash(@conn, :info) do
    p.alert.alert-info(role="alert")= get_flash(@conn, :info)
  = if get_flash(@conn, :error) do
    p.alert.alert-danger(role="alert")= get_flash(@conn, :error)

Simple as this was to do for this one top-level layout template, it is a brittle coding pattern overall, and I can imagine similar visual artifacts ending up on larger websites because of the need to implement the if check on every potential nil or blankish value.

I'm hoping this doesn't become a showstopper in building my app using Expug for my template files. The syntax is refreshingly terse compared to .eex, and I quite like that, but if it winds up necessitating more overhead to ensure a clean interface for my users, I'm likely going to revert to .eex, using Emmet to reduce the number of keystrokes to generate the boilerplate stuff

[thepeoplesbourgeois]

Annnd I reverted to .eex. This remained hilarious until it became sad.

The good news is, I'm sure it'll circle back to hilarious in due time

[cortfritz]

this seems like it wouldn't be an expensive PR. I'm open to submitting one, but I'd like a pointer for which section of code would be the right spot to start.

[thepeoplesbourgeois]

I've just decided to use Slime instead

[rstacruz]

Unfortunately I can't maintain this library anymore. If anyone would like to take over, let me know and I can transfer it.

On Fri, 22 Jan 2021, 12:25 pm thepeoplesbourgeois, notifications@github.com wrote:

I've just decided to use Slime https://github.com/slime-lang/slime instead

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rstacruz/expug/issues/13#issuecomment-765050808, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAASFEMRZMDRMNFCAOJJSKDS3DHYPANCNFSM4GDTDOPQ .