Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags

Some feedback after a week of daily driver use

A topic by False Idol Workshop created Nov 01, 2021 Views: 162 Replies: 3
Viewing posts 1 to 4
(5 edits)

I’ve pumped around 10k words into Deepdwn over the last week or so. There’s a lot to like, but also some issues.

  • this morning I tried creating some templates. They’re great, btw, thank you. Using {{ time }} in the title: frontmatter field really rustles Deepdwn’s jimmies. I reproduced this on Ubuntu and Windows. You didn’t claim it as a feature, so I wouldn’t necessarily call this a bug, but it would turn {{ time }} from a cool little feature to a killer inclusion for me if it evaluated in titles. For example, I have a lot of calls with the same people which I take notes on, so I usually include dates in document titles because “Call 16 with Adam” doesn’t tell me enough. 25 Aug 15:30 Call with Adam, though, that’s the stuff.

  • in a similar vein, it might be helpful to add ctrl+click multi-selection between and within categories, tags, and directories for deeper filtration. E.g., selecting tags “Adam” and “Julie,” in category “Calls,” in folder “Work” would help in cases where “Adam” and “Julie” occur across directories, projects, and other contexts. This may only start to show its value in cases where Deepdwn manages a significant corpus over a long period of time. But I’d like to use Deepdwn to do just that.

  • I use a 65% keyboard. The laptop keyboard emulates a numpad with Fn, but still the create-from-template shortcut doesn’t work. I think that if you aren’t going to offer rebinding to cut down on settings you have to maintain, then a paradigm which sticks to keys 99% of laptops have, maybe Ctrl+T+Numrow, would be a better replacement that doesn’t overlap Heading collapse shortcuts

  • nested lists apply inconsistent spacing beneath their elements. I think they should apply the same spacing as a top level list. An example:

    nested list spacing issue image

  • performance puts a significant dampener on the prospect of using Deepdwn as a daily driver over a long period of time. I don’t know if it’s Electron or what, but Deepdwn will open using 60MB of RAM and 6 hours later use 150 even if no changes are made to any files. (The starting memory usage and continuous memory creep are actually significantly worse on Windows, now that I’ve had the chance to test it there.) This is with it only pointing at a directory of 13 files totaling about 30KB. To roughly approximate what this might look like in the future, I went and tested how Deepdwn handles progressively larger numbers of files by adding in duplicates of that folder, stopping at 25MB worth of files because the app had already become inoperable. The app becomes progressively more sluggish and difficult to use. Launching takes forever, it uses staggering amounts of memory, and editing experiences significant lag.

    Maybe that’s something that simply can’t be helped because of your stack, but despite how much I enjoy using Deepdwn and want to see it succeed, if someone writes prolifically in it they will simultaneously write themselves out of being able to use it. All of the finnicky stuff above is frankly second fiddle to this. I would even argue that every feature addition in your roadmap is second fiddle to this. I’m going to be following Deepdwn’s development and trying new versions as they come out, because in terms of the composition and organization experience it’s one of the better Markdown editors I’ve used. It just needs to scale. But I don’t think I can recommend it to people until that’s addressed.

(4 edits) (+1)

Hi,

First, thanks for giving Deepdwn a try and thank you for the feedback.

Using {{ time }} in the title: frontmatter field really rustles Deepdwn’s jimmies.

I’m not sure what you mean by this. Can you provide examples of what you’re trying, exactly, what you expect to happen, and what occurs instead?

It sounds a bit like you’re trying to do something that the templates, and that placeholder field aren’t designed to do, which is probably a failing of the devlog update more than anything else.

It’s designed so that you may create a template like:

---
title: "{{ time:d MMM t}} call with"
tags:
 - calls
 - template
---

When you create a new file using this template, the new file’s content will be prefilled with something like:

---
title: 1 Nov 2:23 PM call with
tags:
 - calls
---

[edit] I do see a possible YAML parsing issue here. You’ll likely want to enclose the title in quotes as shown.

Add ctrl+click multi-selection between and within categories, tags, and directories for deeper filtration

This is a planned feature currently :)

Better keys for templates

These shortcuts will likely change, if for no other reason than that the displayed shortcut key in the native menu incorrectly display these as Ctrl+1 etc. which is misleading. I thought they were better than no shortcuts at all (for those users not using low% keyboards anyway). Ctrl+T+number is pretty awkward for typing. Possibly Ctrl+Shift+Num

nested lists apply inconsistent spacing beneath their elements

