Right now, URLs that are not explicitly made into links are just text. It would be nice to auto-link them for consistency with what github does.

This could be done on the Rust side in the markdown parser -- for each Text event, run a search-and-replace on the contents. Or it could be done in javascript, which could be done after the document is rendered, and might be easier (would it?).

Right now, there's only one CSS used, github's default one, which I literally ripped out of the site. It would be nice to allow changing the CSS to the dark-mode version and possibly others, like crates.io's markdown rendering. So, --theme github-light, --theme github-dark, --theme crates.io.

Alternatively, it would be plugged into the file config -- that would make it easier to pick just one, but harder to switch. Could be that "both" would be a good option for this particular setting.

A help dialog that shows keybindings, like Ctrl+scroll to zoom in/out, would be nice. It should be relatively easy to do this with GTK.

An about dialog with some basic info, a github repo, documentation links, would also be nice and easy, probably. An "open file" dialog would be something I never use, but I guess rather common for something like this.

Settings being editable via GTK might be nice... but treating the config as simply a storage mechanism might be a problem, since right now, it has explanatory comments.

(Very much a side note, I'd love a YAML parser that allows updating keys without touching comments. Definitely not in scope for the project, though.)

GitHub lets you use relative links when referring to images (and any other files) in the repo, e.g.

![Company logo](distribution/media/logo.png)

It would be nice if quickmd supported this. Ideally it would look for the file starting at the root of the current Git repo, but for a start using the directory of the current file would be good enough.

I can try opening a PR for this if it's not too hard to implement.

Right now, quickmd doesn't work on MacOS, because there's no working webview2gtk. It might work on windows, but it'd need GTK installed.

It might be nice to use the web-view project instead, since it seems like it's cross-platform and it uses whatever works on each platform... but it might be much more inconvenient to work with, with a lot of the logic needing to be in javascript. I have no realistic idea of how it would work.

HTML generation, file-watching, and configuration have nothing to do with GTK, so a good chunk of the logic might be fine without it. Whether web-view is convenient enough UI-wise is the big question.

It's something I'd try at some point, at least. Though maybe not even in this project, but in a separate one by copy-pasting stuff ¯\_(ツ)_/¯

It shouldn't be difficult to listen to keybindings and scroll up and down. Maybe gg and G could also jump to the top and bottom of the document respectively. I'd also like to use J and K for faster scrolling, though these are not as vim-compatible.

It would be nice to get this done in the GTK portion of the code... but I'm not sure if it's possible. I can't see a way to scroll the webview from GTK, but I might be missing something. It'd be relatively easy to do in javascript, but it might make it complicated to implement #5, since keybindings would be kind of split between GTK and javascript in a non-obvious way.

It might be that GTK simply triggers some javascript -- it might be the best compromise, and probably won't have a whole lot of overhead. Difficult to say without trying it out.

This could be a hard one, depending on what's being attempted.

Ideally, clicking a link in the markdown document would actually open it in the default browser. There's no point in opening it in the embedded webview. But I don't see a good way to hook this "link was clicked" event into GTK other than maybe some kind of polling to check a global variable?

Alternatively, it might be possible to use the javascript clipboard API to just copy an external link to the clipboard, and the only next step would be pasting it in the browser. If the clipboard API works, it should be relatively easy to do this in the javascript part of the app.

If so, it would be nice to show some kind of notification. The "link preview" div in the bottom-right could also change between Copy <url> and Jump to <url>, the second one showing up for internal links like anchors.

There's a branch called exec-editor that is unfinished. Right now, it execs the app into a GVim when pressing Ctrl+e.

Instead, the app should look up the configured editor from the YAML configuration and exec into that. If there's no editor configured, it would be ideal to show some GTK error message that says "go fill the editor in ", or to default to one of several known editors that exists in PATH. Maybe gvim and code to start.

In terms of mappings, I'm considering e for spawning an editor and E for exec-ing into one (only for unix). Switching from preview to editing, effectively. The preview is supposed to be read-only, so using standard keys for actions should not be a problem.

Would it be possible to get the "global" GUI editor? Maybe by fetching the association for text files? I remember investigating it, but I realized that markdown files are also considered "text", and I wanted to associate them with quickmd for double-clicking... although that might be a problem as well if quickmd gets associated with all text files. Starting with an explicit config might be easiest.

After upgrading glib2 to the 2.72 version, the preview window became completely blank. quickmd --debug doesn't produce any errors. Downgrading the package fixed the issue.

Edit: This is on Arch Linux with Wayland.

Hi.

Great tool ;)

It would be nice to provide a binary release, It took me some time to build everything on my machine, and had to install some missing dependencies, as well as having the rust toolchain (which I already had, but for other users might be complicated to setup).

It should be simple to do with GitHub actions. For example: https://alican.codes/rust-github-actions/

The preview isn't updated when saving changes to the watched file in NeoVim.

Looking at the debug logs, it seems quickmd detects the file as being removed and recreated, instead of being modified:

[DEBUG quickmd::background] Ignored watcher event: NoticeRemove("/home/florent/dev/devlint/README.md")
[DEBUG quickmd::background] Ignored watcher event: Create("/home/florent/dev/devlint/README.md")
[DEBUG quickmd::background] Ignored watcher event: NoticeRemove("/home/florent/dev/devlint/README.md")
[DEBUG quickmd::background] Ignored watcher event: Create("/home/florent/dev/devlint/README.md")

This doesn't happen with other editors (tested in Leafpad and nano).

I have some rudimentary knowledge of Rust, so if this is an easy fix I can try to take a stab at it. Otherwise, I'd still be happy with a quick keybinding to manually refresh the preview, e.g. r of F11 😄

It would be really nice if it was possible to customize keybindings for spawning an editor, for scrolling, etc.

It could be implemented the way Alacritty does it:

  - { key: Insert, mods: Shift, action: PasteSelection   }

Alternatively, I'd love to have vim-like <S-Insert> descriptions of keys, which are pretty compact and readable (though I might be biased here).

This one might be done quite easily by using include_str... but it would be a lot of repetitive lines, since highlight.js has tons of separate files with different language support. It could all be packed into one file and exported, but it would be a large file, with lots of stuff that would never be used.

Currently, the code knows which code languages are being used on the markdown page, so there's no issue in including just the right files. So an "easy" way to solve this issue is something like:

• Create a folder in res with an import of highlight.js files.
• Create a hashmap, maybe with lazy_static or once_cell with include_str lines for these.
• Package them up in a struct with a sensible interface to write these script files like we do here:

  quickmd/src/assets.rs

  Lines 88 to 93 in 9e09b02

  	fs::write(output_path.join("main.js"), MAIN_JS).
  	unwrap_or_else(|e| warn!("{}", e));
  	fs::write(output_path.join("main.css"), MAIN_CSS).
  	unwrap_or_else(|e| warn!("{}", e));
  	fs::write(output_path.join("github.css"), GITHUB_CSS).
  	unwrap_or_else(|e| warn!("{}", e));

An interesting, more complicated idea, might be to make this reusable, maybe even pull this concept into a separate crate. Something like an include_dir! proc macro that recursively reads the whole contents of a directory, and does the whole lazy-static hashmap setup above, it just doesn't require somebody to manually go over the individual files in the source. The hashmap that include_dir! spits out could be keyed by a Path. The contents might even be compressed like include_flate does, but that's a separate thing.