itsonlyaname said:
Updated
Didn't encounter the bug where the entire first page of results is stripped, let me know if it still happens with this version.
It doesn't happen now. Maybe it won't return. :D
Posted under General
Ok, two Endless Pages bugs - minor and rather major.
Minor one:
When search returns only one page, following is printed at the botom of the page:
Danbooru2 Tweaks & Features: error parsing Current Page from paginator data ReferenceError: ep_rs is not defined Danbooru2 Tweaks & Features: No paginator found, switching to url fall-back
This doesn't happen when there are 2 or more pages of results and when all pages are loaded.
Rather major one:
When doing one tag search and switching to "wiki tab" (that Javascript magical one), Endless Pages loads pages indefinitely (I suppose that's problem with visibility checking).
While "buffer as much as you can" could be considered a feature when it gets its own button, it looks like bug when it's triggered by entering wiki entry while searching.
Oh, and you have a pull request from me on Github which enables the userscript on https.
Fixed, Fixed and merged :)
If you want, you can change how much is buffered by changing the "ep_scrollTrigger=1000;" line in the script (currently it starts loading next set if you scroll anywhere within 1000px from the bottom of the page). Don't think a separate button for it would be very useful.
itsonlyaname said:
Fixed, Fixed and merged :)
If you want, you can change how much is buffered by changing the "ep_scrollTrigger=1000;" line in the script (currently it starts loading next set if you scroll anywhere within 1000px from the bottom of the page). Don't think a separate button for it would be very useful.
Thank you for response that fast!
If I may give you tip about effective Git usage: you don't have to hold back with number of commits created.
I see 3 logical changes there (fixing 2 unrelated bugs and a typo fix), and it's generally considered more elegant when each commits contains one logical change and message tells what change it was ("fix typos", "fix unlimited loading when viewing Wiki tab", "fix error messages on one-page results").
Of course it would make sense to bump version number only in the last commit in row. It's just that you can prepare more than one logical changeset (commit) before publishing (pushing) all of them at once.
It's only a suggestion for future changes though, and I hope it helps you. ;)
Yea, when working with bigger projects & multiple people, multiple commits, issues, etc are a must-have (such as the danbooru github).
For a small single-file script i just take the lazy way of coding locally and then copy/pasting new script over the old code :p I also didn't install the git program/command line thingy to crunch commits & all that other stuff.
Thanks for the tips.
itsonlyaname said:
For a small single-file script i just take the lazy way of coding locally and then copy/pasting new script over the old code :p I also didn't install the git program/command line thingy to crunch commits & all that other stuff.
Oh man, that hurts... Working with Git repo without Git...
Of course it's your project and your repo, but IMHO you're really missing out.
I really find it useful even when working on single-file scripts of few hundred lines.
Just the possibility of actually not committing some changes while committing others makes coding easier.
Committing something as soon as it works and simply resetting to that state when something later breaks makes coding easier (and you can also amend last commit).
Seeing the diff anytime you want makes coding easier.
Of course you can do most of that basic stuff with just copying files around and diffing them... But Git does that automatically so there's no need to manually making copy of last working version "just in cause I'll mess this up". It makes development less chaotic.