Repository navigation
Expand file tree
/
Copy pathexample.bbt
More file actions
executable file
·209 lines (161 loc) · 6.48 KB
/
Copy pathexample.bbt
File metadata and controls
executable file
·209 lines (161 loc) · 6.48 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
[h1]BBCode Sample Document[/h1]
This is an example of what a fully featured BBCode document may look like. This document should contain examples of everything that our compiler and exporters should be capable of dealing with and is the basis of any unit tests that assure that no regressions have cropped up in our project.
[h2]Text Styling[/h2]
This is an example of styled text that should be [b]bold[/b], [i]italicized[/i], [u]underlined[/u], and [s]strikethrough[/s]. Although these are simple styling options, they are most of what is usually used in regular text, but we also support colored text, such as [color=red]red[/color] or [color=#FF00FF]fuchsia[/color].
[h2]Headings[/h2]
We've already been using these, but we have the ability to support 6 levels of text headings. This value has been choosen to line up HTML's heading levels.
[h3]Heading 3[/h3]
[h4]Heading 4[/h4]
[h5]Heading 5[/h5]
[h6]Heading 6[/h6]
[h2]Links[/h2]
Links are very simple things, but are the basis of most texts online, thus it's extremely important to support them. An example of a link is this: [url=http://nathancampos.me]Nathan Campos[/url].
[h2]Images[/h2]
I has been said that an image is worth a thousand words, thus supporting images is extremely important.
Accessibility is extremely important these days and images are known to not be accessible, thus our compiler only accepts image tags with alt text, such as this:
[img=https://nathancampos.me/assets/images/http-status/404.jpg]A funny 404 image with cats[/img]
[h2]Quotes[/h2]
Quoting other people is great and gives attribution to the rightful authors of texts, thus this can be done anonymously:
[quote]This is a quote made by someone somewhere.[/quote]
Or it can be attributed an author, such as Nathan Campos:
[quote=Nathan Campos]I'm sure this is not the weirdest setup for a website on the internet. Surely someone has something even weirder floating around with a public IP, but my website is definitely up there with the weirdos, just as I like it.[/quote]
[h2]Code and Preformatted Sections[/h2]
Everyone loves to publish source code on the internet!
[code=cpp]#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <limits.h>
#include "utils.h"
#include "atom.h"
/* Private functions. */
void print_tag(const atom_t *atom, int close);
void print_tag_arg(const atom_t *tag, const atom_t *arg);
void print_tag_group(const atom_group_t *atoms);
/**
* Application's main entry point.
*
* @param argc Number of command line arguments passed.
* @param argv Array of command line arguments.
*
* @return Return code.
*/
int main(int argc, char **argv) {
char line[LINE_MAX];
atom_group_t *atomsgrp;
atom_t *atom;
int ret;
/* Initialize variables. */
ret = 0;
atom = NULL;
atomsgrp = NULL;
/* Go through input line-by-line. */
while (fgets(line, sizeof(line), stdin)) {
char *buf;
/* Removing newline from the end of the string. */
buf = line + strlen(line) - 1;
if (*buf == '\n')
*buf = '\0';
/* Allocate a new atom if needed. */
if (atom == NULL)
atom = atom_new(-1);
/* Are we parsing a new atom or continuing from a previous one? */
if (ret == 0) {
/* Parse atom from line. */
ret = atom_parse_line(atom, line);
} else {
/* Do we need to keep parsing the last line? */
ret = atom_parse_continue(atom, line);
}
/* Should we stop everything or continue parsing? */
if (ret == -1) {
break;
} else if (ret >= 1) {
continue;
}
/* Deal with tags that may span more than a single atom. */
switch (atom->type) {
case ATOM_TAG_OPEN:
if (!atom_args_maybe(atom))
goto handle_atom;
atomsgrp = atom_group_new();
atom_group_append(atomsgrp, atom);
atom = NULL;
break;
case ATOM_TAG_ARG:
if (atomsgrp == NULL) {
fprintf(stderr, "error: atom argument found without group\n");
goto finish;
}
atom_group_append(atomsgrp, atom);
atom = NULL;
break;
handle_atom:
default:
/* Handle previous atom group first if one exists. */
if (atomsgrp) {
print_tag_group(atomsgrp);
atom_group_free(atomsgrp);
atomsgrp = NULL;
}
print_tag(atom, 1);
atom_free(atom);
atom = NULL;
break;
}
}
finish:
/* Free resources. */
atom_group_free(atomsgrp);
atomsgrp = NULL;
atom_free(atom);
atom = NULL;
return ret;
}[/code]
We can also have preformatted sections, whenever we want a piece of text to be monospaced and have all of its textual properties preserved, such as the case when we want to print out some ASCII art:
[pre] _ _ _ _ ____
| \ | | __ _| |_| |__ __ _ _ __ / ___|__ _ _ __ ___ _ __ ___ ___
| \| |/ _` | __| '_ \ / _` | '_ \ | | / _` | '_ ` _ \| '_ \ / _ \/ __|
| |\ | (_| | |_| | | | (_| | | | | | |__| (_| | | | | | | |_) | (_) \__ \
|_| \_|\__,_|\__|_| |_|\__,_|_| |_| \____\__,_|_| |_| |_| .__/ \___/|___/
|_|[/pre]
[h2]Lists[/h2]
Lists are great! We use them every time. Usually lists are unordered, such as this one:
[list]
[*]Windows
[*]Linux
[*]Mac OS X
[*]*BSD
[*]Plan 9
[/list]
But sometimes we need to be very specific about the order of our items, especially when dealing with steps, such as the following list:
[olist]
[*]First do this
[*]Second [b]thing[/b] to do should be this
[*]We can also have [url=gopher://nathancampos.me/]links here[/url] without issues
[*]It's also important to have a [i]complex[/i] and long list item to test for proper text wrapping in [url=https://en.wikipedia.org/wiki/BBCode]BBCode documents[/url] such as this, proving that they will properly wrap to 80 characters.
[*]You should be done by now
[/olist]
[h2]Tables[/h2]
Some information is very complex and can only be laid out using a table, thus we should also support this type of output, even when it's complex and difficult to do so.
[table]
[tr]
[th]Header 1[/th]
[th]Header 2[/th]
[/tr]
[tr]
[td]table cell 1,1[/td]
[td]table cell 1,2[/td]
[/tr]
[tr]
[td]A cell can have [b]bold[/b] text[/td]
[td]Maybe a [url=https://innoveworkshop.com/]link[/url] too?[/td]
[/tr]
[tr]
[td]table cell 3,1[/td]
[td]table cell 3,2[/td]
[/tr]
[/table]
[h2]Lexer and Parser Test[/h2]
Lastly, but certainly not least, here is a simple test for the lexer and parser to ensure that we don't have any quirks in them and that they can deal with any weird input.
This is something/somewhere, and 2+2=4. Also [[]this should be inside brackets] and [[]this=is clearly not a tag argument.
If this entire document was able to be compiled, we have a working compiler!