Skip to content
New issue

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

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(tech support) how to get line spacing, without line breaking #596

Open
shentino opened this issue Sep 13, 2017 · 5 comments
Open

(tech support) how to get line spacing, without line breaking #596

shentino opened this issue Sep 13, 2017 · 5 comments
Milestone

Comments

@shentino
Copy link

I've become somewhat confused on how vertical spacing works.

Is there a way for me to get both of these results:

  • block level tags at the same indentation level get a blank line between them

(ul)
(li)blah(/li)

(li)blah(/li)

(li)blah(/li)
(/ul)

  • span level tags and leaf-level block tags stay on one line

(p)(span)blah blah blah(/span)(/p)

instead of

(p)(span)blahb lah blah(/span)
(/p)

@geoffmcl
Copy link
Contributor

@shentino thank you for this follow on from #582...

If possible, to show html use, the three back-ticks. It is a github markdown extension - see creating-and-highlighting-code-blocks - try not to use pseudo html coding...

So it seems your request is, if you use --vertical-space yes, you want -

<p><span>blah blah blah</span></p>

instead of

<p><span>blah blah blah</span>
</p>

It would be relatively easy to add code to do this.

The problem is would it be acceptable to all users. This vertical space is in the realem of a pretty print user preference...

So then it is necessary to create a new option, so both vertical space preferences can be supported... so what would be the new options name? type?

In this particular case, I too would prefer that the </p> not be moved to a newline, and in fact tidy-2000, my oldest version, did not. But by tidy-2009 it did, with --vertical-space yes, so tidy has been that way for a long time... Personally, I have gotten used to it!

Look forward to more feedback on this tough preference problem... thanks...

@geoffmcl geoffmcl added this to the 5.5 milestone Sep 16, 2017
@shentino
Copy link
Author

shentino commented Sep 16, 2017

Personally I'd be curious why the behavior changed between 2000 and 2009.

Here's also why the current behavior is weird:

We get these:

<p>blah blah blah</p>

<p>
</p>

But why on earth are these two considered different:

<p><span>blah blah blah</span>
</p>

vs

<p>blah blah<span>black sheep</span>have you any wool</p>

One would think that it would only treat empty elements differently. An element with contents ending in plain text should not be treated differently from an element with contents ending in a tag.

<p><span>blah blah blah</span>
</p>

Should not suddenly turn into this just because you add one letter:

<p><span>blah blah</span>o</p>

@geoffmcl
Copy link
Contributor

@shentino thank you for the added comment, and you now seem to understand the github specific markdown of 3 back-ticks... makes html, and other code formatting quite easy...

I do not know why the change occurred between 2000, more or less the first release of tidy, and 2009, the last cvs release of tidy, and have not tried to track down the specific commit, which may or may not have given some reasoning...

Back prior to 2009, the source was housed in a sourceforge cvs repository, and while I was a contributor back then, it was not until well after the source was moved to this github repository, that I became a full maintainer...

You certainly make quite a compelling, simple case - why should things change just because you add one letter? Does not seem too logical...

As time permits, I will search for a fix... maybe it would be simple... and if found, give it strong consideration... any help appreciated, and further comments of course... thanks...

@shentino
Copy link
Author

shentino commented Sep 17, 2017

Indeed. Took a bit of practice to figure it out.

And now you know why I reported this issue as a bug in the first place. A single letter having that much of an impact is what led me to believe the behavior in question was not intended. And an element whose contents end in a nested tag is not "empty" and is why

<p>
</p>

Should not be treated the same as

<p><span>blah blah blah</span></p>

@geoffmcl
Copy link
Contributor

As it seems this Pretty Print issue is still open moving out the milestone...

@geoffmcl geoffmcl modified the milestones: 5.5, 5.7 Nov 28, 2017
@balthisar balthisar modified the milestones: 5.7, 5.9 Jul 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants