Support for ussing documents as sub-paragraph containers

Hí, I think Scrivener is full of useful features for writer, but at least one critical feature for scientific prose writers is missing: the ability to have documents for units of discourse smaller than paragraphs. All scrivener needs to have for this to be possible, is the ability to joint documents without inserting a line break between them. In this way, every card could be a simple idea (a sentence, perhaps) and rearranging cards would be possible to build a paragraph. And with paragraphs, sections, and so on.
I´m using scrivener, for instance, to write a short scientific paper, and the natural breakdown structure that I use, gives a card (document) for ideas that later will fit together into a single paragraph. Right now I have to join multiple ideas in a simple document (it kills the corkboard purpose) or I have to delete a bunch of unnecessary paragraph breaks after the document is compiled.
Pleeeeease, such a simple request! Imagine a checkmark on every document, next to “page break before” that say “no paragraph break after”.
Not before this small feature gets implemented, will scrivener have its potential maximized as helper of scientific prose writers.
Thanks, in advance.
MB.

Minus the rhetoric about ‘small features’ and Scrivener achieving its potential(!), there is a good idea here. I’d also use this from time to time (perhaps because I’m also an academic). Also it seems that it would be a good fit with the Scrivener philosophy of allowing the writer to break the text down into the most useful units without worrying about the formatting.

I can see at least one problem, though: what would happen to the paragraph formatting of the output if the different blocks in Scrivener are formatted differently, or if the compile settings would make them come out differently? Perhaps just use the para style of the first block?

At first blush, I would suggest not treating sub-paragraphs differently. If a sub-paragraph is formatted differently from its containing paragraph, then perhaps the writer wanted that difference.

This may suggest the need for radio buttons for sub-paragraphs, “do not assume adjacent formatting”, “assume formatting left” and “assume formatting right.” Assuming “paragraph formatting” may not be possible in complicated situations, but it should always be possible to assume formatting to the left or right. If left/right are checked in situations where there is no left or there is no right (at the beginning or end of the paragraph), the sub-paragraph is formatted as is.

And note that left/right would have to obey left-to-right and right-to-left languages correctly. It wouldn’t affect the UI or the user’s view of the text, but the code to produce that formatting would probably have to be aware of the current language’s direction.

Fine for character formatting, but that doesn’t make sense for paragraph formatting. Each paragraph can only have one first line indent, one left margin, one right margin, one setting for left and/or right justification. Otherwise it’s not one paragraph… So if you have a feature that melds together things that are separate paragraphs during compilation, there would have to be a general rule about which paragraph formatting the composite paragraph in the output ends up with.

Maybe using a special character or code at the end of a unit that shall NOT end with a paragraph break in compile?

I would end every sentence with, let’s say, two asterisks, and I would throw the compiled output into a word processor to exchange all ** with a single blank. Voilà – problem solved.

Personally, I don’t see the usefulness of such a feature. I rarely ever use documents as small as one paragraph, and if I’d go smaller … well, I think with a binder one mile long the handling would become too difficult to handle.