textile / php-textile

Textile markup language parser for PHP
https://textile-lang.com
Other
214 stars 44 forks source link

Option to allow blank lines in regular un/ordered list items #195

Open wion opened 4 years ago

wion commented 4 years ago

Is your feature request related to a problem?

Not a problem. More like a usability convenience.

What is the feature?

I tend to work on a lot of nonfiction long-form content, and use a lot of notes and bibliography lists in relation. When using Textile for notes, blank lines are allowed/necessary between items and this is nice because if/when notes are long. For example:

notelist:†.

note#ye. ‘pseudo-archaic term for “the”: Ye Olde Cock Tavern . . . in late Middle English ϸ [thorn] came to be written identically with y, so that the could be written ye. This spelling (usually yᵉ) was kept as a convenient abbreviation in handwriting down to the 19th century, and in printers’ types during the 15th and 16th centuries, but it was never pronounced as “ye”.’

note#hjcomp. ‘Honorable John Company’ is this book’s reference to the British East India Company that emerged in 1600, also called Honourable East India Company or John Company, as just two alternatives, thus the derivative name used in the title. The Company’s exploitation of India’s resources would lead to its colonization, making a lot of white men rich and powerful. I use the reference here with endearment to those unscrupulous capitalists exploiting the rest of us on the web. (A fascinating book in its own right. Perhaps a subject for another day.)

etc

You can imagine how much more difficult it would be to find and edit notelist items in the Textpattern editor (which doesn't highlight code like here) if they required no blank lines as regular lists do.

The problem comes with creating bibliographies, however, which do use regular lists, thus require no blank lines between items. When you have bibliographies of 20 or more items, even less, it just looks like a big wall of text and is initially cumbersome to scan through and edit. If we could allow blank lines in regular lists somehow the scanning and editing would be a lot simplified.

Specifically I mean make lists work so blank lines could be used or not per a given list. Obviously there are many cases where having no blank lines would be more desirable.

Don't know if it's possible, but since notes work that way, thought I'd toss it in there.

wion commented 4 years ago

Btw, I've been choosing to use notes only up to now and combine full biblio graphic references with any note comment per notes item, for example, but I'm finding there are times when you need both notes and biblio lists.

For example, when you use a lot of research for background info, but only cite a portion of it. Notes will reflect the portion while the bulk of research will be accounted in the biblio. This is standard in a notes/biblio referencing system.

Another example I'm finding suited to having both lists is using biblios for media file sources (images, videos, etc) as a better way of being able to shorten the 'source' info in captions when attributing, due to copyrights, CC licenses, etc. Keeps the captions much lighter!

wion commented 4 years ago

I guess the first thing to ask is whether it's really necessary to use a list on a bibliography at all. Not needing to would make this moot for me since paras would be fine on biblios. But after 2 decades of working with HTML, I'm inclined to think it is necessary for semantic reasons. The Oxford Style Manual says a bibliography is 'normally ordered alphabetically'... The key word there being ordered, suggesting a numbered list, though unlike with notes, the biblio's numbering is rarely ever shown.

Bloke commented 4 years ago

If I've understood correctly, the only neat way I can think to implement this is by using the 'double dot' syntax like we do to allow line breaks in bq and bc etc. So:

*(some-class)..
* Really long ref 1 Lorem ipsum dolor sit amet, consectetur adipiscing elit.
Sed laoreet nisi nisi, id suscipit tortor sollicitudin quis. Suspendisse potenti.
Fusce tincidunt ligula sit amet metus pellentesque posuere.

* Really long ref 2 Lorem ipsum dolor sit amet, consectetur adipiscing elit.
Sed laoreet nisi nisi, id suscipit tortor sollicitudin quis. Suspendisse potenti.
Fusce tincidunt ligula sit amet metus pellentesque posuere.

* Ref 3
* Short Ref 4

* Really long ref 5 Lorem ipsum dolor sit amet, consectetur adipiscing elit.
Sed laoreet nisi nisi, id suscipit tortor sollicitudin quis. Suspendisse potenti.
Fusce tincidunt ligula sit amet metus pellentesque posuere.

p. And then drop back to regular mode using the `p.` as normal.

Would that be doable? Same with numbered lists.

wion commented 4 years ago

If that’s possible, it would work nicely.

In the case of a biblio, always the last section, the closing p. might not be an issue anyway. I don’t know if that would otherwise break markup leaving a p. off in that particular case, but I could always fake it with an unseen (cleverly colored) point, eg p(bgcolor). ., or whatever.

runeimp commented 4 years ago

This sounds like a great place to use CSS from what I'm reading. Just have a class with something along the lines of:

ul.some-class li + li {
    margin-top: 1em;
}
wion commented 4 years ago

Yes, the presentation is easy, as my example given earlier (second post) might suggest. What I’m referring to here, and admittedly wasn’t clear about, is spacing used in the editor of Textpattern.

And I realize as I type this now, this request might be problematic in that php Textile may not be used only for Textpattern.

I am increasingly drafting in Scrivner first these days anyway, so I suppose it’s my own labour regardless.

Bloke commented 4 years ago

The trailing p. is only necessary if you want to carry on writing afterwards. If it's for a biblio then typically you wouldn't use that, as it'd be last thing in the article. I was just including it for completeness to demonstrate mid-page usage.

wion commented 4 years ago

Bloke, thanks for the clarification. Seems like a good situation no matter how you slice it.