Some tiny improvement proposals

[Maaartinus]

• The tags listed in the "Available Tags" section should be clickable. I guess, this could be the fastest way how to find an API.
• The description, i.e., the part between the title and "Available Tags" (excluded), should be collapsible. In my case, it's a pretty long text which pushes the most read part ("Paths") down.

I guess, I could contribute it (the only obstacle is the beginning of livedoc.js, which kills my editor, probably due to a stupid highlighting regex).

[twskj]

The tags listed in the "Available Tags" section should be clickable. I guess, this could be the fastest way how to find an API

I have no objection to that. This should be relatively easy to tackle if you want to make PR. Otherwise I'll roll it out after new search functionality

The description, i.e., the part between the title and "Available Tags" (excluded), should be collapsible. In my case, it's a pretty long text which pushes the most read part ("Paths") down.

Good suggestion. This probably just needs to convert desc part from string to object and attach visible to store state and attach a toggle function to it.

PS. One thing I personally do is to develop from the generated file. If you give pretty-swag -f lite the file size is relatively small. Once we get a result we need, we just have to copy over to livedoc.

You can also try to change extension to .txt and see if that does the trick. All scripts are embedded there because I try to accommodate web-base use case since it can't access file system. But come to think about it now maybe I can introduce a flag to switch web vs node environment 🤔

Note: when copy over to livedoc it's likely that we need to escape reserved words.

[Maaartinus]

I hacked something like this:

.tag-container>span.tag{background:inherit;border:none;box-shadow:none}

<div v-if="getAllTags.length > 0" class="tag-container">
    <span class="bold">Available Tags: </span>
    <span class="tag" :class="[appConfig.showNav ? 'pointer':'']" v-for="tag in getAllTags.split(/, ?/)" @click="addToSearch(tag)">{{tag}}</span>
</div>

It's hacky, but together with AND-ing tags it'd provide a perfect search. But then, the possibility to remove one / the last added tag would be nice.

---

PS. One thing I personally do is to develop from the generated file. If you give pretty-swag -f lite the file size is relatively small. Once we get a result we need, we just have to copy over to livedoc.

That's what I tried, too, but the main problem is that I always forget not to open livedoc.js in my emacs and it dies. No work gets lost, but I'm used to never close it and re-opening everything costs about as much time as the tiny change I want to do.

All scripts are embedded there because I try to accommodate web-base use case since it can't access file system.

That's fine as I'm serving the generated file from my Java server and it makes it simpler. For me, a using CDN would do even better. I could imagine livedoc-lite.js (using nodejs or CDN) being the editable file and livedoc.js being generated.

I'm trying the atom editor now and it works well, but the embedded scripts come into the way again and again, e.g., when searching.

[twskj]

I am messing around with the folding meta-data part but don't find a clean way to present it. Would setting sticky navbar (using flag -fixedNav) mitigate or solve problem you are seeing?

[Maaartinus]

I don't understand your last comment. My above problem is related to editing the sources. My proposal was something like

• Create livedoc-lite.js which uses CDN (or nodejs), embeds no scripts, and makes editing simple.
• Create livedoc-embeddings fragment containing nothing but the huge scripts.
• Remove livedoc.js from git and generate it in the build process (by replacing the CDN links by the embeddings).

I guess, it'd help you in the long run, too. OTOH, my editing problems are mostly gone since I started to use atom.

I'm using already "fixedNav": true.

[twskj]

I got what you mean now!!! guess I need some coffee 😬