On 25/11/2021 19:11, Ihor Radchenko wrote:
Maxim Nikulin writes:
I think, new variant should be committed even it does not fix Juan's
case. He have not confirmed the fix yet.
The patch does apply onto main, but I have a comment.
+ ;; Emphasis of second word.
+ ;; Locales with
Maxim Nikulin writes:
> I think, new variant should be committed even it does not fix Juan's
> case. He have not confirmed the fix yet.
The patch does apply onto main, but I have a comment.
> + ;; Emphasis of second word.
> + ;; Locales with significant spaces (C, es_ES, pl_PL)
I
Hi Nicolas,
Nicolas Goaziou writes:
>> Is this okay to install this in the maint branch?
>
> I didn't test it, but it seems to fix the issues reported. So I guess
> this is fine.
Done, thanks!
--
Bastien
Hello,
Bastien writes:
> Hi Nicolas,
>
> Nicolas Goaziou writes:
>
>> Ah! I forgot the link part! Hopefully done here.
>>
>> (defun org-sort-remove-invisible (s)
>> "Remove emphasis markers and any invisible property from string S.
>> Assume S may contain only objects."
>> ;;
Maxim Nikulin writes:
> Bastien, the following message in this thread contains alternative
> draft from Nicolas:
> https://orgmode.org/list/87a6pt9hyd@nicolasgoaziou.fr/
>
> It is better than initial patches from Juan Manuel. It fixes the
> problem with removing characters around emphasized
Hi Nicolas,
Nicolas Goaziou writes:
> Ah! I forgot the link part! Hopefully done here.
>
> (defun org-sort-remove-invisible (s)
> "Remove emphasis markers and any invisible property from string S.
> Assume S may contain only objects."
> ;; org-element-interpret-data clears any text
On 15/05/2021 20:32, Bastien wrote:
Bastien writes:
Bastien writes:
Thanks for the heads-up. I reverted the commit. Please go ahead with
whatever you see fit.
PS: Re-opening this work-in-progress patch for updates.orgmode.org.
I'm closing this now -- Juan, feel free to resubmit a
Bastien writes:
> Bastien writes:
>
>> Thanks for the heads-up. I reverted the commit. Please go ahead with
>> whatever you see fit.
>
> PS: Re-opening this work-in-progress patch for updates.orgmode.org.
I'm closing this now -- Juan, feel free to resubmit a patch if you
are still working on
Bastien writes:
> Thanks for the heads-up. I reverted the commit. Please go ahead with
> whatever you see fit.
PS: Re-opening this work-in-progress patch for updates.orgmode.org.
--
Bastien
Nicolas Goaziou writes:
> Unfortunately, this is not a proper fix for the problem, as discussed in
> the thread.
Thanks for the heads-up. I reverted the commit. Please go ahead with
whatever you see fit.
--
Bastien
Hello,
Bastien writes:
> Juan Manuel Macías writes:
>
>> 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...
>
> applied in the maint branch as commit 5be650714.
Unfortunately, this is not a proper fix for the
Hi Juan,
Juan Manuel Macías writes:
> 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...
applied in the maint branch as commit 5be650714.
The patch was missing a proper changelog entry: please see
On 21/04/2021 22:45, Juan Manuel Macías wrote:
I have tried the Nicolas' patch (latest version) and I see that the
items with emphasis are already ordered well. However, it seems that the
problem with identical items with or without emphasis still persists:
which items should go before and in
Hi all,
Maxim Nikulin writes:
> I think, new variant should be committed even it does not fix Juan's
> case. He have not confirmed the fix yet.
Sorry, I have been busy with other matters and had lost the thread of
the discussion. I'm catching up on the messages...
I have tried the Nicolas'
On 21/04/2021 03:37, Nicolas Goaziou wrote:
Maxim Nikulin writes:
(let ((s (org-sort-remove-invisible
"A wrapping [[https://orgmode.org?a=b=d#e][link]] emphasis/"
I expect "A wrapping link emphasis".
Yet, your expectations are wrong. There is no link in the text above.
Emphasized text
Hello,
Maxim Nikulin writes:
> Surprisingly there are still cases when the old approach works better:
>
> (let ((s (org-sort-remove-invisible
> "A /wrapping [[https://orgmode.org/?a=b=d#e][link]] emphasis/")))
> (set-text-properties 0 (length s) nil s)
> s)
> "A wrapping
On 20/04/2021 20:57, Nicolas Goaziou wrote:
Maxim Nikulin writes:
(org-sort-remove-invisible "A")
#("A" 0 1 (:parent (#("A" 0 1 ...
This is a string.
Thank you, from second attempt I have managed to strip text properties.
Since the intended usage of return value is sorting key, would
Hello,
Maxim Nikulin writes:
> Maybe first variant deserves to be committed while discussion of a
> better option is in progress.
I'd rather not, since we're currently considering a somewhat different
path. The problem has been there for ages anyway.
> I can not even determine what type of
On 20/04/2021 00:50, Nicolas Goaziou wrote:
Maxim Nikulin writes:
On 19/04/2021 23:08, Nicolas Goaziou wrote:
+ ;; Space role in sorting.
+ ;; Test would fail for locales with ignored space, e.g. en_US, it works
+ ;; in C and currently rare locales having significant space
Hi,
On 19/04/2021 23:08, Nicolas Goaziou wrote:
In my opinion, a more severe limitation comes from sequential
regexp-based approach. Consider stripping markers from
1. "a =b *c* d= e"
2. "*b* /i/"
Fair enough. Here comes another, more involved, attempt.
Maybe first variant deserves to be
Tom, thanks! i assumed something like that.
Maxim Nikulin writes:
> On 19/04/2021 23:08, Nicolas Goaziou wrote:
>>> + ;; Space role in sorting.
>>> + ;; Test would fail for locales with ignored space, e.g. en_US, it
>>> works
>>> + ;; in C and currently rare locales having significant space (es_ES,
>>> pl_PL)
>>> +
On 19/04/2021 23:08, Nicolas Goaziou wrote:
+ ;; Space role in sorting.
+ ;; Test would fail for locales with ignored space, e.g. en_US, it works
+ ;; in C and currently rare locales having significant space (es_ES,
pl_PL)
+ (should
+ (equal "- Time stamp\n- Timer\n"
+
Hi Greg,
seq cannot be used because it is not available in older versions
of emacs that org still supports. When support for those older
versions is dropped then seq could be used. Best,
Tom
hi, Nicolas,
i'm curious, not knowing history and/or procedures.
> ... CL is still necessary however, as we cannot use `seq' yet.
why is 'seq not "yet" available? what will make it available?
cheers, Greg
Hello,
Maxim Nikulin writes:
> Just a curiosity, what is style guide recommendation: let - lambda or
> cl-labels?
I stay away from CL as much as possible, otherwise newcomers will have
to learn two languages to start contributing, Elisp and CL (cl-loop,
ewww). CL is still necessary however, as
On 19/04/2021 15:33, Nicolas Goaziou wrote:
Could you try the following instead?
--8<---cut here---start->8---
(defun org-sort-remove-invisible (s)
"Remove invisible part of links and emphasis markers from string S."
(let ((remove-markers
Hello,
Juan Manuel Macías writes:
> I wonder if this other approach can be viable or if it is something
> crazy: if the spaces in org-sort-remove-invisible are a
> problem only for the first emphasis of each item, how about this
> fix to org-sort-list? (not modifying org-sort-remove-invisible):
Juan Manuel Macías writes:
> 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
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
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
On 16/04/2021 21:59, Maxim Nikulin wrote:
Ukrainian sort works better than Russian one with such example:
printf "Иванова Алла\nИванов Адам\nИванова Светлана\n" \
| LANG=uk_UA.UTF-8 sort
Иванов Адам
Иванова Алла
Иванова Светлана
printf "Иванова Алла\nИванов Адам\nИванова Светлана\n" \
|
Hi Juan,
On 16/04/2021 01:21, you wrote:
#+begin_src emacs-lisp :tangle list-var.el
(message "%S" (sort '("-\s\sv" "-\sv" "-\sa" "-\s\sa")
#'string-collate-lessp))
#+end_src
#+begin_src sh
exec 2>&1
LC_ALL=en_US.UTF-8 emacs --batch -Q -l list-var.el
#+end_src
Hi Maxim
Maxim Nikulin writes:
> I can reproduce the issue with emacs-27.1 from ubuntu-21.04 beta live
> image running in qemu. Org mode is current git HEAD. It seems that
> something is changed in emacs since locale is correct:
>
> ubuntu@ubuntu:~$ printf '%s- v\n- /v/\n- a\n- /a/\n' '' \
>
I can reproduce the issue with emacs-27.1 from ubuntu-21.04 beta live
image running in qemu. Org mode is current git HEAD. It seems that
something is changed in emacs since locale is correct:
ubuntu@ubuntu:~$ printf '%s- v\n- /v/\n- a\n- /a/\n' '' \
| LANG=C.UTF-8 sort
- /a/
- /v/
- a
- v
Hello again,
Since I have an old Emacs version (24.5.1) on my Raspberry, I've done
a few more tests. The situation is the following:
1. On Arch Linux and Emacs 27.2:
- The system locales are set to "es_ES.UTF-8". When, inside Emacs, I do M-x
getenv RET LANG RET, I get "es_ES.UTF-8".
Hi Maxim,
Thanks again. In my case, I keep getting the wrong result. In addition
to the test I did in a virtual machine with Fedora, I use Arch Linux in
my every day computers, with locales correctly (I hope) configured as
es_ES.UTF-8 (there was a typo in my previous mail, sorry:
'en_ES.UTF-8').
On 14/04/2021 22:42, Maxim Nikulin wrote:
I have generated es_ES.UTF-8 locale using
dpkg-reconfigure locales
Depending on linux distribution you run, the locale may be ready to use
or not. I tend to think that in minimal environment of virtual machine
it was missed.
I forgot to add a
On 14/04/2021 02:08, Juan Manuel Macías wrote:
The situation is that with locales configured for Spanish from Spain
(en_ES.UTF-8) the list is not ordered correctly, unless those three
spaces from org-sort-remove-invisible are removed. But I couldn't say
why or if that would be appropriate as a
Hi, Maxim,
Thanks for clearing things up. So it seems obvious that the root
of the problem is in the locales and the collation rules.
The situation is that with locales configured for Spanish from Spain
(en_ES.UTF-8) the list is not ordered correctly, unless those three
spaces from
On 10/04/2021 18:41, Juan Manuel Macías wrote:
Nicolas Goaziou writes:
Do you have a simple test case to reproduce the problem? Currently
sorting the following trivial lists causes no issue:
- b
- *a*
and
- *b*
- a
The current result is wrong:
- /a/
- /v/
- a
- b
I
Hi Samuel,
Samuel Wales writes:
> probably not a relevant non-confirmation but in recent maint, my config:
>
> - a
> - /a/
> - b
Thanks for trying. I've uploaded this screencast with a minimal Emacs on
a virtual machine:
probably not a relevant non-confirmation but in recent maint, my config:
- a
- /a/
- b
On 4/12/21, Juan Manuel Macías wrote:
> Hi Ypo,
>
> Ypo writes:
>
>> This is my result after doing "org-sort-list a":
>>
>> - /a/
>> - /v/
>> - a
>> - b
>>
>> Regards
>
> Thanks for trying. So it
Hi Ypo,
Ypo writes:
> This is my result after doing "org-sort-list a":
>
> - /a/
> - /v/
> - a
> - b
>
> Regards
Thanks for trying. So it seems that you can reproduce the problem as
well... I wonder if anyone else is able to reproduce it, preferably in a
minimal emacs.
Best regards,
This is my result after doing "org-sort-list a":
- /a/
- /v/
- a
- b
Regards
Nicolas Goaziou writes:
> I cannot reproduce it. With your initial list, and a minimal init file,
> I get:
>
> - /a/
> - a
> - b
> - /v/
>
> Could you try with a minimal Emacs, too?
That's weird ... I have tried launching emacs -q in a virtual machine,
and I keep getting the wrong result
Hello Nicolas,
Nicolas Goaziou writes:
> Do you have a simple test case to reproduce the problem? Currently
> sorting the following trivial lists causes no issue:
>
> - b
> - *a*
>
> and
>
> - *b*
> - a
Consider this (unordered) list:
- a
- b
- /v/
- /a/
The current result is
Hello,
Juan Manuel Macías writes:
> 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...
No problem. Thank you.
Do you have a simple test case to reproduce the problem? Currently
sorting the following trivial lists
Hellow Nicolas:
Nicolas Goaziou writes:
> Thank you.
>
> 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
Hello,
Juan Manuel Macías writes:
> I have noticed that a couple of (spurious?) spaces in a `format'
> expression of `org-sort-remove-invisible' is causing `org-sort-list' not
> to sort correctly (alphabetically) the items that contain emphasis marks
> in a plain list. I propose this very
Hi all,
I have noticed that a couple of (spurious?) spaces in a `format'
expression of `org-sort-remove-invisible' is causing `org-sort-list' not
to sort correctly (alphabetically) the items that contain emphasis marks
in a plain list. I propose this very simple patch to fix that problem.
Best
51 matches
Mail list logo
