Richard Stallman <[EMAIL PROTECTED]> writes:
> Certainly cleaner than the straw man you are trying to put up, no
> question about that.
>
> It's not a straw man. It's what I'd expect most such cases to do.
>
> If it is very important to optimize your code, we could add a
> function match-
Certainly cleaner than the straw man you are trying to put up, no
question about that.
It's not a straw man. It's what I'd expect most such cases to do.
If it is very important to optimize your code, we could add
a function match-count to do so. But is it really that
important to optimi
Richard Stallman <[EMAIL PROTECTED]> writes:
> > Can't you tell that more easily by seeing if match-beginning returns
> nil?
>
> Which match-beginning?
>
> One for a subexpression inside the alternative you're trying to test for.
>
> After (string-match "\\(a\\)\\|\\(b\\)\\|\\(c\\)" i
> Can't you tell that more easily by seeing if match-beginning returns nil?
Which match-beginning?
One for a subexpression inside the alternative you're trying to test for.
After (string-match "\\(a\\)\\|\\(b\\)\\|\\(c\\)" input)
I can just consult (length (match-data)) for dist
Richard Stallman <[EMAIL PROTECTED]> writes:
> This `evaporate' idea is a good one, but I agree with the person
> who said that the indication should go at the end, not the beginning,
> of the return value. The value returned by `match-data' has
> a defined format and this should not be broken.
Richard Stallman <[EMAIL PROTECTED]> writes:
> Actually the only cases I can vaguely remember using the (/
> (length (match-data)) 2) idiom didn't use the whole
> (match-data). They typically used the idiom in order to know
> *which* subgroup matched (of course it only works if yo
Actually the only cases I can vaguely remember using the
(/ (length (match-data)) 2) idiom didn't use the whole (match-data).
They typically used the idiom in order to know *which* subgroup matched (of
course it only works if you craft your regexp carefully).
Can't you tell that mo
Problem is that markers slow down editing, and significantly so. And
normal editing operations are not associated with extensive consing,
so they won't trigger frequent garbage collection.
That is sufficient reason to urge people to use match-data only when
really necessary, but not a
This `evaporate' idea is a good one, but I agree with the person
who said that the indication should go at the end, not the beginning,
of the return value. The value returned by `match-data' has
a defined format and this should not be broken.
___
Emacs
[EMAIL PROTECTED] (Kim F. Storm) writes:
> David Kastrup <[EMAIL PROTECTED]> writes:
>
>>> Actually the only cases I can vaguely remember using the
>>> (/ (length (match-data)) 2) idiom didn't use the whole (match-data).
>>> They typically used the idiom in order to know *which* subgroup matched (
David Kastrup <[EMAIL PROTECTED]> writes:
>> Actually the only cases I can vaguely remember using the
>> (/ (length (match-data)) 2) idiom didn't use the whole (match-data).
>> They typically used the idiom in order to know *which* subgroup matched (of
>> course it only works if you craft your reg
Stefan Monnier <[EMAIL PROTECTED]> writes:
>>> There is no other interface into the number of accessible match
>>> strings (which might be nil) rather than
>>> (/ (length (match-data t)) 2).
>
>> That's still pretty inefficient -- I suggest that we introduce a new
>> function `match-count'
Stefan Monnier <[EMAIL PROTECTED]> writes:
>>> There is no other interface into the number of accessible match
>>> strings (which might be nil) rather than
>>> (/ (length (match-data t)) 2).
>
>> That's still pretty inefficient -- I suggest that we introduce a new
>> function `match-count'
>> There is no other interface into the number of accessible match
>> strings (which might be nil) rather than
>> (/ (length (match-data t)) 2).
> That's still pretty inefficient -- I suggest that we introduce a new
> function `match-count' to return that number.
> Is there sufficient use
> In any case, to me, the match-data interface should not be considered
> a user-level feature _at all_. The user level feature is
> save-match-data, which does not (in principle) allow the user to mess
> with the saved data. And in that respect, nobody should really care
> about what the format
Richard Stallman <[EMAIL PROTECTED]> writes:
> In any case, to me, the match-data interface should not be considered
> a user-level feature _at all_.
>
> I don't agree. It is legitimate for user code to call match-data
> directly.
In special cases, yes.
However, the majority of code
Richard Stallman <[EMAIL PROTECTED]> writes:
> > There is no other interface into the number of accessible match
> > strings (which might be nil) rather than
> > (/ (length (match-data t)) 2).
>
> That's still pretty inefficient -- I suggest that we introduce a new
> function `
Richard Stallman <[EMAIL PROTECTED]> writes:
> In any case, to me, the match-data interface should not be considered
> a user-level feature _at all_.
>
> I don't agree. It is legitimate for user code to call match-data
> directly. There is no reason for the changes people are proposing.
In any case, to me, the match-data interface should not be considered
a user-level feature _at all_.
I don't agree. It is legitimate for user code to call match-data
directly. There is no reason for the changes people are proposing.
___
Emac
> There is no other interface into the number of accessible match
> strings (which might be nil) rather than
> (/ (length (match-data t)) 2).
That's still pretty inefficient -- I suggest that we introduce a new
function `match-count' to return that number.
Is there sufficient
Which brings me to the suggestion that we add an optional arg to
set-match-data like this:
(set-match-data list &optional destroy-markers)
and change save-match-data to use it
That would be an improvement, but the next GC will destroy these
markers anyway, so it may not be a b
David Kastrup <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Kim F. Storm) writes:
>
>> In any case, I didn't find any code which actually uses the REUSE
>> form of match-data, so that feature is pretty obscure already, so I
>> think we should just keep the original behavior of the REUSE arg.
>
[EMAIL PROTECTED] (Kim F. Storm) writes:
> In any case, I didn't find any code which actually uses the REUSE
> form of match-data, so that feature is pretty obscure already, so I
> think we should just keep the original behavior of the REUSE arg.
Look at replace-match-data in replace.el...
I thi
David Kastrup <[EMAIL PROTECTED]> writes:
> If INTEGERS (the optional first argument) is non-nil, always use
> integers (rather than markers) to represent buffer positions. In
> this case, and if the last match was in a buffer, the buffer will get
> stored as one additional elemen
[EMAIL PROTECTED] (Kim F. Storm) writes:
> David Kastrup <[EMAIL PROTECTED]> writes:
>
>>> I made the change slightly different to avoid adding another arg to
>>> Fset_match_data, which causes problems at C level. Instead, if first
>>> arg to match-data is 'evaporate', set-match-data will eventua
David Kastrup <[EMAIL PROTECTED]> writes:
>> I made the change slightly different to avoid adding another arg to
>> Fset_match_data, which causes problems at C level. Instead, if first
>> arg to match-data is 'evaporate', set-match-data will eventually free
>> markers on the resulting list...
>
>
[EMAIL PROTECTED] (Kim F. Storm) writes:
> [EMAIL PROTECTED] (Kim F. Storm) writes:
>
>>
>> Which brings me to the suggestion that we add an optional arg to
>> set-match-data like this:
>>
>> (set-match-data list &optional destroy-markers)
>>
>> and change save-match-data to use it
>>
>> (defma
[EMAIL PROTECTED] (Kim F. Storm) writes:
>
> Which brings me to the suggestion that we add an optional arg to
> set-match-data like this:
>
> (set-match-data list &optional destroy-markers)
>
> and change save-match-data to use it
>
> (defmacro save-match-data (&rest body)
> "Execute the BODY
> "DK" == David Kastrup <[EMAIL PROTECTED]> writes:
DK> [EMAIL PROTECTED] (Kim F. Storm) writes:
>> I noticed the following code in reftex-index.el:
>>
>> (condition-case nil (texmathp) (error nil
>> (setq beg (car (match-data))
>> end (nth 1 (match-data)))
>>
>> Using match-data like
David Kastrup <[EMAIL PROTECTED]> writes:
> That is not the same: the above will set beg and end to markers,
How "clever" ... I would NEVER have guessed that.
> whereas match-beginning/match-end happen to be integers. However, the
> above will also create markers that are unused, so it would be
On 6/6/05, Stefan Monnier <[EMAIL PROTECTED]> wrote:
> If you want markers, then say so: (make-marker (match-beginning N))
(copy-marker (match-beginning-N))
or
(set-marker (make-marker) (match-beginning-N))
perhaps?
--
/L/e/k/t/u
Stefan Monnier <[EMAIL PROTECTED]> writes:
>> That is not the same: the above will set beg and end to markers,
>> whereas match-beginning/match-end happen to be integers. However, the
>
> If you want markers, then say so: (make-marker (match-beginning N))
Yes, indeed.
--
Kim F. Storm <[EMAIL P
> That is not the same: the above will set beg and end to markers,
> whereas match-beginning/match-end happen to be integers. However, the
If you want markers, then say so: (make-marker (match-beginning N))
Stefan
___
Emacs-devel mailing lis
[EMAIL PROTECTED] (Kim F. Storm) writes:
> I noticed the following code in reftex-index.el:
>
> (condition-case nil (texmathp) (error nil
> (setq beg (car (match-data))
> end (nth 1 (match-data)))
>
> Using match-data like that seems inefficien
I noticed the following code in reftex-index.el:
(condition-case nil (texmathp) (error nil
(setq beg (car (match-data))
end (nth 1 (match-data)))
Using match-data like that seems inefficient.
I suggtest using match-beginning/match-end instea
35 matches
Mail list logo
