Re: [BUG] Re: 98e168b48 Add compatibility wrapper for string-clean-whitespace (Emacs 26 compatibility) [9.6-pre (release_9.5.5-920-g057193 @ /home/yantar92/.emacs.d/straight/build/org/)]

2022-10-08 Thread Ihor Radchenko
Kyle Meyer  writes:

> I've pushed 04d9d4b3d, but please feel free to adjust as needed if some
> other reason to avoid loading subr-x surfaces.

Thanks! I see no reason to avoid subr-x.

Also, leaving the patch link for easy reference in future
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=04d9d4b3db84e0025e21e9248bc2d218cd3c0e9b

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 



Re: [BUG] Re: 98e168b48 Add compatibility wrapper for string-clean-whitespace (Emacs 26 compatibility) [9.6-pre (release_9.5.5-920-g057193 @ /home/yantar92/.emacs.d/straight/build/org/)]

2022-10-07 Thread Kyle Meyer
Ihor Radchenko writes:

> I do recall Nicolas repeatedly voicing against usage of subr-x staff:
>
> https://orgmode.org/list/87wo4en8qk@nicolasgoaziou.fr
   2. we don't use "subr-x.el" in the code base. In particular, it 
 would be
  nice to replace `when-let' with `when' + `let'. This change costs
  only one loc.
>
> However, he did not mention the reasoning behind this, except a single
> massage I was able to find:
>
> https://orgmode.org/list/8737t0b2c9@nicolasgoaziou.fr
  ... you are not using `if-let' anywhere if this patch. Besides, we still
  cannot use subr-x, since it is a 24.4 library, and, AFAIR, we didn't
  drop support for 24.3 yet.
>
> If supporting Emacs 24 is the only blocker for subr-x, it should be safe
> to use it.

Right, as far as I understand, support for Emacs 24.3 was the main
reason to avoid it; subr-x.el wasn't added until Emacs 24.4, when it was
renamed from helpers.el.  (There may be the general stylistic question
of whether to use when-let{,*} and friends, but that's not relevant in
this context.)

I've pushed 04d9d4b3d, but please feel free to adjust as needed if some
other reason to avoid loading subr-x surfaces.



Re: [BUG] Re: 98e168b48 Add compatibility wrapper for string-clean-whitespace (Emacs 26 compatibility) [9.6-pre (release_9.5.5-920-g057193 @ /home/yantar92/.emacs.d/straight/build/org/)]

2022-10-07 Thread Ihor Radchenko
Kyle Meyer  writes:

>> It is available in Emacs-26, however (require 'subr-x) should be added.
>>
>> There is `org-trim' and despite it is less generic, likely it can be
>> used if subr-x is avoided for some reason.
>
> Ihor, sorry for overlooking that.  As Max mentions, indeed string-trim
> used to be in subr-x.  It's been available since Emacs 24 and was
> relocated with Emacs 28's a4ececf004e (Move string-trim functions to
> subr.el, 2021-03-24).
>
> I won't be at my computer much today or tomorrow, but, when I get a
> chance, I'll plan to add something like
>
>   (eval-when-compile (require 'subr-x))  ; Emacs < 28

I am a bit confused about usage of subr-x in Org.

I do recall Nicolas repeatedly voicing against usage of subr-x staff:

https://orgmode.org/list/87wo4en8qk@nicolasgoaziou.fr
>>>   2. we don't use "subr-x.el" in the code base. In particular, it would 
>>> be
>>>   nice to replace `when-let' with `when' + `let'. This change costs
>>>   only one loc.

However, he did not mention the reasoning behind this, except a single
massage I was able to find:

https://orgmode.org/list/8737t0b2c9@nicolasgoaziou.fr
>>>  ... you are not using `if-let' anywhere if this patch. Besides, we still
>>>  cannot use subr-x, since it is a 24.4 library, and, AFAIR, we didn't
>>>  drop support for 24.3 yet.

If supporting Emacs 24 is the only blocker for subr-x, it should be safe
to use it.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 



Re: [BUG] Re: 98e168b48 Add compatibility wrapper for string-clean-whitespace (Emacs 26 compatibility) [9.6-pre (release_9.5.5-920-g057193 @ /home/yantar92/.emacs.d/straight/build/org/)]

2022-10-07 Thread Kyle Meyer
Max Nikulin writes:

> On 07/10/2022 12:14, Ihor Radchenko wrote:
>> 
>> The following commit adds `string-trim', which is not yet available in
>> Emacs 26.
>
> It is available in Emacs-26, however (require 'subr-x) should be added.
>
> There is `org-trim' and despite it is less generic, likely it can be
> used if subr-x is avoided for some reason.

Ihor, sorry for overlooking that.  As Max mentions, indeed string-trim
used to be in subr-x.  It's been available since Emacs 24 and was
relocated with Emacs 28's a4ececf004e (Move string-trim functions to
subr.el, 2021-03-24).

I won't be at my computer much today or tomorrow, but, when I get a
chance, I'll plan to add something like

  (eval-when-compile (require 'subr-x))  ; Emacs < 28

And of course please feel free to beat me to it and fix it however you
see fit.  Thanks.



Re: [BUG] Re: 98e168b48 Add compatibility wrapper for string-clean-whitespace (Emacs 26 compatibility) [9.6-pre (release_9.5.5-920-g057193 @ /home/yantar92/.emacs.d/straight/build/org/)]

2022-10-07 Thread Max Nikulin

On 07/10/2022 12:14, Ihor Radchenko wrote:


The following commit adds `string-trim', which is not yet available in
Emacs 26.


It is available in Emacs-26, however (require 'subr-x) should be added.

There is `org-trim' and despite it is less generic, likely it can be 
used if subr-x is avoided for some reason.




[BUG] Re: 98e168b48 Add compatibility wrapper for string-clean-whitespace (Emacs 26 compatibility) [9.6-pre (release_9.5.5-920-g057193 @ /home/yantar92/.emacs.d/straight/build/org/)]

2022-10-06 Thread Ihor Radchenko
Kyle,

The following commit adds `string-trim', which is not yet available in
Emacs 26.

98e168b489e4350430d1600f7ece57215de1027c
Author: Kyle Meyer 
AuthorDate: Tue Oct 4 17:42:27 2022 -0400
Commit: Kyle Meyer 
CommitDate: Tue Oct 4 18:38:25 2022 -0400
compat: Add compatibility wrapper for string-clean-whitespace
* lisp/org-compat.el (org-string-clean-whitespace): New compatibility
function.
* lisp/ox.el (org-export-resolve-radio-link): Use
org-string-clean-whitespace.

This is a follow-up to the port of Emacs's 70341cab3.

Best,
Ihor