Textile Markup Language
textile-lang.com
textile-lang.com
I still use TXP at [1] and others. Back in the day when I didn't know how to code, and yet too much reliance on Joomla and WordPress plugins was often disastrous (one of those small plugin vendors sold customer data to a very specific type of telemarketing firm, as a funny example), TXP tags absolutely saved the day. You could use them to write web apps with CRUD interfaces, with the help of the admin theme being utterly simple to style away using CSS.
You could create a new section within seconds, an instant /whatever endpoint with a blank textarea where you could place any content type or any code you wanted.
For example the smd_xml plugin (thanks Stef) where you could write e.g. <tag query="SQL query here" wraptag="p">{title}</tag> to show a quick list of favorite book titles from the DB or whatever content you wanted really. Combine that with another tag for getting GET and POST variables and voila, a lot was possible without leaving the admin interface.
Toward the end of my business-oriented TXP days, I was running a network of food and drink distribution & marketing websites which spoke to each other on the back end, hosted a sales material database (labels, product shots, PDFs) along with custom PDF creation tools for salespeople which drew on that database. All without learning to do web coding...and when I was ready to code I was _really_ ready because I had already made some minor fixes to plugins, which were editable via the admin panel directly.
(Did I mention that you install plugins by copying and pasting a plain text bundle into the admin? This clipboard install method is pretty amusing and easy on the brain)
To this day I enjoy using TXP. It's very lightweight, it has a learning curve, but it works great for blogging and lots of other things. Textile and Markdown both live comfortably in the same mind and it's nice to be able to work with both.
As far as I can tell, what you actually want is to denote a section and give it a header, and within the section you may want to denote sub sections.
Something like this:
@section {
@title: This is my section title
Text, paragraph, etc.
@section {
@title: Subsection Title
Text, text, text.
}
}But I'm not aware of any markup language that lets you do this.
I prefer not using them and fall back to using <header> elements inside sections, but styling them globally makes it rather difficult and ugly to work with. What's other people's solution to this? Or am I just picky when it comes to semantics?
@section {
@title: This is my section title
Text, paragraph, etc.
@section {
@title: Subsection Title
Text, text, text.
}
More text that belongs to the parent section. But how will the reader know that? Indentation? Blocks with background color maybe?
} title: ships
p: ships travel on water
p: they are like cars but on water
title: motors
p: ships have motors
p: spin around
p: very powerful
p: ships can be used for many things
title: fishing
p: fish are in water, so the incentives are super-aligned @Section[name=quickstart]{@Title{Quickstart}
@P{ The official documentation is very sparse, but as a quickstart here is what you need to do: }
@List{
@Item{Create a fullscreen window to render into}
@Item{Initialize the library with @FuncRef{S3DTK_InitLib}.}
@Item{Create a renderer with @FuncRef{S3DTK_CreateRenderer}.}
@Item{Create an IDirectDraw instance - DirectDraw is mainly used to manage video memory.}
@Item{Setup exclusive and fullscreen cooperative level and set the video mode to 640x480x16bpp or whatever.}
@Item{Obtain the base of the framebuffer (see below) to use for calculating surface offsets.}
@Item{Create a primary surface with a secondary buffer attached to it to act as a swap chain.}
@Item{Create two @TypeRef{TS3DTK_SURFACE} variables to hold info about the surfaces. S3D actually needs very little info about a surface: its size, pixel/texel format and the offset in video memory from the framebuffer. This bit is the trickiest one.}
@Item{Optionally create a 16bit surface to hold a z buffer - again you need to do this via DirectDraw and @TypeRef{TS3DTK_SURFACE}.}
}
@P{ And that is about it. Beyond that it is mainly setting state and drawing triangles. In terms of memory management, S3D relies on DirectDraw to do the video memory allocation/etc so in general the process is allocating a DirectDraw surface and filling a @TypeRef{TS3DTK_SURFACE} variable with info about it. The S3D API itself does not actually know about DirectDraw, it is only used indirectly to obtain the memory offsets and to perform surface flipping. In theory it might be possible to allocate a big surface and chop it to smaller pieces with multiple @TypeRef{TS3DTK_SURFACE}s. }
produces the list at the top of [0]. The main difference in the syntax is that instead of "@title: blah" you type "@title{blah}" because "blah" is just the content for the "title" node and the parser doesn't treat any nodes in a special way, it just creates a tree and then passes it to a script for doing whatever it wants to do (to produce the linked HTML document it is passed to a script that generates HTML in a variety of formats - e.g. single file, multiple files, using HTML5 elements or sticking to "basic" HTML that works in a bunch of primitive viewers, etc).The "Section" node above uses "P" but strictly speaking it isn't necessary as any text after the } will create text nodes for the parent node (in this case the "Section" node). I did it this way mainly for consistency, but a script could just use the node's own text (which is basically what nodes like "FuncRef", "TypeRef", etc are doing).
(i do not have any releases for the processor yet since i'm still -slowly- tweaking it as i -very slowly- write various documents using it)
[0] http://runtimeterror.com/tech/s3dtk/docs/s3dtk_quickstart.ht...
I don't have an opnion on the syntax in particular. The point I was trying to bring up is to have some kind of recursion in the syntax.
Is your document format published somewhere?
Header levels would have been derived from the document structure.
<section>
<h>Hacker News/h>
<section>
<h>Guidelines</h>
</section>
<section>
<h>FAQ</h>
<section>
<h>...</h>
</section>
</section>
</section>Anyone using a screen reader.
The way I see it, Markdown is great for outputting simple text and readily used for that reason in the Wordpress blog space. Once you start needing more complex styling and formatting then i'd go for either Latex or HTML, both feature rich markup languages.
I use markdown for my everyday notes right now, and love it. The syntax is simple, fast to type either on mobile or desktop and pretty easy to read. Looking over the tag based syntax of Textile i'm not sure i'd have as easy a time using it for fast output... and if i'm wanting more style and moving to tags, I might as well use HTML... so what's the use case?
Textile was invented around the same time as Markdown, so it tackled the same problem that Markdown tried to solve, only Markdown got more popular.
> so what's the use case?
Cover most HTML elements and edge cases, something Markdown was never supposed to do.
PS: Let me add more context - The top-linked Textile Markup Language is a documentation website. Textile markup/down is history and FAILED - thus - the next step is what can we learn from the fail - what are the good, bad and ugly parts? what was missing and so on. Now how do you "fix" textile (or markdown)?
For more context let me add / point out the side-by-side samples (texti vs markdown vs latex vs wikipedia markup), see https://github.com/texti/texti.github.io/tree/master/samples using the Wikipedia article on markup as an real-world sample.
I was kind of hoping based on the name it would be for that. That industry is woefully lacking good open source and DIY tools for telling the machines what to sew.
But back on topic: I'm not sure what in this language would encourage me to move off of markdown at this point. It seems nice but the friction to use yet another markdown language (even if this one is older by 2 years it seems) is high.
https://confluence.atlassian.com/doc/confluence-wiki-markup-...
https://breckyunits.com/aftertext.html https://news.ycombinator.com/item?id=29643313
I've tried doing my CV and some presentations in markdown cause I just didn't want to put the time to learn latex. I went markdown -> html -> pdf. I just couldn't get something satisfactory. The pains: pagination, centering, columns, image positioning, colors.
And then I took a day to learn enough latex - https://latex-beamer.com/quick-start/ - to create a presentation for work. It was a lot easier than I thought and it came out looking great. Here is the skeleton of it so you can judge how complex it is:
\documentclass{beamer}
\usepackage{hyperref}
\usetheme {teheme-name}
\title{My Title}
\subtitle{My subtitle}
\author{me@example.com}
\date{\today}
\setlength{\parindent}{4ex}
\setlength{\parskip}{1ex}
\begin{document}
\begin{section}{Title}
\begin{frame}
\titlepage
\end{frame}
\begin{frame}{Contents}
\tableofcontents
\end{frame}
\end{section}\begin{section}{Some section}
\begin{frame}{Page title}
My text here
\begin{itemize}
\item one item
\item another item
\end{itemize}
\end{frame}
\end{section}\end{document}
No one should ever ask themselves "how do I do image positioning" or "how do I add pagination" when dealing with markdown. That's just not what it's good for.
Imagine having to write comments on HN using LaTeX.
Also renderable safely and in bounded time (TeX is turing complete).
> No one should ever ask themselves "how do I do image positioning" or "how do I add pagination" when dealing with markdown. That's just not what it's good for.
Meh. This is a common question for table extensions, and the full-blown image commonmark spec is a bit of a mess.
> Imagine having to write comments on HN using LaTeX.
That would be an improvement over the current state of affairs at least, though probably a tad overdone on the other side of proper complexity.
Plain text paragraphs separated by blank lines is already a subset of LaTeX, so we are already doing that!
than that.[0] https://bookdown.org/yihui/rmarkdown/ [1] https://github.com/TudorAndrei/dotfiles/blob/1b118830315cdcc...
And have you ever tried to write complex tables with Latex? A nightmare!
The best approach to write structured documents in a non-WYSIWYG way is AsciiDoc. You get a clean separation between content with its semantics and styling and you have a all the features you need for the biggest technical or scientific books.
h6. or //h6 Is a lot more readable IMO than ######
I don't love markdown, but I am pleased that it "won" in the sense that I can use it everywhere. There's nothing worse than having to use three+ different markup languages during the course of a day.