Re: [PATCH] Use replace-match in posting-style.

Re: [PATCH] Use replace-match in posting-style.

[Ted Zlatanov]

On Wed, 23 Jun 2010 23:02:16 +0200 Daniel Dehennin <daniel.dehennin@baby-gnu.org> wrote: 

DD> Daniel Dehennin <daniel.dehennin@baby-gnu.org> writes:
>> Ok, looking in elisp manual, I saw nothing to expand positional
>> parameters in a string.
>> 
>> I first saw this functionality in nnmail-split-fancy, so I look in the
>> code a find the nnmail-expand-newtext in nnmail.el.
>> 
>> I adapt it to my needs, I think such function should be "mainstream".
>> 
>> What do you thing about this:
>> 
>> ;; I need the matched string because I found no way to get it from
>> ;; (match-data)
>> (defun my-expand (string matched &optional lowercase)
>> "Replace positional parameters with the text matched by groups in the
>> <matched> string.
>> If the optional lowercase parameter is set, the matched text by groups
>> is forced to lowercase."

DD> No feedback about this features?

It worries me that we're inventing (yes, including the
nnmail-split-fancy usage) something that looks like but isn't at all a
real regex positional replacement.  Can we find out from emacs-devel if
this can be done better through ELisp or even C and then apply the fix
both to your code and to nnmail-split-fancy?  We'll also need to find
out if XEmacs can do something similar, since Gnus supports it as well.

I think the description you gave is probably not specific enough to give
us the best answers; can you write a more formal definition of how
my-expand should behave?

Thanks
Ted

Re: [PATCH] Use replace-match in posting-style.

[Daniel Dehennin]

[-- Attachment #1: Type: text/plain, Size: 1304 bytes --]

Ted Zlatanov <tzz@lifelogs.com> writes:

> It worries me that we're inventing (yes, including the
> nnmail-split-fancy usage) something that looks like but isn't at all a
> real regex positional replacement.  Can we find out from emacs-devel if
> this can be done better through ELisp or even C and then apply the fix
> both to your code and to nnmail-split-fancy?  We'll also need to find
> out if XEmacs can do something similar, since Gnus supports it as well.
>
> I think the description you gave is probably not specific enough to give
> us the best answers; can you write a more formal definition of how
> my-expand should behave?

Ok, I'll try:

The idea is to use the match-data informations to expand positional
parameters in any string, where replace-match only works on the one the
match occurs.

1. my-expand take a string as argument,

2. if there is no captured match then return the argument,

3. if the string does not contains positional parameters then return the
   argument,

4. build a new sting from the argument by replacing all the positional
   parameters by their captured value,

5. return the new string.

Is this what you asked ?

Regards.
-- 
Daniel Dehennin
Récupérer ma clef GPG:
gpg --keyserver pgp.mit.edu --recv-keys 0x6A2540D1

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

replace matches in any string (was: [PATCH] Use replace-match in posting-style.)

[Ted Zlatanov]

I'll try to explain more clearly since there haven't been responses.
Daniel said:

"The idea is to use the match-data informations to expand positional
parameters in any string, where replace-match only works on the one the
match occurs."

So for example, we can say:

(when (string-match
       "\\(daniel\\)"
       "daniel.dehennin@baby-gnu.org")
  (replace-match "Daniel is \\1" nil nil "daniel.dehennin@baby-gnu.org" 1))
-> "Daniel is daniel.dehennin@baby-gnu.org"

But replace-match needs to be passed the same string that matched
("daniel.dehennin@baby-gnu.org" in the example).  How can we replace \\1
and the other positional parameters in arbitrary text?  Gnus has
nnmail-expand-newtext[1] to do this and it would be great to avoid special
code to do it, or if such code can't be avoided, at least move it
outside Gnus because IMO it's generally applicable and useful.

Thanks
Ted

[1] presented without comment, as it is in the source :)

