Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Potential refinements to tags searching feature.

Aperta
  • Qualcosa non va?
#2,268 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
28/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Tranquilla
Stack tecnologico
python
Ambito
desktop, frontend

Direzione di ricerca

L'issue non indica file, test o punti di ingresso. Innanzitutto individua le implementazioni esistenti di RimSort per la ricerca tramite filtro dei tag e per la ricerca testuale dei tag, quindi chiarisci se debbano essere unificate o se una delle due debba essere rimossa. Il lavoro è completato quando rimane un unico approccio chiaramente scelto per la ricerca dei tag, con comportamento coerente e senza funzionalità ridondanti.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

feature/improvement 🆕
Origin of idea

Currently, RimSort provides a robust tags filtering feature that supports both AND and OR search. I will refer this feature as filter search.

Then, RimSort also has a "tags" type search that allows user to search tags by typing. I will refer this feature as text search

Image

In my opinion, one of them should be deprecated and removed.

  • They were duplicated because they serve the same purpose (to search mods by tags).
  • It does not make sense to keep both when they serve the same purpose.

I see this as an opportunity to remove/merge similar features.
Besides, having two tag search functionalities of different mechanism can confuse users in several ways such as "which is better?", "which should I use?", "why they work differently?", etc. It also burdens contributors, managing one module is always better than two.

Suggestion/proposed solution?

Note that, I have never viewed the source code of RimSort. I do not know how RimSort handles these two features (such as, whether they use a common interface or different implementations).
I assume they are using different implementations as I don't find a way to match multiple tags via text search.

Here I provide suggestions of two options to keep both text/filter search or keep only one of them and remove the other one.

Keep both feature

If both are to be kept, then they should perform in similar way and gives equivalent output. The benefit of this is allow user to have more controls over their preferred styles of searching tags. But, it adds complexity and burden to the contributors.

For example, text search should implement what filter search supports, such as:

  • matching tags via "Any" mode.
  • matching tags via "All" mode.

Another option is to refine text search further so it provides more robust tags matching functionality, but that shadows the necessity of filter search. Refer to Text search refinements below.

Keep only one of them, then remove the other one

There are two choices depends on the contributors' outlook about RimSort.

  1. Keep filter search & remove text search.
  2. Keep text search & remove filter search.

Option (1) should be direct and easier, simply removes all codes and references to the text search module.

If filter search is to be removed, then RimSort should refine the text search further before removing filter search. Refer to Text search refinements below.

Text search refinements

One refinement I could think of is to change text search to evaluate input string as a logical expression. This allows to parse complex expressions with mixed operators.
An example would be matching mods by tagA & tagB | tagC (tagA AND tagB OR tagC). This would output all mods with tagA and tagB + all mods with tagC. It is useful in scenarios where user want to find mods with different categories of tags e.g., vanilla-expanded AND outpost OR qol to find all Vanilla Outposts Expanded mods and QoL mods.

An optional brackets support could be provided to change precedence of conditions e.g., tagA & (tagB | tagC) to produce an equivalent condition of tagB | tag C & tagA. Though, I never encounter any situation to use such condition. I think it adds more complexity than benefits to the software.

Note that, I refer ampersand ('&') as AND operator and pipe (|) as OR operator because I am used to them. Other users will have different preferences about the syntax and operators.

Personally, I prefer text search as I prefer keyboard controls over mouse clicks.
Besides, I can always see all tags that I am searching for when using text search. With filter search, I have to open the tab to see what I am filtering, not to mention that it becomes harder to track selected tags with more tags added to the software.

Alternatives considered

Equivalent output of tagA & tagB | tagC can be achieved in filter search with few more clicks:

  1. Filter by "All" mode, select tagA, tagB, record output.
  2. Clear selections, filter by "Any" mode, select tagC, record output.
Additional context

No response

Code of Conduct

I agree to follow this project's Code of Conduct

Duplicate Issue Check

I've checked for similar issues and didn't find anything

Wiki/FAQ Check

I've checked the Wiki for a solution and didn't find a solution

Lingua principale
Python
Stelle
1.2k
Fork
155
Merge medio
7h 23m
PR unite (30g)
62

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di RimSort/RimSort

Tutte le issue di RimSort/RimSort

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.