New config options

[jannis-baum]

continued discussion from #34

• custom client-side JS, multiple files
• support multiple custom style sheets
• 1-n files with globs to ignore files in directory lists
• assign name attribute to directory items that include full name of file/directory for custom scripting & colors
• option to redirect to ~-path
• document changes/features
• move all config to vivify-server so that viv doesn't depend on jq anymore done in ESM and simplified config #90
  • port & timeout are trivial
  • open command can be handled by having the option to pass an argument to vivify-server and then open that; we can probably even use a Node-way of doing it so we don't need any program anymore

[jannis-baum]

@tuurep Another being a hide dot-prefixed files -toggle. <- if I was the sole user of this, I'd want to do it with a keybind, something like Ctrl + H, but that has the downside of not being discoverable.

1. Interesting thoughts about the keybinding; that would require a good bit of additional client-side JS. This also seems quite customized to me, so what do you think about just offering a config setting where people can add their own additional client-side JS? That should open up lots of possibilities and keep stuff that is too custom out of main Vivify.
2. The hiding certain files however is more straight forward that I was also already thinking about: on macOS you get these pesky .DS_Store files everywhere (e.g. see screenshot) that I hide for every directory listing tool I have. So I was thinking of adding a config option to specify regexes for ignoring files/directories that match.

Let me know what you think!

[jannis-baum]

On another note: we could "complexify" (2.) and instead of just giving the option to hide matching files/directories also give the option to assign a CSS class. This would make the custom JS easier for your use case and probably also others.

You could assign a class to items that start in . and then use your custom JS to toggle the display property of that class.

[tuurep]

1. Yeah I'm not sure what that looks like in practice, but if it means I can script some stuff per keybinding, and it's not too arcane to do, sounds just great
2. So that's a bit like a .gitignore but for vivify dir list? Definitely good. Also since this is a markdown viewer (lets not forget this lol) a very sensible setup could be: show only directories and markdown files 😄

[jannis-baum]

1. Yeah I'm not sure what that looks like in practice, but if it means I can script some stuff per keybinding, and it's not too arcane to do, sounds just great

Yes, if we add the option to assign classes by matching regexes then it should be about 3 lines of code on your custom config! :)

2. So that's a bit like a .gitignore but for vivify dir list? Definitely good. Also since this is a markdown viewer (lets not forget this lol) a very sensible setup could be: show only directories and markdown files 😄

Yes! And yes, Vivify is a markdown viewer but it's also just a viewer; it does e.g. do code highlighting if you open non-markdown files.

[jannis-baum]

Just realized the classes by regexes will also allow people to easily do custom color highlighting by file extension, for example. I think this is good to add, seems to bring lots of customization benefits for little overhead.

[tuurep]

I'm kinda bummed out about how slowly the page refreshes after saving file. Would this be easy to change or configurable if necessary?

I have a couple related questions with that:

• Would it be possible to refresh page even without having to save?
• Sometimes I run into this: trying to open an empty file doesn't work, it needs to have like at least one character in the contents

^ Both of the above occur to me when I use Vivify as sort of a live-notetaking side preview

Edit:
Oh yeah, some of this might be about the vim plugin

[jannis-baum]

Hey @tuurep I replied to you on the plugin's repo: jannis-baum/vivify.vim#5

[tuurep]

I'd like it if $HOME could be substituted to ~ on the address bar. Could this be an option? :)

i.e.:

http://localhost:31622/viewer/home/tuure/projects/vivify/README.md

to

http://localhost:31622/viewer/~/projects/vivify/README.md

Similarly, $HOME to ~ substitution in the path components so that page title could be for example ~/.bashrc instead of tuure/.bashrc, in case this isn't messy to do.

[jannis-baum]

In the address bar it might be a bit tedious to implement and would make us more error-prone, especially if we want to keep both options.

If it's just about the page title on the other hand we could just provide the option to have the path components use ~ instead of the components that make up $HOME. Would that be enough?

[jannis-baum]

As for being able to open a URL like http://localhost:31622/viewer/~/projects/vivify/README.md, this was supposed to have already been working but there was a bug in the regex. I just fixed it: #75

[jannis-baum]

In the address bar it might be a bit tedious to implement and would make us more error-prone, especially if we want to keep both options.

Actually, now that I thought about it longer, we could probably just make an option that will have express always redirect to the ~-equivalent of the URL. That should be clean & straight forward.

Edit: Looks easy: we can check if $HOME is part of the URL and if so replace it with /~ and redirect there. The slash in /~ is needed because it is part of $HOME and needs to stay there for the URL to have it between viewer and ~ - that was the regex bug before ^^

[tuurep]

Cool!

To be clear, the only thing I care about for my own use is ~ on the address bar but then realized it would appear more consistent if the pagetitle reflected it as well :)

[jannis-baum]

Noted! With the redirect it should be good. I'll update the list above.

[jannis-baum]

I might work on this next after the other two PRs are through :)

[tuurep]

Ok, thanks!

[tuurep]

Hey I'll be sitting on a train tomorrow for many hours with my laptop with nothing else to do so I can definitely finish this tomorrow

E: meant to comment on the PR, so I mean, to review that and test the new options

[jannis-baum]

Hey I'll be sitting on a train tomorrow for many hours with my laptop with nothing else to do so I can definitely finish this tomorrow

E: meant to comment on the PR, so I mean, to review that and test the new options

Awesome, thanks! I'm excited to release v0.2.0. I decided to make the release once that PR is merged. The other things that are open also work well as next minor releases I think.

I also added a Homebrew package (primarily for macOS users) earlier and I think (90% sure) that it wouldn't work with the current latest release because of some code-signing Apple stuff that I fixed when we changed to Node SEA. So it'll be great to have a working version out☺️

[tuurep]

Nice

Also looks like I can use nvm in the AUR PKGBUILD:

https://wiki.archlinux.org/title/Node.js_package_guidelines#Using_nvm

[jannis-baum]

Nice

Also looks like I can use nvm in the AUR PKGBUILD:

https://wiki.archlinux.org/title/Node.js_package_guidelines#Using_nvm

Nice, that's cool! Maybe we can have everything work again after all ^^