(defun nnmail-expand-newtext (newtext)
  (let ((len (length newtext))
	(pos 0)
	c expanded beg N did-expand)
    (while (< pos len)
      (setq beg pos)
      (while (and (< pos len)
		  (not (= (aref newtext pos) ?\\)))
	(setq pos (1+ pos)))
      (unless (= beg pos)
	(push (substring newtext beg pos) expanded))
      (when (< pos len)
	;; We hit a \; expand it.
	(setq did-expand t
	      pos (1+ pos)
	      c (aref newtext pos))
	(if (not (or (= c ?\&)
		     (and (>= c ?1)
			  (<= c ?9))))
	    ;; \ followed by some character we don't expand.
	    (push (char-to-string c) expanded)
	  ;; \& or \N
	  (if (= c ?\&)
	      (setq N 0)
	    (setq N (- c ?0)))
	  (when (match-beginning N)
	    (push (if nnmail-split-lowercase-expanded
		      (downcase (buffer-substring (match-beginning N)
						  (match-end N)))
		    (buffer-substring (match-beginning N) (match-end N)))
		  expanded))))
      (setq pos (1+ pos)))
    (if did-expand
	(apply 'concat (nreverse expanded))
      newtext)))

Re: replace matches in any string

[Ted Zlatanov]

On Fri, 30 Jul 2010 12:43:28 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> I'll try to explain more clearly since there haven't been responses.
TZ> Daniel said:

TZ> "The idea is to use the match-data informations to expand positional
TZ> parameters in any string, where replace-match only works on the one the
TZ> match occurs."

TZ> So for example, we can say:

TZ> (when (string-match
TZ>        "\\(daniel\\)"
TZ>        "daniel.dehennin@baby-gnu.org")
TZ>   (replace-match "Daniel is \\1" nil nil "daniel.dehennin@baby-gnu.org" 1))
TZ> -> "Daniel is daniel.dehennin@baby-gnu.org"

TZ> But replace-match needs to be passed the same string that matched
TZ> ("daniel.dehennin@baby-gnu.org" in the example).  How can we replace \\1
TZ> and the other positional parameters in arbitrary text?  Gnus has
TZ> nnmail-expand-newtext[1] to do this and it would be great to avoid special
TZ> code to do it, or if such code can't be avoided, at least move it
TZ> outside Gnus because IMO it's generally applicable and useful.

I haven't heard any comments on this.  It's blocking a Gnus feature so
I'd really like to get it done; the code is ready[1] so I simply need to
know if this functionality should be in Emacs or only in Gnus.

Ted

[1] --or we'll make Lars hack it until it's ready, you've been warned--

Re: replace matches in any string

[Stefan Monnier]

> I haven't heard any comments on this.  It's blocking a Gnus feature so
> I'd really like to get it done; the code is ready[1] so I simply need to
> know if this functionality should be in Emacs or only in Gnus.

I do not understand the feature you request.
Rather than code that supposedly implements the feature, try to post
examples of uses you'd like to see work.

I have the impression that what you want is already provided by
replace-match, tho only in the case when the match was performed on
a string rather than in a buffer.


        Stefan

Re: replace matches in any string

[Ted Zlatanov]

On Thu, 02 Sep 2010 13:29:41 +0200 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

SM> I do not understand the feature you request.
SM> Rather than code that supposedly implements the feature, try to post
SM> examples of uses you'd like to see work.

I believe the following is accurate.  Daniel, please correct me if I'm
wrong in my description.

Given:

(let ((regex "\\(alpha\\)")
      (string "gamma alpha beta"))
  (when (string-match regex string)
    (replace-match "[first greek letter \\1]" nil nil string 1)))
-> "gamma [first greek letter alpha] beta"

We want the equivalent but against any string, not just the original
string (the `replace-match' docs say STRING has to be the one used for
the original `string-match').  The use case is when you say to match X
in an e-mail address, then set the target group to "something-X-other".
We want to do it with regex "\\(X\\)" against "userX@valid.domain" and
target group "something-\\1-other".  Does that make sense?  Basically we
want \1 but without the context of that original string we matched:

(let ((regex "\\(alpha\\)")
      (string "gamma alpha beta"))
  (when (string-match regex string)
    (our-new-function "found greek letter \\1")))
-> "found greek letter alpha"

As I said, `nnmail-expand-newtext' implements this for Gnus purposes and
it can handle \[0-9] arguments and \& for the whole match but it's not
generic.  It needed to be extended for Daniel Dehennin's patch and so we
came to this.

SM> I have the impression that what you want is already provided by
SM> replace-match, tho only in the case when the match was performed on
SM> a string rather than in a buffer.

I hope so.

Ted

Re: replace matches in any string

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> We want to do it with regex "\\(X\\)" against "userX@valid.domain" and
> target group "something-\\1-other".  Does that make sense?  Basically we
> want \1 but without the context of that original string we matched:
>
> (let ((regex "\\(alpha\\)")
>       (string "gamma alpha beta"))
>   (when (string-match regex string)
>     (our-new-function "found greek letter \\1")))
> -> "found greek letter alpha"

If you look at the low-level stuff that's actually saved by
`string-match' and friends, it's basically a list of start/end points,
and that's it, I think.

(progn (string-match "\\(alpha\\)" "gamma alpha beta")
       (match-data))
=> (6 11 6 11)

So when you say `(match-string 1)', it just uses the range 6-11 and does
a buffer-substring on that, or, if you give the latter function a string
parameter, then a substring on that.

So, for reasons of efficiency (I'm guessing), the actual substrings that
were matched aren't stored anywhere.

Now, the simplest change here would be if `string-match' and friends
also saved what it did the match on in addition to the current match
data.  Then things like

(replace-match "letter \\1" nil nil t)

would "remember" that we're referring to the string in question.  The
performance impact should be minimal -- just an extra `setq' on a global
C variable that would refer to the string we matched.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: replace matches in any string

[Stefan Monnier]

> (let ((regex "\\(alpha\\)")
>       (string "gamma alpha beta"))
>   (when (string-match regex string)
>     (replace-match "[first greek letter \\1]" nil nil string 1)))
> -> "gamma [first greek letter alpha] beta"

> We want the equivalent but against any string, not just the original
> string (the `replace-match' docs say STRING has to be the one used for
> the original `string-match').  The use case is when you say to match X
> in an e-mail address, then set the target group to "something-X-other".
> We want to do it with regex "\\(X\\)" against "userX@valid.domain" and
> target group "something-\\1-other".  Does that make sense?  Basically we
> want \1 but without the context of that original string we matched:

I think I'm beginning to understand.
First, you don't want

  (replace-match "[first greek letter \\1]" nil nil string 1)
but
  (replace-match "[first greek letter \\1]" nil nil string)

then second, you do get the behavior you want in the particular case
where the string-match matched the whole string.
So to simulate:

> (let ((regex "\\(alpha\\)")
>       (string "gamma alpha beta"))
>   (when (string-match regex string)
>     (our-new-function "found greek letter \\1")))
> -> "found greek letter alpha"

you'd want:

   (let ((regex "\\(alpha\\)")
         (string "gamma alpha beta"))
     (when (string-match (concat "\\`.*?\\(?:" regex "\\).*\\'") string)
       (replace-match "found greek letter \\1" nil nil string)))

