Ladies[1] and gentlemen of /prog/, on this historical day, I hereby pronounce BBCode failures to be abolished, for from this day onward, EXPERT PROGRAMMER and /g/roksi alike will be able to adorn their posts with the most civilized of markup languages Sexpcode!.
>>3
Can you post a sample that trips it up? The delimiter is arbitrary, for what it's worth, you just have to start a sequence of characters with a non-alphanumeric, non-wihtespace leading character and it'll be used as a delimiter.
>>7
Yeah, whatev, I never quite got the Xarn cult of personality, which is ancient history anyway. Well, I wanted to buio with ease, which is what this is most useful for, and substitute my own self-approval for that which my father will never give me I wanted to try my hand at Clojurescript.
>>10
Eh, I can upload the actual source code somewhere later tomorrow, that was only Clojurescript's compiler horrid ``optimized'' output. The implementation is quite neat, and I had reusing the parser to build a toy BBS in the future, as it's pretty much plug 'n' play.
>>12
Hmmm... it's a little short of 400 lines, spread over multiple files, and you need the project structure anyway to compile it, so I'd have to upload it either zipped or in a repo anyway.
>>13
Do you, people, need free anonymous fossil repositories? I read that some anon was willing to offer this. I could provide it too, I have unused servers. but their ToS don't allow me to run an onion site.
The I made email account I used for userscripts just for this, so I can sign up to bitbucket or whatever for this with it. That's enough anonymity, it's just a BBCode generator, people, I won't get the secret police on my tail for this.
tag-name = alpha+
tag = verbatim-tag
| (tag-name (whitespace* "{" text "}")+)
`verbatim-tag' is defined as follows: let `delimiter' be a string not containing the character " " such that the concatenation of " ", `delimiter' and "}" is not a substring of `contents'. Then a valid `verbatim-tag' evaluating to `contents' is
\frac, \root, and \braces
While \array can be clumsily used to implement these, it is better to have dedicated tags for them in order to signal intent. A command-line viewer could render \frac{a}{b} as (a)/(b), for example.
\size
It is needed for things like large summation symbols.
\indices
\sup and \sub cannot be used simultaneously.
\abovebelow
This is needed for cases when subscripts and superscripts should be placed above and below a symbol, e.g. TeX code "\displaystyle{\sum_{i=1}^n}".
SPECIFICATIONS
For the scope of this specification, the special verbatim tag `v' shall not be considered a tag, and will instead be viewed as its contents, as text. The reason behind this is because the verbatim tag is merely a convenient way of escaping large blocks of text, and does not have any semantic meaning.
Passing the specified number of arguments is MANDATORY unless specified otherwise.
\q {quoted-text}
`quoted-text' SHOULD be rendered slightly indented.
\url {link} {content}
`content' SHOULD be rendered as a hyperlink towards `link'. `link' MUST NOT contain any tags.
\code {language} {source}
`source' SHOULD be rendered with the appropriate syntax colouring for `language'. `language' and `source' MUST NOT contain any tags.
\attachment {name} {mime-type} {gzipped-base64-data}
`gzipped-base64-data' SHOULD be made available through user action, and be automatically decompressed; it MUST be gzip-compressed (RFC 1952) using the DEFLATE method. `gzipped-base64-data' MUST NOT contain any non-base64 characters or tags, except for whitespace which MUST be ignored. `mime-type' MUST be the MIME type of the uncompressed data. `name' MUST be a suggested filename for the data; as such, it must NOT contain the backslash or forward slash characters. The attachment SHOULD be rendered as a hyperlink including the `name' and `mime-type' information. An estimate of the uncompressed data size MAY also be included.
\c {colour} {content}
`colour' MUST be three hexadecimal digits corresponding to red, green and blue, representing the colour with which `content' should be rendered. If multiple \c tags are nested, then the innermost takes precedence.
\frac {numerator} {denominator}
`numerator' and `denominator' SHOULD be rendered as a fraction, i.e. `numerator' should be rendered atop of `denominator' with a horizontal bar between them.
\root {radix} {content}
`radix' and `content' SHOULD be rendered as a root. See figure 1.
----------------
`radix'/ \
/ `content'
\/
Figure 1: the \root tag
\size {font-size} {content}
`font-size' MUST be a positive integer. `content' SHOULD be rendered using a font size of `(* (/ font-size 10) current-size)' where `current-size' is the current size. A renderer MAY limit the maximum size obtainable in this manner.
\indices {content} {r-sup} {r-sub} ({l-sup} {l-sub})?
`content' SHOULD be rendered with `r-sup', `r-sub', `l-sup', and `r-sub' as indices (see figure 2). If the `l-sup' and `l-sub' tags are ommitted, their values are taken to be the empty string.
PART 2/3
\abovebelow {content} {above-content} {below-content}
`above-content' SHOULD be rendered above `content' and `below-content' below `content' (see figure 3).
\braces {brace-info} ({content} {brace-info})*
`brace-info' MUST be the concatenation of `brace-type' and `brace-height'. `brace-type' MUST be one of the following characters: "()[]{}<>|d" (where "{" and "}" were properly escaped). While the others are self-explanatory, the "d" case in `brace-type' SHOULD be rendered as a double vertical bar (e.g. as in the usual notation for vector norm), and "<" and ">" SHOULD be rendered as angle brackets. `brace-height' MUST be one of the following:
If `brace-height' is an empty string, then the height of the rendered brace SHOULD be `content-bbox-height', that is, the height of the bounding box encompassing all `content's.
If `brace-height' is a positive integer, then the height of the rendered brace SHOULD be `(* (/ brace-height 10) current-line-height)'.
If `brace-height' is the character "+" followed by a positive integer `x', then the height of the rendered brace SHOULD be `(+ content-bbox-height (* (/ x 10) current-line-height))'.
\spoilernote {content} {explanation}
`content' SHOULD be rendered in a particular way to mark this tag (e.g. using a different background colour). The `explanation' SHOULD NOT be visible until the user takes explicit action to interact with the `content' (e.g. click on it). The explanation MUST then be easy to hide by user action (e.g. by clicking again).
Name:
3/32013-08-23 7:12
PART 3/3
\array {array-info} {cell}+
It is simpler in this case to give the formal grammar:
sectionspec = "|" | "d" | ":" | " "
repetition = positive-integer
borderspec = repetition (sectionspec repetition?)* | (sectionspec repetition?)+
noinherit = "*"
alignment = (h-align v-align? | v-align h-align?)
h-align = "l" | "c" | "r"
v-align = "t" | "m" | "b"
array-info = borderspec "," borderspec
cell-info = alignment ("," borderspec? ("," borderspec?)?)? noinherit?
cell = cell-info ";" cell-content
`borderspec' defines both how long (in columns or rows) a border is and how each column-long or row-long section SHOULD be rendered: "|" means solid line, "d" means two parallel solid lines, ":" means dashed line, and " " means no line. If `repetition' is present, then the `sectionspec' preceding it SHALL be interpreted as having been repeated `repetition' times; if `repetition' is present but there is no preceding `sectionspec', then this SHALL be interpreted as " " repeated `repetition' times.
For both `array-info' and `cell-info', the first `borderspec' refers to horizontal borders, and the second `borderspec' refers to vertical borders. We shall refer to these as `h-borderspec' and `v-borderspec'.
For a cell, the `h-borderspec' and `v-borderspec' define its bottom and right borders respectively (and in particular, their lengths).
The position at which the next cell shall be placed (or, more precisely, the leftmost topmost position it will span) MUST be the lowest (y,x) coordinate (in lexicographic order) that is not spanned by any cell, where `x' is column number and `y' is row number. The cells MUST form a partition over the set of valid array coordinates.
For the array, the `h-borderspec' and `v-borderspec' in `array-info' define its top and left borders respectively.
For a cell, if `borderspec' (vertical or horizontal) is empty or absent, then its `borderspec' SHALL be the first `sectionspec' of the corresponding `borderspec' of the last specified cell that was not marked `noinherit'. If no such cell exists, then `borderspec' SHALL be the first `sectionspec' of the corresponding `borderspec' of `array-info'.
The `alignment' specifies how `cell-content' is aligned within the cell. "l" means left, "c" means centre, "r" means right, "t" means top, "m" means middle, and "b" means bottom.
If `h-align' or `v-align' is unspecified for a cell, then the cell MUST inherit the corresponding alignment from the last specified cell that was not marked `noinherit'. If there is no such cell, then "c" (if `h-align') or "m" (if `v-align') SHALL be used instead.
`cell-content' SHOULD NOT word wrap, and the array's rows and columns should enlarge to fit all `cell-content's.
\table {table-info} {column-widths} {cell}+
Everything is exactly the same as \array (with `table-info' playing the role of `array-info'), with the difference that `cell-content' now word wraps, and that the extra argument `column-widths' MUST contain a comma-separated list of `column-width'. This list MUST NOT have more elements than the table has columns, but may have less. `column-width' must either be the empty string or a positive integer followed by "%". If `column-width' is an empty string or is not stated, the renderer is free to decide the corresponding column's width. If `column-width' is a positive integer followed by "%", then the corresponding column SHOULD have width `(* (/ column-width 100) table-width)'.
>>14,16
Can't you run a freenet or Gnunet fossil repository? I would love to read the TOS⸮
>>25-27
*facepalm* And this is more efficient to shit4chan users how? >>28
Also, space it per minute.
Name:
!TBBT3YPfHA2013-08-23 8:51
>>29
Did you miss the part where I said that the script I uploaded isn't the actual source code for userscript, and that you need project's structure to build it? It's not much, but it has folders and shit. Anyway, maybe later tonight.
>>30
My apologies. I thought the script does all the work, not fetch something externally to be operational. How does a .tar.xz base64 compress to (so you can post it here)?
Name:
Anonymous2013-08-23 9:38
>>29
It's not meant to be used on Shiichan, AFAIK.
Name:
Anonymous2013-08-23 10:35
>>32
Don't worry. You are correct in that the userscript does all the work, not making any external requests whatsoever, nor requiring another script to work, but what I meant is that it isn't the source code in the sense that it's not the "preferred form of the work for making modifications to it", as the GPL would put it.
The program is actually written in Clojurescript. The script I uploaded is just the slightly-modified output Clojurescript's compiler.
Name:
Anonymous2013-08-25 13:02
>>32
Alright then, here it comes, as a base64-encoded .tar.gz: