Previous Entry Share Next Entry
Release 0.6.8
querki
jducoeur wrote in querki_project
Hmm. It seems that adding features gets addictive after a while. After debugging yesterday, I found myself jonesing to deal with a problem I've been annoyed about for a long time: the fact that Querki *always* squashes lines together into a paragraph. That is, paragraphs must be separated by blank lines, and all of the lines in the paragraph get run together.

Mind, it does so for fair reasons. That is the way Markdown does things, and it does make for Large Text blocks that are relatively readable, which is the motivation for Markdown's approach. Most of the time, it works fine. But sometimes, you really want a newline to mean newline. This has been particularly driven home by my attempt to transcribe my filksong book into Querki. In a song, lines matter. I've been dealing with that by using <pre> formatting, but I've been very dissatisfied with that answer.

So last night, I implemented rawLines, the first Querki Parser Directive. This basically tells the system to stop squishing the lines together -- indeed, to omit the rendering of "paragraphs" as such entirely -- and instead put a <br /> at the end of each line. That way, the results render more or less as specified, while still allowing you to use all of the usual QText formatting.

These directives happen at the beginning of a line, and begin with an exclamation point. (Note that I am reserving this as namespace, so be cautious about putting a "!" at the beginning of a line.) To turn on rawLines mode for a section:
!+rawLines
Line 1
Line 2
Line 3
!-rawLines
So everything between "!+rawLines" and "!-rawLines" will be rendered one-line-at-a-time, instead of becoming paragraphs. This behaviour stacks -- you can nest these clauses inside each other, and it will behave sensibly. (This is an edge case, but given the way Querki works, it's likely to come up.)

This is by *no* means fully baked, mind -- I don't guarantee that it will work ideally for blocks inside bullet list, or anything like that. I've tested that it does the right thing for simple top-level paragraphs and blank lines after them, which is the primary use case. I'll probably expand the functionality over time, but that code is hairy enough that it's not going to happen soon. (QText is based on a highly-optimized library called Actuarius, which is lovely and fast but not always trivial to understand.)

I encourage you to play with this if it's appropriate in your use cases, and tell me what you find. If it proves useful enough, we'll likely wrap it in its own TextLines Type, or something like that, so that normal users don't need to worry about this syntax.


On the bugfix front:


Bugfix - _bulleted finally works correctly with single-element Lists: Alexx reported this one a fair while ago, and it took a while for me to completely get my hands around it. (It probably wasn't feasible to fix until my big refactoring of the function library a few weeks ago.)

Suffice it to say, because of Querki's fluid concept of Collections, it is a bit tricky to propagate the right collection identity through the stack. This bug arose because the QL processor was forgetting that we had started with a List Property -- since there was only a single resulting element, it was rendering that as ExactlyOne.

I've fixed this in both a semi-general way, as well as a tweak specific to Text Properties (which are their own ball of Special), and it seems to work correctly in the simple cases now. Please let me know if you find other places where a List of one element behaves differently from one of many elements -- they are probably other manifestations of the same conceptual problem.


Bugfix -- Lists of Primitives work correctly again: during testing, I discovered that Lists of primitives (say, a List of Text) got broken in the live Editor, probably during the enhancements to make Model Values work. These should now work correctly again.


Bugfix -- rendering of Tag Sets in Lists of Model Values: this was a weirdy found by mindways: if you had a Tag Set Property on a Model Type, and created a List Property from that Model Type, and edited it in the bulk Editor, the font of the tags came out about twice the correct size. (I actually had difficulty believing this one until I built a repro environment and saw it for myself.)

This was basically just a dumb CSS bug. The CSS for rendering list items (which is *very* old) was being applied to *all* list items -- and the tags in a Tag Set are technically list items. So Tag Sets under a List were getting mucked up. This is now fixed -- the List CSS is being a little more careful about which elements it applies to. (The sooner I can get Querki to profitability, and I can hire somebody else to deal with CSS for me, the better. It is *not* one of my core skills.)

Along the way, I also fixed a problem where, if you had a Tag Set under a List like that, and you added a new element to the List, the Tag Set would show up as uneditable until you refreshed the page. This is fixed, but please tell me if you come across any other examples of List content that doesn't work when you first add it.
Tags:

?

Log in

No account? Create an account