I am not very satisfied about current Markdown editors or note-taking apps. Most Markdown editors use side-by-side live preview to minimize the gap between the edit and read of Markdown. People usually think of "live preview" when it comes to Markdown, which is really a MISUNDERSTANDING about Markdown.
So I want to develop a note-taking app with pleasant Markdown experience, which try to minimize the gap of Markdown by carefully-tuned syntax highlights and in-place image preview.
Give VNote a try and you will be surprised by the simple and pleasant experience VNote provides. :)
I also develop a note-taking app [0] and so far I've chosen the side-by-side live preview approach, but it's interesting you're trying to make it work with only the editor.
I'm wondering how would you go about keeping notes with many links readable? For example, in this note imported from Wikipedia [1] the left side is hard to read while the right side doesn't have this problem. Some users have also been importing entire web pages, which are a mess of tables and links. They render fine in HTML but are not readable in Markdown.
I think link in edit mode is OK. I used the conceal feature in Vim to hide the URL part of the link when I used Vim to edit Markdown before. But I found that it distracted me when I moved the cursor above the link, the URL part showed, and when I moved the cursor away, the URL part hid. I think it is better to show all the text to the user and use syntax to highlight the outline of the content.
About side-by-side live preview, I hate the feeling of moving eyes left and right frequently and try hard to keep track of where you are.
> If I had a penny for every notetaking app, I'd invest that money in another notetaking app.
I commented about that a few days ago:
> It's funny. Every week there is a new note-taking app being shown in HN. (and the usual guy raving about org.mode :) )
> Many of them are similar but not equal. It really shows that there is a need for these apps but the problems they are thought to solve are unique from person to person.
> I know this because I'm starting to build my own note-taking app.
I'm very happy it's not written in {insert technology unpopular among hackers to gather points}.
Nowhere is Electron mentioned and still comes the hate. A close friend of mine (not a web-developer, unlike me) has a very popular app (>10K users) which uses Electron and he got only around 30 performance complaints last year and all of them could be solved without rewriting the damn thing. The app has a giant "Feedback" button in the main view and there are at least 10 bug reports / suggestions per day (I manage the support desk).
This is getting to the levels of this silly Java hate because everyone thought the performance of Eclipse from years ago still is the state-of-the-art for Java development. There are many bad electron-based apps, that is for sure and completely normal because the barrier to entry is so low. Yeah and there is Slack, but don't complain if you gave up IRC for that incompatible piece of... Whatever.
So I just opened my note which has 100 000 characters. VNote uses 400MB of RAM. Hackmd.io tab in Chrome (and chrome itself) uses just 70MB more. Not big of a difference if you ask me. Also because hackmd supports graphviz so that might be the reason of higher memory usage in Chrome.
Yes, I hate using Electron apps too, although it is easier to write beautiful interface using Electron than using Qt.
I previously use [CMD Markdown](https://www.zybuluo.com/mdeditor) to edit notes, which is developed in Electron. It is really painful to alternate between multiple note tabs in it.
VNote is faster though it combines C++ and JS via QWebEngineView.
How is that different to any other advancements we've made? C is slower than assembly. Python is slower than C. Programmers will continually pick higher level programming languages since it's easier.
I keep on seeing people complaining about Electron here, but it's brought about an age of hundreds of thousands of applications that have compatibility across OS' to do very specific tasks.
I just feel that the ~80MB memory usage and large file size (30-60MB) is inconsequential in modern computing.
Atom doesn't use 80MB, it uses 800MB. On the other side, my Eclipse installation uses ~1100MB and runs whole array of analyzers and background stuff that an IDE should run. Atom runs nothing at the back or provides the same functionality while using 800MB. Also, Eclipse is portable around all major operating systems.
Resource usage can be justified if the that resources is used toward something meaningful. C is "slower" than assembly, yes; however both assembly can be inlined into C, and magnitudes more can be done with C at near-assembly speeds.
I develop in C/C++/Python mainly and in some other languages for fun and curiosity. Python is easy, but it's not as performant unless the underlying library is native, hence nobody is using it if it can't obtain very high performance in my field (scientific computing, HPC, and related areas).
Actually, writing a low performance GUI is pretty hard since most of its cycles are idle. If you can write an application with a GUI which slow to respond to low-complexity, common tasks (naive text editing, input, menus, moving windows), something is very, very wrong (to be clear, GUI can trigger resource intensive background tasks, but that's not what I'm saying).
This is an over exaggeration, and quite a large one. Facebook just released information on the average memory usage of "nuclide" (their Atom editor bundled with a metric ton of plugins which use quite a lot of memory) to be around 600mb. And that's not indicative of a "normal" Atom user (if there can be such a thing).
I personally have currently 5 windows open in atom, with about a combined 40 tabs, and about 30 plugins installed, and my instance is using 360mb of memory right now across all processes. And those windows have been open for about a week now.
And that Atom instance is running a lot of what your Eclipse instance is running. Linters, autocomplete, code analysis tools, CI server integration, a webserver for serving up my application in the editor, a debugger that links the live preview in the editor with the code in the editor, and a ton more.
Switching to something which uses a few hundred less MB of RAM for a fraction of the capability would be a monumentally stupid thing to do, as Atom makes me significantly more productive than any other editor I've tried has ever before.
There are a lot of problems with Electron, but memory usage isn't one of them any more. It can be, just like with any language/platform, but it's not "inherent" to the technology.
First of all, for the 800MB thing, there's the source: https://medium.com/@caspervonb/why-i-still-use-vim-67afd76b4... and I've also seen this behavior while editing small Python files. I also had no other plugins other than the default bundle. So my atom installation was pretty lean.
It looks like you're a web developer, I'm not. I develop at the system level, and for development scenarios Atom is nowhere capable as Eclipse, and seriously that's OK. Every IDE has its niche. I used atom as a pretty text and script editor for my needs, but its auto complete capabilities left too much to be desired for me.
Honestly, maybe atom was not optimized for better memory usage before. Maybe there were memory leaks. Maybe my build was buggy (I used an official deb package BTW), or maybe he tested a buggy version, but these problems were (or are) real for some other people, and they may have been solved or not; but I'm neither the only, nor the last people who talked about excessive memory usage of atom.
I loved atom when it first came out. I tried to migrate to it, but it has burned me with its radioactivity. So I returned to my dark corner under Eclipse to work and recover.
>and I've also seen this behavior while editing small Python files. I also had no other plugins other than the default bundle. So my atom installation was pretty lean.
Atom has made significant strides in the last year reducing that overhead, but the 800 mb from that article was a bug, and was if i recall fixed in the very next version, reducing the total memory usage from opening that large xml file to basically nothing. Even your article shows that it started with a ~250mb memory usage, but the article didn't go into detail about what happens when you open a ton of files (the memory usage only increases a small amount with each file). The overhead is large, but it's fairly static. And judging a program by it's baseline memory usage when using it for it's most trivial tasks seems silly. It's like complaining that your OS takes a minute to boot up just to edit a text file, when VIM can start up in a hundred milliseconds!
>I develop at the system level, and for development scenarios Atom is nowhere capable as Eclipse, and seriously that's OK.
I completely agree! I just hate when there are perfectly valid problems and issues with a technology, but people ignore them and jump on the bandwagon of a non-problem.
Just like how there was a time when Emacs was a laughing stock for being so resource intensive, things improve, bugs are fixed, programs are optimized, and hardware gets more capable. Judging programs by what they once were is an easy trap to fall into, but it's not helpful for anyone.
> I just hate when there are perfectly valid problems and issues with a technology, but people ignore them and jump on the bandwagon of a non-problem.
Same for me. I didn't intend to 'bash' atom and electron. I just wanted to point some problems with it. If my style sounded like bashing, I'm sorry, it was unintended.
> Atom has made significant strides in the last year...
Honestly, I may give it another shot, as a semi-IDE rather than a complete replacement to my Eclipse setup. I love to explore new applications and see what they do right and where they lack.
I may have jumped the gun here myself, I tend to get a little overzealous and read into comments too much when it comes to web tech (so often people just outright lie or just repeat what they read online and never actually look into it).
>I may give it another shot...
If you do, I recommend doing a complete uninstall of it, delete your `~/.atom` folder (or `%USERNAME%\.atom` on windows), and reinstall from scratch. I'd also recommend trying out the new-ish "Atom IDE" set of plugins [0] which works fantastically for languages that have an IDE plugin (javascript/typescript, C#, Java, PHP, and some still-kinda-early-stage ones for Go, C++, and rust right now). I don't know what it is about the "IDE-*" packages, but they don't install well to "aged" setups, and they don't uninstall well either. If you don't like them, i'd recommend wiping clean again before moving on... (all the customizability in atom comes with the major downside of needing change-management in your goddamn editor...)
I'll freely admit that the amount of time I sunk into getting my atom install the way I like it probably approaches "not worth it" levels (I tend to do that with any editor!), but spending an hour or 2 looking for and playing with packages really pays off now.
Java will probably always be better off in a "made-for-java" IDE, but i've done a fair amount of C++, PHP, and Go work in Atom and it's a breeze.
> I may have jumped the gun here myself, I tend to get a little overzealous...
I sometimes make the same thing. It's perfectly OK, we are all human. We all have some technology we like to protect as our only child (my soft spot is low-level & high performance tech). The key is to be able to recognize one's reaction and tune it little by little. I had my share in both sides of a flamewar and I'm very well done in that respect. BTW, I didn't feel like you did. I just wanted to say we sometimes overreact, and even if we don't project it to otherside or just to outside, we can learn from the experience.
> If you do, I recommend doing a complete uninstall of it...
I've completely removed every atom related folder from my home folder some time ago. I'll install the latest .deb package and progressively experiement with it. I won't tie anything important to that setup, so it will be an experiment bench for me.
I'm using Eclipse for ~10 years, so I know the effort you put into setting it up. It's always worth it, don't worry. I maintain three eclipse installations (home, office, laptop) and they sync their settings over Oomph. So when I improve something in one, all three benefits :) When you use something for a very long time and set it up to your liking, it feels like home. :)
It's not necessarily about large file size (storage is cheap anyway) and memory usage (although RAM on portable devices is still kind of limited).
Performance in Electron-based editors (e.g., Atom) is horrible. When you're used to vim or fast GUI-based editors like Sublime, even typing in Atom feels sluggish. That's not even talking about loading large files, search-and-replace operations, multiple cursors, etc.
That's all very fine and well, but programmers are rarely programming for themselves. If you are targeting your product at the user specifically then you should be aiming at least at a pleasant user experience. If the "advancement" you cite is at the expense of the user then perhaps it's not that much of an advance.
Electron/Chrome is not slow or bloated. The majority of people developing for the platform are idiots who do not know a damn about memory management or writing performant code. They just throw in some random code copy/pasted from stackoverflow or download a npm package and then cry about memory usage and performance.
The general reason for the performance of C/C++ apps is that the language forces you to care about your memory usage. The lack of a garbage collector ensures that you think twice about what memory you allocate and free. Someone with a background in c/c++ will write efficient electron apps. Their past experience ensures that they reflexively write good code.
I wrote an electron based music player that uses less memory than a native player developed in c# that i wanted to replace.
I spend an hour reviewing and profiling every feature that I add to ensure that i am not wasting memory. And it shows.
People need to understand that it is not the platform that is slow. It is the stupid code that you write without a thought that is the problem.
I used to use Ulysses. It's a great app, but shortly after I paid $40 for it, they switched to subscription. I'm now looking for a new app.
I use Mac for work (with the old no longer updated Ulysses)
Linux at home (using caret)
And an Android phone (JotterPad).
I sync between them using Dropbox.
Once Ulysses stops working on a future MacOS update, I'll likely switch to caret there as well. It's relatively easy to get a really nice, supported polished Mac app. Working in a cross platform world is tough. I'd love to be able to replace Ulysses and caret with a native Markdown editor like this. I'll check it out.
I have less problems with the subscriptions, but with their proprietary file format. All I want to do is edit text files and maybe convert them to blog posts. It's impossible, since Ulysses doesn't seem to support batch exporting multiple files to Markdown.
For pure writing, I use iA Writer, but its library/organizational features are lacking.
Since I have no Apple hardware except for a work provided laptop, I don't use Ulysses' proprietary format. I just have a folder (that's in Dropbox) with straight .md files in it, and have added it to ulysses. After the Evernote mess, I don't want anything in a proprietary format.
Plus, since I'm cross platform, with different apps on each platform, I don't have a choice.
You can use Ulysses in the proprietary format or open regular .md files. I have a folder open, so I have multiple layers of folders. It works pretty well.
The proprietary is required for iCloud (if you want to share notes with the iOS app).
VNote is great for managing and editing plaintext md files. All data is plaintext and you could even use any editor to edit your notes even after VNote is obsolete someday.
The documentation hasn't really been written yet, which is a bit sad, as I kinda wanted to dive into themes and templates, but I don't think it'll take too long to work out how to make them.
Search is lacking, but high priority so hopefully I'll see it soon.
Mini-rant: What happened to Boolean search in note taking apps? It seems to have been lost over the years. When I search for docker and get 80 notes returned, then change search to “docker AND login” I want to narrow my search, not get 110 notes returned.
I was ready to complain about there being no vim mode, but there it is, right in the github readme, "Supports Vim mode". Me and a couple hundred users have been begging typora to support vim keybindings but we've been ignored so far. I'm definitely going to give this a try when I get some time.
VNote is inspired by Vim, so there is no reason to not support Vim mode in VNote. However, the Vim mode is implemented by myself one feature by one feature and it does not support the `.` and macro yet.
For an app that I thought I absolutely don't need, pretty awesome. I like that you don't try to sync my notes for me and hide it in proprietary db and sell me subscription for it.
Thank you, I will use it and see if it will stick, thanks for making it.
While I really like the lightweight approach and easy inserting of images, I don´t see a big difference to edit md-files with Sublime/Atom/Code and activated tree-view/markdown/vim-plugin.
Maybe you should advertise more differences for a developer compared to his already running Sublime/Atom/Code/Vim-Setup with a Notes-Folder full of markdown-files.
Indeed, VNote is inspired by Vim when I used Vim to edit Markdown notes for about a month. VNote utilize many code editors' features for note taking, such as Vim mode, vertical split, and shortcuts.
The obvious differences to code editors may be:
1. In-place image preview. Preview of formulas and flowcharts will come soon. This really help user to focus on the content without a side-by-side live preview or alternating between read/edit mode frequently.
2. Note management. VNote handle stuffs like images, attachments, and tags in the future.
Currently I am focusing on the edit experience of VNote. Next step, I will try to connect to third-party store services within VNote, which enables VNote to sync by itself. After that, we could think of the Web client. According to current development progress, I think it will take long time to achieve it.
Currently I use other apps to record thoughts anytime and anywhere via phone and reorganize them in VNote.
I'm really happy with VSCode as my "Markdown note-taking app", especially after the support for multiple projects was added in the last release. This means, I open a workspace with multiple projects (my dev notes, config files, markdown files for my static blog, etc.), and I can access any file by using the built-in file search (Ctrl + E).
Sounds good and I really like the design choices regarding file management and sync, but honestly I don't see any advantage over just using plain Vim(which is already tuned to my preferences).
Paired with a few plugins it offers all the same features except image preview, and I don't really need that.
Yeah! I used Vim to take md notes before writing VNote. I intended to write VNote to manage and preview the images, formulas, and charts. Indeed, VNote bollows a lot from Vim, like the leader key, split, and so on. I am satisfied about VNote for now. :)
VNote is a Vim-inspired Note-taking app. That is where "VNote" from. Give it a try :)
1) Would be neat if you could use this to edit Jekyll / statically generated sites, especially if it had basic git integration.
2) Would be especially useful if it had a mobile client. (Although I know there’s several mobile markdown editing apps, if it had Jekyll / static site generation - that’d be really nice)
Hi, for now you could use VNote as an editor to open and edit any md files. VNote treats internal notes and external files differently. Indeed I use VNote to edit the github page and it is really enjoyable.
VNote uses notebook to manage notes. A notebook could be local, or synced via Dropbox. So you could use git to manage your notebook, too. Integration with git will be considered in the future.
I like this, but for the windows version it would be better to default the notebook directory to either My Documents or something under %appdata%, currently the default is a new directory directly under the users/<user> folder.
Use this kind of syntax seems do not support up to 6 levels of headings? VNote use `markdown-it` to render the Markdown, so VNote will recognize them in read mode. VNote just choose one syntax to recommend for simplicity, so the outline seems do not recognize it as header. For another example, image links in reference forms will not be previewed in place.
Jokes aside, this looks nice! Especially good to see that native C++ development (even if it's in Qt) isn't dead.