emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Improve `replace-regexp-in-string' ergonomics?


From: Lars Ingebrigtsen
Subject: Re: Improve `replace-regexp-in-string' ergonomics?
Date: Wed, 22 Sep 2021 22:18:37 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Dmitry Gutov <dgutov@yandex.ru> writes:

> This way makes it impossible to use any optional arguments, right?

Indeed.

> But if we target thread-first instead and make the new function accept
> STRING in the first position, all optional arguments would be still
> available.

Yes, I've always found it weird that these functions have the object to
be worked upon as the last non-optional parameter.  I had to look it up
for years when using `replace-regexp-in-string'.  And it didn't help
that Emacs took this function from XEmacs, which had the string in a
different position...  But I don't remember where...

*Lars says "apt install xemacs21"*

I misremembered:

`replace-in-string' is a compiled Lisp function 
  -- loaded from "/build/xemacs21-rcHAYB/xemacs21-21.4.24/lisp/subr.elc" 
(replace-in-string STR REGEXP NEWTEXT &optional LITERAL) 

So it has the placement of STRING that seems logical, I think.

On the other hand, changing the placement in a new function like this
will probably be even more confusing.

>>              (regexp-replace "'" "\""
>>                              ",[[:space:]]" " "
>>                              "\\]" ")"
>>                              "\\[" "("
>>                              results)))
>> Or some variation thereupon with some more ()s to group pairs.
>
> I'm not sure how to also make it accept "normal" convention, and we
> probably don't want to always have to wrap the args in an alist, even
> when only one replacement is needed.

No, that's the problem.  We could hack it up by doing a &rest in
reality, and then checking if the first parameter is a list, but yuck.

>>      (setq author (regexp-remove "[ \t]*[(<].*$" author))
>>      (setq author (regexp-remove "\\`[ \t]+" author))
>>      (setq author (regexp-remove "[ \t]+$" author))
>>      (setq author (regexp-replace "[ \t]+" " " author))
>
> IDK, if that leads to no increase in efficiency, then probably not?
> Replacing with "" is an established pattern by now.

It helps with readability -- the function says what the intention is.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



reply via email to

[Prev in Thread] Current Thread [Next in Thread]