Mario, Whilst I agree with this,
> wikitext markup should be globally interchangeable I do not think its enforcement should limit the flexibility of an editor in their own wiki. If content is not designed for sharing, or only shared to pre-configured wikis such as personal notes, then it is simply not sharable. The plan should be to have sufficient richness in the markup to support interchangeability, but this comes with time, new facilities and features could be developed by editors for their own use and compelling solutions moved into global wiki markup in the fullness of time. It makes me wonder if we need a kind of "escape character", behind which custom markup can be defined, but ignored if not handled by the recipient wiki. A field and its content could cause such an alternate markup or the type field. Perhaps copy to clipboard, and copy, export could include an option to ignore especially escaped markup. Just some thoughts Tony On Thursday, February 27, 2020 at 11:08:08 PM UTC+11, PMario wrote: > > On Thursday, February 27, 2020 at 12:16:08 PM UTC+1, TonyM wrote: > > Codemirror allows indents/with tabs, but the render does not honor them, >> but here I want no indent, just a paragraph. >> > > I know. ... but I do want a generic solution, that may fit more usecases. > > We could create some (2) buttons that can create tabs without codemirror, > just for indenting paragraphs. > > In my case I already use ":" to indent and make an effective paragraph, >> > > No you create a Description Details element > <https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dd> ... that's > a different thing. ... You are basically "misusing" it, because there is no > visual difference. > > But there is a semantic difference. eg: If you copy paste the html code > into a different app, that tries to make sense out of the html structure, > it will be confused. > > >> multiple indents as well, as you know ";" is bolded but is does what I >> want otherwise, but since I we are dealing with paragraphs it seems best to >> use the html P tag. At one point I removed the bold with ;.p where p was a >> class name that unbolded it. But ;.p is surprisingly distracting. >> > > Yea distraction was the main point why I didn't like the . dot at the > start of the line. ... But you are right. If there are more elements like > ;.p it is even worse. ... > > ;.p looks like an emoji ;p > > I was thinking about the ยด tick, because it's also a small character. ... > I don't know, what's better. > > >> I notice that using period as the second character to ;.classname and >> :.classname works, so theoretically ..classname could also work while >> rendering the text in an un-indented paragraph. >> > > You are right it should work for un-indented paragraphs. If ... means > paragraph level 3, it won't work for ...test paragraph level 2, since the > parser can't recognize the difference between level 2-with-class and level 3 > > >> But I am not wedded to period, however it is nicely easy to access on the >> keyboard (no shift) and it is often so unassuming if it was at the >> beginning of a paragraph (not wikifield) it is almost unnoticeable. >> > > ... keyborad layout and character access is a thing. ... that's right. > > >> One idea is what if we used an invisible character? eg; non breaking >> space, one that is otherwise ignored?, the only question is how do we get a >> single key entry, and ideally display while editing raw text. >> > > I'm not a big fan of invisible "formatting", but for some things, we don't > have a choice. ... The [tab] at the beginning of a line will be visible in > edit mode. ... but it would look the same as if you did 8 spaces. ... But > nobody makes 8 spaces at the start of a line. right ;) > > I did also experiment with a new hard-linebreak inline-parsing-rule. using > <space><space><enter> ... that will be translated to <br/> > > It works nicely, but has very high potential for misuse, which will cause > a lot of maintenance cost (for the users) in the long run. > > I also created .q and .a classes to highlight Questions and their Dnswers >> differently and this also allowed the Questions and answers in a long text >> to be listed in a footer. >> > > ok > > >> With matching I listed unanswered Questions. You can see here, this >> provides an ad hoc way for an author to add annotations, >> > > There is an html element for annotations. <aside>: The Aside element > <https://developer.mozilla.org/en-US/docs/Web/HTML/Element/aside> ,where > the default ARIA role is complementary. > > classification and formatting details to their content as they write, a >> bit like a home grown shorthand, which is what markup is all about. >> > > I'm not sure what you mean with classification. ... but it could be <dt>: > The Description Term element > <https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dt> > > >> I may also add when trying to take notes in a class or watching a video >> the more easy tricks the better. >> > > That's right. .. But it would be nice, if the easy tricks also create > valid html output. > > > >> Regardless if such "customisations" were hackable more can be done. >> Inventions we can't imagine. >> >> - One I can imagine - an indicator to later excise, and transclude or >> Link to that transclusion (needs beginning and end, or default to end of >> line/paragraph) >> >> That's right, but if it is hackable it may cause a lot of incompatibility > between wikitext of user A and user B. I think, the wikitext markup should > be globally interchangeable. > > have fun! > mario > -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/51aa516a-3504-4942-ab25-867a93906933%40googlegroups.com.
