[X] My Assistant

So I don't know if I understand this completely. Right now, what has the biggest jump forward in the index, using the range indicator or the "jump" button? How much does "jump" jump in comparison to it?

Not sure if I understand the question, but the range indicator jumps are relative to the full result; there are 50 pips, so clicking the 25th pip would be roughly equivalent to going to page 25 in a 50-page result in the old search engine.

The jump button on the other hand works by time, either with an absolute date or relative (+/- days/weeks/months/years) from the currently displayed page.

Thank you for your hard work Tenboro (IMG:[invalid] style_emoticons/default/smile.gif)

thanks , i like the update now , great job

When searching some unicode characters in descriptions, it won't show "no indexable characters or too short"?
comment:"오" -> "has no indexable characters or is too short"
comment:"오역" -> nothing
comment:"오역 오탈자" -> 1 hit

This post has been edited by aklfhl: Dec 7 2022, 21:26

When searching some unicode characters in descriptions, it won't show "no indexable characters or too short"?
comment:"오" -> "has no indexable characters or is too short"
comment:"오역" -> nothing
comment:"오역 오탈자" -> 1 hit

I think I mentioned this somewhere, but it's because my code considers it indexable but the database engine does not, so it won't return any hits if it uses the index.

I think I mentioned this somewhere, but it's because my code considers it indexable but the database engine does not, so it won't return any hits if it uses the index.

Ah, I thought the "not indexable" tip was newly added to represent the database status, thanks for the clarification.

Ah, I thought the "not indexable" tip was newly added to represent the database status, thanks for the clarification.

Generally, the database engine requires three characters, while my indexing code requires three single-byte characters or two multi-byte characters. It could probably print a warning if a shorter word was passed to an indexed lookup, but it shouldn't error out in general since it works with non-indexed comment lookups, like say when using group:"manguri cannon$" comment:"오역"

After reading the previous posts about the functionality changes and why the page selector went away, thank you for adding this comparable feature back in, it's pretty helpful.

Any chance that the "expunged galleries" option can be changed back to be additive to the search rather than exclusively searched? So, showing all regular search results and the expunged galleries rather than just the expunged galleries.

This post has been edited by toogoo111: Dec 8 2022, 18:24

Any chance that the "expunged galleries" option can be changed back to be additive to the search rather than exclusively searched? So, showing all regular search results and the expunged galleries rather than just the expunged galleries.

I haven't found a way to do it without significant performance degradation, so it's probably rather unlikely, at least for now.

I haven't found a way to do it without significant performance degradation, so it's probably rather unlikely, at least for now.

I see, thank you.

There was also an option previously for showing galleries with low powered/downvoted tags, is that on by default now?

I see, thank you.

There was also an option previously for showing galleries with low powered/downvoted tags, is that on by default now?

You type weak:"tag name" now instead. Allows you to mix it in with other searches if you wish but similarly with the ability to view expunged galleries it does not allow you to search for the full power version of the tag at the same time.

This post has been edited by nasu: Dec 9 2022, 00:40

Seems like a lot of work just to screw bots over at little.

This post has been edited by b51de: Dec 9 2022, 01:35

Is not the best but is something after the last fix.

I love the new little "page indicator" nubs!

The range indicator is only available for normal searches; that is, not for favorites, watched tags, or in gid/file searches. Favorites will be revisited at a later date, as part of a larger rework of the favorite system.

Any details about large rework? The range indicator would be useful in favorites, to me that's where it's most useful.

Any details about large rework? The range indicator would be useful in favorites, to me that's where it's most useful.

It's mostly an internal rework for better performance, but there will probably be some UI work as well to get rid of the popup window. Will probably happen some time in 2023 unless more important things come up.

The range indicator will let you see roughly where you are in a search result and how much of it is found on the current page

The CSS for the Range Indicator doesn't work on old legacy Firefox (45.9 ESR).

it complains about these lines:

CODE

#rangebar div{height:10px;width:10px;background:#5C0D113D;border-radius:50%}
#rangebar div[data-inrange]{background:radial-gradient(#5C0D11B0,#5C0D1196)}

CODE

09:35:14.406 Expected color but found '#\35 C0D113D'.  Error in parsing value for 'background'.  Declaration dropped.1 g.css:100:48
09:35:14.406 Expected color but found '#\35 C0D11B0'.  Error in parsing value for 'background'.  Declaration dropped.1 g.css:101:55

It would seem old legacy browsers may not support RGBA colors as HEX.

Changing it to the following should be more compatible:

CODE

#rangebar div{height:10px;width:10px;background:rgba(92, 13, 17, 0.3);border-radius:50%}
#rangebar div[data-inrange]{background:radial-gradient(rgba(92, 13, 17, 0.69),rgba(92, 13, 17, 0.59))}

The CSS for the Range Indicator doesn't work on old legacy Firefox (45.9 ESR).

The site cannot support old browsers. You will need to update if you have a problem. You cannot keep using the same old browser forever.

Hey, just wanted a quick heads up about this past question & answer:

favnote searches in Favorites do not seem to support "_" characters. If my favnote is purple_hair and I type favnote:purple_hair or favnote:"purple_hair", it doesn't seem to find anything.

Is that expected behavior, or is it something that can be fixed/has a workaround?

That's basically the same issue we had with some usernames, and it should basically have the same fix. I'll look into it.

Is there a chance this gets fixed anytime soon?
I'm currently massively editing my favorite notes, so I could probably use "-" over "_" from now on.
It would still be a significant bother to edit "_" to "-" on all my past favorite notes, so I'd rather not do it if this is planned to get fixed soon.







About another question I asked earlier:

Is there any way to combine multiple OR statements? For example, (catgirl OR bunnygirl) AND (ninja OR policewoman)?
So there is at least one of the first two tags, and one of the last 2 tags.

The engine could probably support doing that, but the parsing would be more complicated. Not sure if it ever will, but I guess I can put it on the maybe list.

Considering the answer, I assume this feature will not be released anytime soon (like in the next year), if ever at all. Is that correct?
I just wanted a confirmation as this feature would have significant value to me.


Thanks a lot!

This post has been edited by Nashette: Dec 13 2022, 17:58

Considering the answer, I assume this feature will not be released anytime soon (like in the next year), if ever at all. Is that correct?
I just wanted a confirmation as this feature would have significant value to me.

That is correct. The to do list is already huge, so a "maybe" is not something you can wait for. Also, I will have to remind you that whether something is important to one user will not affect site development, so you may not get the feature you need the most.