Merge lp://staging/~jeremy-munsch/synapse-project/ascii-smart into lp://staging/synapse-project

Proposed by Jeremy Munsch
Status: Needs review
Proposed branch: lp://staging/~jeremy-munsch/synapse-project/ascii-smart
Merge into: lp://staging/synapse-project
Diff against target: 190 lines (+145/-3)
2 files modified
src/core/query.vala (+3/-3)
src/core/utils.vala (+142/-0)
To merge this branch: bzr merge lp://staging/~jeremy-munsch/synapse-project/ascii-smart
Reviewer Review Type Date Requested Status
Rico Tzschichholz Needs Information
Review via email: mp+277477@code.staging.launchpad.net

Description of the change

Ignore non ascii chars like éè and so long.
This allows to search word with non ascii chars and match both.
The reverse is also true, searching with non ascii chars will match same word with ascii chars.

eg: searching for Éteindre (Shutdown action) i could just type eteindre, éteindre will still work though.

This will basically provide more matches by sort of ignoring special chars. It makes synapse smarter and have a faster usage will typing. It is extendible by using just a string for hardcoded config.

It is based on this link http://stackoverflow.com/a/16427125

To post a comment you must log in.
Revision history for this message
Jeremy Munsch (jeremy-munsch) wrote :

Updated the branch and commit message following recommendations

Revision history for this message
Rico Tzschichholz (ricotz) wrote :

Looks pretty bold and changes the internal behavior quite a lot.

There are for sure some avoidable performances issue, like useless string-copying.
(Better usage of const, unowned strings and GLib.HashTables)

What I am most curious about is the "reverse" stuff.
If the user explicitly searches for it should there be not-closely-matching results?
Should "additional" results be weighted lower?

review: Needs Information
Revision history for this message
Jeremy Munsch (jeremy-munsch) wrote :

> What I am most curious about is the "reverse" stuff.
> If the user explicitly searches for it should there be not-closely-matching
> results?
> Should "additional" results be weighted lower?

You're making a really good point here. I must agree using non ascii char is a value added to query information. In this case yes, the additional results might be weighted lower.

I'll make some changes.

Revision history for this message
Jeremy Munsch (jeremy-munsch) wrote :

Updated this, I have drop reverse search as this would be too much complicated to handle, i think this PR wins more by staying as simple as possible.

I tried to write things with performance in minds (though with my skills ><).

It also handles multiple replacement (eg: ss => ß :p )

Revision history for this message
Jeremy Munsch (jeremy-munsch) wrote :

* fixed non special chars not outputing
* fixed string copy by using string builder
* fixed double and tripple matching to ignore upper letters, Ss,sS,SS,ss => ß

* added some special upper chars, and removed them from lower to honor Caseless regex rule
this is. Allthough double and tripple matching remains caseless as it would
be too much complicated to handle for the program and the user.
http://stackoverflow.com/questions/3371697/replacing-accented-characters-php/33856250#33856250

Revision history for this message
Jeremy Munsch (jeremy-munsch) wrote :

I also not if this is merge desktop files plugin would have to be updated to remove usage Utils.remove_accents as it will become useless.

Revision history for this message
Rico Tzschichholz (ricotz) wrote :

Define the strings in a const-array, use a GLib.HashTable and fill it in a loop.

Rebase on trunk.

review: Needs Fixing
Revision history for this message
Jeremy Munsch (jeremy-munsch) wrote :

Just did that.

Revision history for this message
Rico Tzschichholz (ricotz) wrote :

why are you constantly introducing other changes?

review: Needs Information
Revision history for this message
Jeremy Munsch (jeremy-munsch) wrote :

corrected:

* usage of multi dim array with unowned strings
* renamed var starting with '_'
* added space to have better formatting of equations (with numeric operators)

Unmerged revisions

637. By Jeremy Munsch

core/utils: add map_special_chars
core/ query: make usage of Utils.map_special_chars

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
The diff is not available at this time. You can reload the page or download it.