will do what you want, assuming your strings don't contain newlines, and
assuming that providing `string' is not a problem.
Of course, such string matching is a bit less optimized (and even less
so if you replace "." with "\\(?:.\\|\n\\)" to handle newlines), so it
might not be ideal.

We could implement this feature efficiently by generalizing the `subexp'
argument so that rather than subgroup-number it can also take a special
new value `whole-string' which means "not just the whole matched text,
but the whole freakin' string".  Then you could do:

   (let ((regex "\\(alpha\\)")
         (string "gamma alpha beta"))
     (when (string-match regex string)
       (replace-match "found greek letter \\1" nil nil string 'whole-string)))


-- Stefan

Re: replace matches in any string

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I think I'm beginning to understand.
> First, you don't want
>
>   (replace-match "[first greek letter \\1]" nil nil string 1)
> but
>   (replace-match "[first greek letter \\1]" nil nil string)
>
> then second, you do get the behavior you want in the particular case
> where the string-match matched the whole string.
> So to simulate:
>
>> (let ((regex "\\(alpha\\)")
>>       (string "gamma alpha beta"))
>>   (when (string-match regex string)
>>     (our-new-function "found greek letter \\1")))
>> -> "found greek letter alpha"
>
> you'd want:
>
>    (let ((regex "\\(alpha\\)")
>          (string "gamma alpha beta"))
>      (when (string-match (concat "\\`.*?\\(?:" regex "\\).*\\'") string)
>        (replace-match "found greek letter \\1" nil nil string)))

You mean like

(let ((regex "\\(alpha\\)")
      (string "gamma alpha beta"))
   (when (string-match regex string)
     (match-substitute-replacement "found greek letter \\1" nil nil string)))

-- 
David Kastrup

Re: replace matches in any string

[Ted Zlatanov]

On Thu, 02 Sep 2010 18:21:22 +0200 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

SM>    (let ((regex "\\(alpha\\)")
SM>          (string "gamma alpha beta"))
SM>      (when (string-match (concat "\\`.*?\\(?:" regex "\\).*\\'") string)
SM>        (replace-match "found greek letter \\1" nil nil string)))

