xvxx / deadwiki Goto Github PK

It used to work well, now it doesn't. Hashtags don't work at all. Probably programmer error when I switched to Hatter.

I installed deadwiki using cargo. The dead command runs, gives me help messages, and when I point it at a directory with .md files, says it's serving on port 8000. However, when I try to fetch anything, I get either 500 or 404 errors.

My directory has an index.md file. When I visit 0.0.0.0:8000/index both the HTML and the dead console report:

GET 500 /index
<h1>500 Internal Error</h1><pre>Custom { kind: Other, error: "Can\'t Find Asset" }

If I try to fetch index.md instead I get 404 not found.

If I just fetch /, I also get the 500 Internal error.

I must be doing something wrong, but can't figure out what, based on the documentation, so I must have missed something subtle.

thanks -- your wiki philosophy is right up my alley!

deadwiki fails to render the index of my notes directory with the error:

RuntimeError: can't find var: print-nested
html/index.hat: line 1, col 1

I get the same error with this minimal example:

bug
├── a
│   └── b
│       └── c.md
└── d
    └── e.md

mkdir -p bug/a/b
touch bug/a/b/c.md
mkdir -p bug/d
touch bug/d/e.md

I should probably just read the source, but thought I should be able to figure this out by fidding:

How do I include locally stored images? I tried just storing them among the ".md" files, and referencing them with an <img src="test.png"> but that didn't work. Also tried the wiki ![](test.png) syntax, but that also didn't work. Also tried ./test.png, as well as creating an img directory and referencing img/test.png, but none worked. I must be missing something simple, but ... ?

Dark mode CSS was added in c128feb. It kicks in when your OS is in "dark mode".

Need to add a little SVG icon so you can toggle dark/light mode in your browser at will, too.

The index or page directory page renders nice drop down menus for folders. Unfortunately, the code only works when the folders are one deep. Additionally there is no indentation making it difficult to tell the folders apart.
Indentation is easy enough to add with <ul></ul> tags. I tried implementing a secondary folder mechanism myself but I'm not a very experienced rustacean and all my solutions proved very buggy.
Also, this project is really cool. Keep up the good work!

Should re-render the form instead, with an error message.

Which is the default page name? Right now running dead test-wiki/ opens a blank page, allowing me to create a new one. How can I add content to the default blank page? Thanks!

Do this:

• visit a page
• edit, then submit changes
• click on another browser tab
• return to deadwiki tab

What I'd expect to see is the edited page. Instead what I see is the page being edited again.

I'm seeing this on Firefox. On Chrome it works fine.

I've just seen https://www.reddit.com/r/rust/comments/impz8p/cratedigging_episode_3_deadwiki/ , and when I was looking at the description, it looks awfully lot like my https://github.com/dpc/tagwiki , so decided to say hello.

For me personally the tag handling (everything is addressed by the tags) was the important part, and that's why I was hacking on tagwiki.

I'm actually not doing any coding in my free time in the last few months due to COVID and personal reasons, and I don't expect it to change anytime soon. But maybe you could use it for inspiration or something. Anyway. Happy hacking!

I created a page with the following contents:

 * [here is a page with funny $ ! * characters ()]
 * [and another with a trailing slash/]
 * [ this should be the same ]
 * [this should be the same]

The first link opens and creates a new wiki page fine, and I see it in the file system, but when I click on it a second time, I get a 404.

When I click on the second link, it creates the directory of that name, but the contents are stored in a file called .md at the top directory.

It may just be personal preference, but I think trim()-ing page names to make white space around []'s irrelevant (as shown by the 3rd and 4th links producing two different wiki pages.

I see in the code a number of places where the links are turned into paths by calling tolower() and substituting _ for " ", etc. I suggest using a function, maybe called link_to_file_name, which applies (perhaps parameterizable) rules to turn a link into a file name. I thought about using urlencode(), but all those %hex values are ugly file names. I think it's reasonable to do something ad hoc for the wiki, but it should be pretty. Maybe " " -> _ as you currently do, trimming leading and trailing white space, allowing a few special characters through (I don't have strong opinions which), eliminating the remaining ASCII punctuation, because they can cause filesystem issues, and perhaps (?) passing along unicode, since that's international-friendly, and operating systems these days are pretty amazing that way. I'd be happy to write this function - but it's the easy part - the trickier part is to make sure it's called in exactly the right places.

I think of this as an opt-in feature: if you have a top-level file called index.md, fetching the root of your wiki would render it instead of the current "index" behavior. Maybe have the current index behavior always be available with the pseudo tag "all_pages"? (kind of like "recent" does recent updates)

I'm not asking for a fix for this issue, but more to start a conversation on how you think the project should handle conflicts (if at all?)

I'm quite new to Rust, but have a reasonable amount of experience with distributed document syncing, including conflict resolution, and am more than prepared to help work on this to fit my personal wiki needs!

When there are conflicting changes on the git remote, and on the wiki, deadwiki will push the unresolved merge conflict back up to the remote. This is preferable to losing the data on either side, but nothing in the logs or UI indicate a conflict has happened, and the rendering of a markdown file containing merge conflicts is kinda broken.

This is somewhat tricky, as changes are synced asynchronously, so the conflict isn't detected until after the user has submitted changes and sync has started. One basic approach could be to trigger a pull before saving a page, and at that point, notify the user a conflict has been detected, and ask them to resolve it manually in the markdown editor before saving again, but this adds quite a bit of overhead to saving of documents.