h a l f b a k e r yGetting blown into traffic is never fun.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
Please log in.
Before you can vote, you need to register.
Please log in or create an account.
|
Back in the infocom days, text based games were often
compiled into
byte codes that are run in a virtual machine. This allows
for multiple
machines of different architecture to support an
interactive fiction
as long as it ran the same interpreter.
I wonder if the same approach for promoting
standardized
markdown
could be done with this approach.
Say, write the 'gold standard' markdown in C, and
compile
it into a
distributable file that can be ran via an interpreter in
multiple
different languages like python, javascript, ruby, php,
go,
etc...
The benefit to this approach is that updating the
markdown engine is
just a case of switching the bytecodes.
Virtual machines is more suitable for 'gold standard'
markdown,
compared to other applications because a markdown
program is
essentially an stdin --> stdio (markdown text in --> html
out).
Plus if you want to 'extend markdown' but have it
available
on all
platform, you could just replace the bytecode as well.
Heck
it may not
even have to be markdown, could be asciidoc or
something
else.
Is this a viable approach? And if so, is there an existing
minimal
interpreter that can efficiently deal with textual
processing
with
minimal overhead?
------------
Possible VM candidate for this idea: microperl?
You want a virtual machine with minimal instruction set
for ease of implementation
Perhaps its not purely a virtual machine but exposes
regexs (which is usually processing heavy)
Emscripten is an LLVM to JavaScript compiler.
https://github.com/...ken/emscripten/wiki
Perhaps distributing via LLVM compiled to multiple platform is a better alternative? [mofosyne, Jul 05 2014]
[link]
|
| |
It could be done in java perhaps, but you want the
virtual machine to be implementable in as few lines
of codes. RISC style perhaps? |
|
| |
Otherwise implementing a JVM in javascript to run a
a markdown app does sound pretty massive overkill
and bloated. |
|
| |
"markdown" seems like a pretty nifty idea. |
|
| |
But it doesn't seem complicated enough to require more than a couple lines of code. |
|
| |
Maybe write a Notepad for it, for editing and simple display, and include it in .html renderers in the same manner you'd put a .txt file inline (however that would be accomplished). |
|
| |
That is okay for a single implementation, but when
every coder 'makes their own' implementation...
the
standard starts to diverge, and diverging standards
and quirks are annoying. (e.g. markdown in one
viewer looks different from another viewer). |
|
| |
There is effort at creating a 'markdown' compliance
test suite, which is our first line of defence. |
|
| |
But a common 'engine' will also help solidify the
standard, and encourage code reuse. |
|
| |
The WP article mentions the basics: titles, subtitles, list, numbered list, italic, bold, underlines, etc. I assume it might get as complicated as simple tables. |
|
| |
The point of markdowning seems to be for user convenience: why not make it as such; just have user-defined display parameters. Some people might want text in 14pt, titles in 22 and sub's in 18. Others might be happy with bolded underlined for titles and non-bolded underline for subtitles. |
|
| |
At that point all you'd be arguing about is the default set, for users who aren't advanced enough, or can't be arsed, to personalize it. And, if all the display defaults are different across different programs, so what ? |
|
| |
It's pretty nifty, and you've my vote for including it in <whatever>, but the concept itself limits scope, since the more complex the rendering, the less legible the simple text. For instance, it seems usage of "*" is a bit deprecated as a simple character, also " ' ", which would annoy some people who use the single-quotes, regularly. |
|
| |