SM> will do what you want, assuming your strings don't contain newlines, and
SM> assuming that providing `string' is not a problem.

SM> We could implement this feature efficiently by generalizing the `subexp'
SM> argument so that rather than subgroup-number it can also take a special
SM> new value `whole-string' which means "not just the whole matched text,
SM> but the whole freakin' string".  Then you could do:

SM>    (let ((regex "\\(alpha\\)")
SM>          (string "gamma alpha beta"))
SM>      (when (string-match regex string)
SM>        (replace-match "found greek letter \\1" nil nil string 'whole-string)))

That would be great.  Then we wouldn't have to play the string-match
regex escaping game above.  But it complicates the code a bit to provide
`string'.  I think Lars's suggestion to always save `string' to the same
global variable is sensible; then we could say

 (replace-match "found greek letter \\1" nil nil 'whole-last-string)

to mean "replace in the whole freakin' string you last matched on" :)

In a few tests your example worked great.  Lars, WDYT?

In general, it would be really nice if there was a
match-string/string-match/replace-match API variation that worked like
Perl's $1...$9 and Perl's named captures.  Those simply contain the
matched substring.  Putting a name on the capture is especially nice in
recent Perls, so you can refer to the captured data symbolically without
the fragile index.  But that's not necessary for the feature I'm
requesting so put it on the wishlist...

SM> Of course, such string matching is a bit less optimized (and even less
SM> so if you replace "." with "\\(?:.\\|\n\\)" to handle newlines), so it
SM> might not be ideal.

I think it will be used in non-performance-critical pieces so it's OK.

Ted

Re: replace matches in any string

[David Kastrup]

Ted Zlatanov <tzz@lifelogs.com> writes:

> SM> We could implement this feature efficiently by generalizing the `subexp'
> SM> argument so that rather than subgroup-number it can also take a special
> SM> new value `whole-string' which means "not just the whole matched text,
> SM> but the whole freakin' string".  Then you could do:
>
> SM>    (let ((regex "\\(alpha\\)")
> SM>          (string "gamma alpha beta"))
> SM>      (when (string-match regex string)
> SM>        (replace-match "found greek letter \\1" nil nil string 'whole-string)))
>
> That would be great.  Then we wouldn't have to play the string-match
> regex escaping game above.  But it complicates the code a bit to
> provide `string'.

Hardly.

> I think Lars's suggestion to always save `string' to the same global
> variable is sensible;

For one thing I guess it is too late to change the API.  For another,
that prevents strings from being garbage-collected as long as they are
present in some match-data.  While the same is true of buffers, a dead
buffer does not take significant space.

> then we could say
>
>  (replace-match "found greek letter \\1" nil nil 'whole-last-string)
>
> to mean "replace in the whole freakin' string you last matched on" :)
>
> In a few tests your example worked great.  Lars, WDYT?
>
> In general, it would be really nice if there was a
> match-string/string-match/replace-match API variation that worked like
> Perl's $1...$9 and Perl's named captures.  Those simply contain the
> matched substring.

What's wrong with match-substitute-replacement ?

-- 
David Kastrup

Re: replace matches in any string

[Ted Zlatanov]

On Thu, 02 Sep 2010 19:22:35 +0200 David Kastrup <dak@gnu.org> wrote: 

DK> Ted Zlatanov <tzz@lifelogs.com> writes:
>> That would be great.  Then we wouldn't have to play the string-match
>> regex escaping game above.  But it complicates the code a bit to
>> provide `string'.

DK> Hardly.

Is "a tiny bit" more accurate?  In any case,
`match-substitute-replacement' seems like the right function.  Thank
you.

>> I think Lars's suggestion to always save `string' to the same global
>> variable is sensible;

DK> For one thing I guess it is too late to change the API.

There's no change!  Saving the string is setting just one pointer
reference and does not change any existing code or APIs.

DK> For another, that prevents strings from being garbage-collected as
DK> long as they are present in some match-data.  While the same is true
DK> of buffers, a dead buffer does not take significant space.

