Hi Maxim, Maxim Nikulin writes:
> On 10/04/2021 07:01, Juan Manuel Macías wrote: >> Nicolas Goaziou writes: >>> Could you apply the same fix to the `org-verbatim-re' match above, and >>> provide an appropriate commit message? >> Done! I've attached the corrected patch. Sorry for the flaws in me >> previous patch: I'm a bit of a novice at submitting patches... > > I have not read yet the following documents to realize what pitfalls > could be expected due to significant space added to Spanish and Polish > collation rules in libc. > > http://www.unicode.org/reports/tr10/ > Unicode® Technical Standard #10 > Unicode Collation Algorithm > > http://www.unicode.org/reports/tr35/tr35-collation.html#CLDR_Collation_Algorithm > Unicode Technical Standard #35 > Unicode Locale Data Markup Language (LDML) > Part 5: Collation > > In the meanwhile I have realized that org-sort-remove-invisible > function has rather strange behavior. There are no tests, so I am in > doubt if the following result is expected and intended (unpatched > version) All this research you've done on spaces and collation rules is very interesting and enlightening. Certainly, space is important, as the following list in Spanish is correctly ordered as: - lo raro - lo vano - localidad However, with the 'unpatched' version of org-sort-remove invisible I get this result (which is correct) for this list: - lo bueno - lo /bueno/ - lo vano - lo /vano/ And with the patched version, I get this, which is wrong (!): - lo bueno - lo vano - lo /bueno/ - lo /vano/ It seems that what I was proposing as a patch at the beginning is not, finally, a viable solution for all contexts... The problem is that, if the first space is removed, we get this abnormal result: #+begin_src emacs-lisp (org-sort-remove-invisible "- lo /bueno/") #+end_src #+RESULTS: : - lobueno Best regards, Juan Manuel
