From: storm@cua.dk (Kim F. Storm)
Cc: Carsten Dominik <dominik@science.uva.nl>, emacs-devel@gnu.org
Subject: Re: Inefficient code in reftex-index.el
Date: Tue, 07 Jun 2005 13:28:59 +0200 [thread overview]
Message-ID: <m3zmu2qubo.fsf@kfs-l.imdomain.dk> (raw)
In-Reply-To: <85psuyzatz.fsf@lola.goethe.zz> (David Kastrup's message of "Tue, 07 Jun 2005 13:05:12 +0200")
David Kastrup <dak@gnu.org> writes:
> storm@cua.dk (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 see. But that doesn't contradict my feeling that match-data
doesn't have to do anything special about markers in REUSE.
But we could make an optional arg RESEAT to match-data which
causes the markers in REUSE to be reseated to nowhere (if t),
or be freed if RESEAT equals `evaporate'.
>
> I think it was me that did that piece of prescient paranoia.
>
>>>> In any case, to me, the match-data interface should not be
>>>> considered a user-level feature _at all_.
>>>
>>> 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.
>
> No objection here. No idea whether match-size would be more
> appropriate. The C code is not really helpful deciding about that
> since it uses search_regs.num_regs and that is not suggestive of any
> sensible Lisp name.
IMO, match-count is better than match-size.
BTW, match-count != search_regs.num_regs, as match-data only
returns elements up to the last successful submatch.
--
Kim F. Storm <storm@cua.dk> http://www.cua.dk
next prev parent reply other threads:[~2005-06-07 11:28 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-06 12:08 Inefficient code in reftex-index.el Kim F. Storm
2005-06-06 12:39 ` David Kastrup
2005-06-06 13:52 ` Stefan Monnier
2005-06-06 14:14 ` Kim F. Storm
2005-06-06 14:15 ` Juanma Barranquero
2005-06-06 14:18 ` Kim F. Storm
2005-06-06 22:24 ` Kim F. Storm
2005-06-06 23:55 ` David Kastrup
2005-06-07 8:46 ` Kim F. Storm
2005-06-07 9:23 ` David Kastrup
2005-06-07 10:38 ` Kim F. Storm
2005-06-07 11:05 ` David Kastrup
2005-06-07 11:28 ` Kim F. Storm [this message]
2005-06-07 14:28 ` Richard Stallman
2005-06-07 14:46 ` Kim F. Storm
2005-06-07 18:06 ` Stefan Monnier
2005-06-08 8:44 ` Kim F. Storm
2005-06-08 9:47 ` David Kastrup
2005-06-08 10:00 ` Kim F. Storm
2005-06-08 10:11 ` David Kastrup
2005-06-08 15:59 ` Richard Stallman
2005-06-08 16:25 ` David Kastrup
2005-06-09 14:40 ` Richard Stallman
2005-06-09 15:05 ` David Kastrup
2005-06-10 13:30 ` Richard Stallman
2005-06-10 14:13 ` David Kastrup
2005-06-07 14:28 ` Richard Stallman
2005-06-07 14:35 ` David Kastrup
2005-06-08 15:59 ` Richard Stallman
2005-06-07 14:42 ` Kim F. Storm
2005-06-07 18:11 ` Stefan Monnier
2005-06-08 12:01 ` Richard Stallman
2005-06-08 23:08 ` Kim F. Storm
2005-06-07 12:24 ` Richard Stallman
2005-06-06 14:41 ` Carsten Dominik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3zmu2qubo.fsf@kfs-l.imdomain.dk \
--to=storm@cua.dk \
--cc=dominik@science.uva.nl \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).