Only one string would be kept around, not all the matches (I think
you're thinking of the tacked-on wishlist item below).

>> In general, it would be really nice if there was a
>> match-string/string-match/replace-match API variation that worked like
>> Perl's $1...$9 and Perl's named captures.  Those simply contain the
>> matched substring.

DK> What's wrong with match-substitute-replacement ?

It works for numeric capture offsets, thank you.  Named captures,
however, make regular expressions much easier to read and reuse.  Emacs,
being 25% regular expressions, would surely benefit from this.

We already have the `\(?NUM: ... \)' construct to explicitly set the
offset, so named captures could be as simple as `\(?'name': ... \)' or
some similar syntax.

Ted

Re: replace matches in any string

[David Kastrup]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Thu, 02 Sep 2010 19:22:35 +0200 David Kastrup <dak@gnu.org> wrote: 
>
> DK> Ted Zlatanov <tzz@lifelogs.com> writes:
>>> That would be great.  Then we wouldn't have to play the string-match
>>> regex escaping game above.  But it complicates the code a bit to
>>> provide `string'.
>
> DK> Hardly.
>
> Is "a tiny bit" more accurate?  In any case,
> `match-substitute-replacement' seems like the right function.  Thank
> you.
>
>>> I think Lars's suggestion to always save `string' to the same global
>>> variable is sensible;
>
> DK> For one thing I guess it is too late to change the API.
>
> There's no change!  Saving the string is setting just one pointer
> reference and does not change any existing code or APIs.

A function using save-match-data may be used in any hook or other stuff
called nearly asynchronously.  It is a very bad idea to add some global
variable to the match data (which is everything that affects matching)
without making save-match-data, match-data and set-match-data involved.

> DK> For another, that prevents strings from being garbage-collected as
> DK> long as they are present in some match-data.  While the same is true
> DK> of buffers, a dead buffer does not take significant space.
>
> Only one string would be kept around, not all the matches (I think
> you're thinking of the tacked-on wishlist item below).

Huh?  Of course only one string would be kept around, the source string
on which the match was made.  And that is at least as long as all
matches combined (at least when the matches are not inside one another).

-- 
David Kastrup

Re: replace matches in any string

[Ted Zlatanov]

On Thu, 02 Sep 2010 20:04:39 +0200 David Kastrup <dak@gnu.org> wrote: 

DK> Ted Zlatanov <tzz@lifelogs.com> writes:
DK> For one thing I guess it is too late to change the API.
>> 
>> There's no change!  Saving the string is setting just one pointer
>> reference and does not change any existing code or APIs.

DK> A function using save-match-data may be used in any hook or other stuff
DK> called nearly asynchronously.  It is a very bad idea to add some global
DK> variable to the match data (which is everything that affects matching)
DK> without making save-match-data, match-data and set-match-data involved.

I understand.  So it has to be local to the match data if introduced at
all.  Thanks for your explanation.

Ted

Recommended gnus spam filter system?

[Camm Maguire]

Greetings!  What is the preferred method of dealing with spam under
gnus?  I.e. what are most people using with satisfaction?

Take care,
-- 
Camm Maguire			     		    camm@maguirefamily.org
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Re: Recommended gnus spam filter system?

[Thorsten Bonow]

>>>>> "Camm" == Camm Maguire <camm@maguirefamily.org> writes:

    Camm> Greetings!  What is the preferred method of dealing with
    Camm> spam under gnus?  I.e. what are most people using with
    Camm> satisfaction?

    Camm> ==========================================================
    Camm> "The earth is but one country, and mankind its citizens."
    Camm> -- Baha'u'llah

Greetings, Earthling!

The preferred method of dealing with spam under GNUS is recommending
to ask questions about it in a GNUS related newsgroup,
e.g. "gnu.emacs.gnus" instead of a mailing list concerned with the
development (and not the use) of GNU Emacs.

Toto

-- 
"We apologise for the inconvenience"
(God's Final Message to His Creation) 

Douglas Adams: So long, and thanks for all the fish

Re: replace matches in any string

[Stefan Monnier]

> For one thing I guess it is too late to change the API.  For another,
> that prevents strings from being garbage-collected as long as they are
> present in some match-data.  While the same is true of buffers, a dead
> buffer does not take significant space.

We already save the matched object if it's a buffer, and no, the
potential "space leak" is not a significant problem.

> What's wrong with match-substitute-replacement ?

Indeed, I had forgotten about it.


        Stefan

Re: Recommended gnus spam filter system?

[Frank Schmitt]

Camm Maguire <camm@maguirefamily.org> writes:

> Greetings!  What is the preferred method of dealing with spam under
> gnus?  I.e. what are most people using with satisfaction?

I forward all my mail to a Gmail account and from there back to my IMAP
server. Gmail does a wonderful job of filtering out spam and I always
have a web accessible backup of my mail. The downside is that Google has
all my mail... 


-- 
Have you ever considered how much text can fit in eighty columns?  Given that a
signature typically contains up to four lines of text, this space allows you to
attach a tremendous amount of valuable information to your messages.  Seize the
opportunity and don't waste your signature on bullshit that nobody cares about.

Re: Recommended gnus spam filter system?

[Karl Fogel]

Camm Maguire <camm@maguirefamily.org> writes:
>Greetings!  What is the preferred method of dealing with spam under
>gnus?  I.e. what are most people using with satisfaction?

Just FYI, this question would be more appropriate on an Emacs help forum
(see emacswiki.org for starters), rather than a development list like
this one.

To answer your question: I think spam filtering is generally considered
outside the purview of Gnus.  Spam filtering is computationally
expensive and most people do it before the mails hit their mail client
(e.g., they do it on the server), or at least with a separate program.
I am not aware of any spam filtering software for Emacs in general, let
alone for Gnus.

If there is a followup thread to this, feel free to CC me on it, but
let's make sure it's in a different forum.

Best,
-Karl

Re: replace matches in any string

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> For one thing I guess it is too late to change the API.  For another,
>> that prevents strings from being garbage-collected as long as they are
>> present in some match-data.  While the same is true of buffers, a dead
>> buffer does not take significant space.
>
> We already save the matched object if it's a buffer, and no, the
> potential "space leak" is not a significant problem.

It's one string per match data, so it's not significant.

>> What's wrong with match-substitute-replacement ?
>
> Indeed, I had forgotten about it.

Oh, that exists?  Never mind, then.  :-)  So you already save all the
matched substrings in case somebody calls a the function
`match-substitute-replacement', which nobody has heard of (there's one
(1) use of the function in question in the Emacs sources...

Hang on.  This is the definition:

(defun match-substitute-replacement (replacement
				     &optional fixedcase literal string subexp)
  "Return REPLACEMENT as it will be inserted by `replace-match'.
In other words, all back-references in the form `\\&' and `\\N'
are substituted with actual strings matched by the last search.
Optional FIXEDCASE, LITERAL, STRING and SUBEXP have the same
meaning as for `replace-match'."
  (let ((match (match-string 0 string)))
    (save-match-data
      (set-match-data (mapcar (lambda (x)
				(if (numberp x)
				    (- x (match-beginning 0))
				  x))
			      (match-data t)))
      (replace-match replacement fixedcase literal match subexp))))

This doesn't help at all.

The use case is that you had some string do a match, but you don't have
access to the string variable.  You just want the matches that you know
were made, aka perlish $1, $2, $3.  I reiterate my first posting on this
issue as a feature request.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: replace matches in any string

[Davis Herring]

> This doesn't help at all.
>
> The use case is that you had some string do a match, but you don't have
> access to the string variable.  You just want the matches that you know
> were made, aka perlish $1, $2, $3.  I reiterate my first posting on this
> issue as a feature request.

I don't know why you'd permanently lose the string you matched against,
but m-s-r does let you write

(defun format-matches (fmt regexp str)
  "Replace \\1 \\& etc. in FMT with matches from REGEXP against STR."
  (string-match regexp str)
  (match-substitute-replacement fmt nil nil str))

...in which case you only need to pass the string to one function.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: replace matches in any string

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> For one thing I guess it is too late to change the API.  For another,
>> that prevents strings from being garbage-collected as long as they are
>> present in some match-data.  While the same is true of buffers, a dead
>> buffer does not take significant space.
>
> We already save the matched object if it's a buffer,

What about my last sentence before yours did you not understand?

-- 
David Kastrup

Re: replace matches in any string

[Lars Magne Ingebrigtsen]

David Kastrup <dak@gnu.org> writes:

>>> For one thing I guess it is too late to change the API.  For another,
>>> that prevents strings from being garbage-collected as long as they are
>>> present in some match-data.  While the same is true of buffers, a dead
>>> buffer does not take significant space.
>>
>> We already save the matched object if it's a buffer,
>
> What about my last sentence before yours did you not understand?

I didn't understand the bit where you seem to imply that saving a
reference to one (1) string would take significant space.  (Unless, of
course, you're using a `save-match-data', where you'd save one (1)
string extra per nesting.  I think.)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen