1) Edit a doc in tab A
2) Open same doc in tab B
3) Edit in tab B
4) Edit in tab A
Result: changes in tab A are not saved and there's no notice/indication/error message.
... now bugs aside, why would I want to use a text editor that isn't local?
Even assuming it works fine, what does this get me that $FAVORITE_EDITOR combined with the plethora of other sync methods (dropbox, google drive, onedrive, etc) get me?
I never understood the purpose of markdown editors. Isn't the main selling point that markdown is a human readable plain text format (i.e., vim will do/you don't need preview)?
Especially for GitHub, I don't want to iteratively push commit after commit to README.md just to get the correct syntax for their GitHub-Flavored-Markdown. When editing on GitHub directly, I appreciate the preview to spot mistakes.
However, there are many downsides of using the website for editing (like you can't combine changes to multiple files in a single commit). I prefer using a real editor locally, but using any other Markdown processor might give slightly different results. Therefore I use flavor [1] to filter the Markdown document through the GitHub API for reviewing it locally before pushing.
flavor also includes CSS rules that closely resemble the design of GitHub, so I can view the result in my local browser as it would look on the GitHub website. With pandoc, I only get plain HTML output.
I wrote mup [1] to help with this: it is a markup previewer. It support multiple markup formats and for markdown multiple markdown implementations: pandoc, commonmark, kramdown, python-markdown and also previewing using GitHub API (slow but the most reliable for README.md editing)
It is a semantically readable text document, that is easy to write and understand by humans too. It really shines when you do something with it after you wrote it (e.g. make a html and style it).
I use it as a plain file/folder wiki and to have a future-proof format for the wiki.
It's an experiment and I'm trying to write all my notes in to it.
The problem is the associative/ribosomal nature of information and the quickly missing context.
We'd need to build a brain that gathers and understands context and files in all the cross-connections.
Until google is done with that we are stuck with what's manageable: A hierarchy (folders) with some limited manual cross-links and full-text search.
All running in a local http server. It's synced to my phone via Owncloud. On my phone I edit the plain files with JotterPad and sync with Foldersync.
But I'm not super happy with yellow:
- missing a tree view (I hacked together something but it's ugly)
- special syntax for the title (but you can ignore it mostly)
- special syntax for the wiki stuff
- was difficult find the setting to change to .md file endings (bad/missing documentation)
- requires an index.md in every folder
What is really nice: i can drop a file in to a public version of the wiki and send a pretty link to someone.
The other selling point is that you can use any/every editor you want, as long as it handles text. Sometimes it is helpful to use an editor with a live preview; other times it's preferable to use vim, or an ide.
I get that if you have a lot of tables, images, etc. live preview is useful but I always shake my head when I open up a Github-style README in a text editor -- they're basically unreadable. Why not create an editor that outputs markdown that looks at least somewhat like a human wrote it (wrap lines at 80 columns, put links at the bottom, etc.)
Agreed completely. An editor specialized to create human-readable Markdown would win my heart. Preview functionality is great, but a killer feature would be to make it easy to preserve the theoretical advantage of Markdown.
At first I was a bit puzzled why anyone would need to describe an editor as "secure"... but oh well, it is actually a web application. I can see the need now.
Did you read the article? It's an interesting way of making a rich shareable document that is readable by those you share the link with and not by anyone else, including those who operate the server, or those on the network route to you.
Well, that's the principle, I didn't look closely enough to see if their implementation can be trusted, but it's a fun idea.
This obsession with react/electron/etc for the desktop is ridiculous. The OP acknowledges as much in the title ("secure" - what do you mean, it's a text editor, isn't it? Oh, because they decided to go "all web" for this!).
I don't have any recommendations for Linux, unfortunately.
Then again, the whole point of Markdown is that it's basic plain-text syntax that can be prettified as HTML. Its entire raison d'être is that you _don't_ have to learn (or test) another markup language, but whatever.
In terms of cross-platform development I understand wanting to use browser technologies, but these off-line web-applications always feel so flaky and unintegrated. The Atom editor for example still can't switch languages for the spell-checker at runtime, even though browsers themselves can.
> I don't have any recommendations for Linux, unfortunately.
Vim works just fine for MarkDown, Gedit is not too bad either. The whole point of MarkDown is being readable both as text in an editor and formatted by a renderer.
It's pretty horrible, but it's the future unfortunately.
The web is ubiquitous. Everyone knows it, and so it's much easier to scratch whatever itch you have in a tech you know than a scary one (C!) that you don't; building for situations you understand (your fast piece of expensive apple tech connected to your fast internet) than ones you don't.
When developing in a higher level language like JavaScript you are less prone to buffer overflow code execution vulnerabilities, witch seems to be the most common security hole.
That's a non-point. There's nothing intrinsic about higher level language that prevents security holes. There are plenty of low-level languages that are immune to buffer overflows—Ada, Rust, D† (to an extent), Oberon†, Cyclone....
D and Ada have real and important software written in them, Rust has hype, Oberon is still actively developed, Cyclone influenced new languages (particularly Rust).
This is exactly what they said about Java in the late '90s and early 2000s, but I have never had any trouble avoiding (non-server) software written in Java, and I doubt I'll have any trouble avoiding non-web software written with web technologies, either.
Sometimes you have to do a lot of detective work to know what technology was used to make the software. Web-tech doesn't ask you to "install Java", for example when running the "web app" with Electron or nw.js
MacDown and MarkdownPad Pro are the editors I use on Mac and Windows too. The Pro version of MarkdownPad has nice support for GitHub flavored Markdown, either using the GitHub API or with an offline renderer.
As much as I like MarkdownPad [Pro], it has its own bloat problem. It uses Awesomium [1] for the preview HTML rendering, which can really chew up a lot of memory.
The original version of MarkdownPad used the native Windows WebBrowser control, but the author didn't know the trick that allows that control to render in IE11 mode instead of IE7 mode. I reported it on their forum over a year ago [2] but it still uses Awesomium.
Anyone who needs to use an embedded web browser on Windows should grab the code in that forum thread. Getting the native WebBrowser into IE11 mode instead of the terrible default IE7 mode makes it a useful control. Since you don't need to bundle an entire web browser with your app, it cuts down the app size quite a bit.
> "secure" - what do you mean, it's a text editor, isn't it?
One of its features is that you can easily share your document with someone else across the internet with transparent encryption built in, so that the owner of the server and those on the network route never see the document.
Most other text editors don't have that feature, without combining them with other programs and services. They certainly don't make it as easy to do.
I am currently developing my own Markdown editor and looked into CodeMirror, Draft.js and ProseMirror and I also plan to base it on CodeMirror. I think if all you need is "syntax highlighting" (maybe including font sizes for headlines) you are better off using CodeMirror. Of course, if you want some WYSIWYG functionality Draft.js, ProseMirror and the like may be more suitable (or even mandatory).
If you are interested in a Markdown Editor App for OS X, Linux, and Windows (not browser based), which also support custom themes, and also supports emojis, and also supports GitHub Flavored Markdown and proper GitHub styles, then go star this repository of mine <https://github.com/niftylettuce/seuss.md>. While I appreciate that this was built with React.js, it still does not solve the problem of the need for a better Markdown editor. I'm almost positive Mou still doesn't have GFM support, and MacDown still has 100% CPU issues.
What Markdown standard does this editor use? Commonmark (http://commonmark.org/), Github Flavored Markdown, or something else? Is it possible to specify which standard to use?
67 comments
[ 4.4 ms ] story [ 101 ms ] threadEven assuming it works fine, what does this get me that $FAVORITE_EDITOR combined with the plethora of other sync methods (dropbox, google drive, onedrive, etc) get me?
oijljljh <del><del><del><del><del><del><del><del>
Leaves a character or 2 still rendered.
<a href="javascript:alert('xss')">test</a>
EDIT: removed example page since it wasn't clear to me that access to link means you can edit
However, there are many downsides of using the website for editing (like you can't combine changes to multiple files in a single commit). I prefer using a real editor locally, but using any other Markdown processor might give slightly different results. Therefore I use flavor [1] to filter the Markdown document through the GitHub API for reviewing it locally before pushing.
[1] http://brettterpstra.com/2012/09/16/easy-command-line-github...
[1]: https://github.com/agateau/mup
It is a semantically readable text document, that is easy to write and understand by humans too. It really shines when you do something with it after you wrote it (e.g. make a html and style it).
I use it as a plain file/folder wiki and to have a future-proof format for the wiki.
I've always found wiki's and the like extremely difficult to organize. Lots of knowledge and little things, but it always runs out of hand quick.
The problem is the associative/ribosomal nature of information and the quickly missing context.
We'd need to build a brain that gathers and understands context and files in all the cross-connections. Until google is done with that we are stuck with what's manageable: A hierarchy (folders) with some limited manual cross-links and full-text search.
I'm using the yellow cms, with a wiki plugin:
http://datenstrom.se/yellow/
http://developers.datenstrom.se/edit/plugins/wiki-plugin/
All running in a local http server. It's synced to my phone via Owncloud. On my phone I edit the plain files with JotterPad and sync with Foldersync.
But I'm not super happy with yellow:
- missing a tree view (I hacked together something but it's ugly) - special syntax for the title (but you can ignore it mostly) - special syntax for the wiki stuff - was difficult find the setting to change to .md file endings (bad/missing documentation) - requires an index.md in every folder
What is really nice: i can drop a file in to a public version of the wiki and send a pretty link to someone.
https://www.cvedetails.com/vulnerability-list/vendor_id-8218...
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3075
Well, that's the principle, I didn't look closely enough to see if their implementation can be trusted, but it's a fun idea.
Use MacDown on OS X http://macdown.uranusjr.com and MarkdownPad on Windows http://markdownpad.com
I don't have any recommendations for Linux, unfortunately.
Then again, the whole point of Markdown is that it's basic plain-text syntax that can be prettified as HTML. Its entire raison d'être is that you _don't_ have to learn (or test) another markup language, but whatever.
> I don't have any recommendations for Linux, unfortunately.
Vim works just fine for MarkDown, Gedit is not too bad either. The whole point of MarkDown is being readable both as text in an editor and formatted by a renderer.
The web is ubiquitous. Everyone knows it, and so it's much easier to scratch whatever itch you have in a tech you know than a scary one (C!) that you don't; building for situations you understand (your fast piece of expensive apple tech connected to your fast internet) than ones you don't.
D and Ada have real and important software written in them, Rust has hype, Oberon is still actively developed, Cyclone influenced new languages (particularly Rust).
† Garbage collected by default
For Linux and any other platform. Emacs' markdown-mode (including its GitHub-flavored gfm-mode) works very well.
It's available in ubuntu repos.
As much as I like MarkdownPad [Pro], it has its own bloat problem. It uses Awesomium [1] for the preview HTML rendering, which can really chew up a lot of memory.
The original version of MarkdownPad used the native Windows WebBrowser control, but the author didn't know the trick that allows that control to render in IE11 mode instead of IE7 mode. I reported it on their forum over a year ago [2] but it still uses Awesomium.
Anyone who needs to use an embedded web browser on Windows should grab the code in that forum thread. Getting the native WebBrowser into IE11 mode instead of the terrible default IE7 mode makes it a useful control. Since you don't need to bundle an entire web browser with your app, it cuts down the app size quite a bit.
[1] http://www.awesomium.com/
[2] http://forums.apricitysoftware.com/t/why-is-markdownpad-spaw...
One of its features is that you can easily share your document with someone else across the internet with transparent encryption built in, so that the owner of the server and those on the network route never see the document.
Most other text editors don't have that feature, without combining them with other programs and services. They certainly don't make it as easy to do.
The irony was lost on someone somewhere.
https://github.com/joeyespo/grip
> site doesn't work if javascript is disabled