I believe you’re running in to a commonmark “feature” rather than a bug, known as “loose lists”, but I can’t say without seeing the markup that generated that list. My guess is it looks something like:

* Testing
  
  * testing
    *testing
  * testing
    * testing
      * testing
    * testing
  * testing
* testing

Which will produce the output you’re seeing for the top level list. You’ll also notice that any subsequent top-level bullets in that list also receive the increased spacing, as the top level of the list is marked as loose.

If that’s not the case, please create a support request for it that includes the markup you’re using.

(+1)

I went and tested how Deepdwn handles progressively larger numbers of files by adding in duplicates of that folder, stopping at 25MB.

if someone writes prolifically in it they will simultaneously write themselves out of being able to use it

First, in general, I think this form of artificial benchmarking isn’t particularly useful, and this example strikes me as somewhat unrealistic. Math follows.

While 25mb doesn’t sound like a whole lot these days, keep in mind that markdown is a plain text format, so that 25MB is doing a whole lot of work.

If 30kb represents about 10,000 words (depends on things like file encoding/content etc.), and took roughly a week, you would have needed to create something like 800 duplicates of that folder, totalling more than 10,000 individual files that Deepdwn needs to read, manage and monitor for changes.

If you were to write at your current output of 10,000 words/week (and required no editing), you’d reach one copy of War and Peace (600,000 words, 1200+ pages, 3.1MB) in about 14 months.

To reach 25MB (~5,000,000 words, 9,600 pages), then, would require you to maintain that same continuous output, every week, until 2030.

I’m not sure that means that Deepdwn “doesn’t scale”, so much as that there are potential use cases that Deepdwn isn’t designed for, and that might include: tens of thousands of markdown files that Deepdwn needs to be aware of and parse, with millions of words. I don’t think that excludes prolific writers, who are certainly among Deepdwn’s target users.

That all said, there are improvements that can be made to the way Deepdwn handles extremely large collections of files and/or large files. Those will likely happen when the search functionality is rebuilt, but I don’t have an ETA for that.

I’m going to be following Deepdwn’s development and trying new versions as they come out

Great! If it isn’t a good fit for you now, I hope that it will be some day in the future (and hopefully before 2030).

Aah, glad to hear it re: multi-select. Wrapping quotes around the Title entry let me add the date in there, that’s perfect, thank you. And thanks for the suggestions regarding the lists. Testing a few different spacing variations real quick, this addresses some of the issues, but not all of them.

I think it’s a just an issue with the preview rendering since both HTML exports properly treat everything as a loose list. I’ll make a post in the bug section.


there are potential use cases that Deepdwn isn’t designed for, and that might include: tens of thousands of markdown files that Deepdwn needs to be aware of and parse, with millions of words

Can’t fault you for thinking this way. I happen to think the value of Deepdwn’s organizational features only goes up as it encompasses larger and larger bodies of files. Incidentally, it was actually significantly fewer files. I screwed up:

I forgot about the images. Only about 4.3MB of that 25MB group of directories were .md files. Images made up about 165KB per 200KB directory. Anyway, the 25MB point was just the size at which the program became wholly inoperable. The program became uncomfortably sluggish at roughly 5MB total/1MB Markdown, and was basically unusable but still technically responding at 15MB total/3MB Markdown.

I’m concerned about the performance because my personal writing directory sits at just over 12MB in .txt/.md files. Certainly no Tolstoy, since that represents almost, god help me, 10 years of wildly varied activity levels. Too much to organize in Deepdwn using the normal file settings though. I don’t think it’s unusual for people to have a standing base of documents they may want to use with Deepdwn, and I don’t think 3MB of files is so outlandish a number either.

However! Today I discovered that turning off file system monitoring mostly eliminates the performance issues up to, so far, 3MB of Markdown files. I’m going to keep pushing it and integrating more of my doc dir’s subdirs until I hit a limit (if there is one in this mode). This should be workable for now. I think anything lost from not having the file system monitored will be worth it in terms of overall usability, though it’ll be nice to hopefully have that again too in the future. Also, I can feel comfortable recommending this to more prolific friends again, which is great.

All that said, I wholeheartedly agree with this:

Great! If it isn’t a good fit for you now, I hope that it will be some day in the future (and hopefully before 2030).

This is the last you’ll hear out of me on the performance front, since harping on about it would be both rude and a waste of our time. (Though I still think it’s very important.) Thank you for your patience and your explanations.