From: Stefan Monnier <monnier@IRO.UMontreal.CA>
To: Dmitry Antipov <dmantipov@yandex.ru>
Cc: Emacs development discussions <emacs-devel@gnu.org>
Subject: Re: [RFC, experimental] save_{excursion,restriction}
Date: Tue, 24 Jul 2012 05:37:59 -0400 [thread overview]
Message-ID: <jwvmx2pfrde.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <500E2FB7.4080006@yandex.ru> (Dmitry Antipov's message of "Tue, 24 Jul 2012 09:16:39 +0400")
>> PS: Another source of slowdown for save-excursion is the
>> unchain_marker call.
> Yes, I believe that markers needs substantial redesign too.
I'm not sure that's actually needed. I think only overlays need such
a redesign after which markers won't be used by overlays any more and
they won't be numerous enough to warrant a redesign.
Basically, I think that overlays should live inside the balanced trees
we use for text-properties, using the "Augmented tree" approach of
http://en.wikipedia.org/wiki/Interval_tree.
> Lisp_Object
> save_excursion_save (void)
> {
> - int visible = (XBUFFER (XWINDOW (selected_window)->buffer)
> - == current_buffer);
> -
> - return Fcons (Fpoint_marker (),
> - Fcons (Fcopy_marker (BVAR (current_buffer, mark), Qnil),
> - Fcons (visible ? Qt : Qnil,
> - Fcons (BVAR (current_buffer, mark_active),
> - selected_window))));
> + Lisp_Object buf;
> + struct excursion *ex;
> + struct window *w = XWINDOW (selected_window);
> + struct Lisp_Marker *m = XMARKER (BVAR (current_buffer, mark));
> +
> + ex = xmalloc (sizeof *ex);
> + ex->window = w;
> + ex->visible = (XBUFFER (w->buffer) == current_buffer);
> + ex->active = !NILP (BVAR (current_buffer, mark_active));
> +
> + /* We do not initialize type and gcmarkbit since this marker
> + is never referenced via Lisp_Object and invisible for GC. */
> + INIT_MARKER (&ex->point, current_buffer, PT, PT_BYTE, 0);
> + ex->point.type = Lisp_Misc_Marker;
> + ex->point.next = BUF_MARKERS (current_buffer);
> + BUF_MARKERS (current_buffer) = &ex->point;
The comment says "We do not initialize type" and then you do
"ex->point.type = Lisp_Misc_Marker;". That sounds contradictory.
> + /* Likewise. Note that charpos and bytepos may be zero. */
> + INIT_MARKER (&ex->mark, current_buffer, m->charpos,
> + m->bytepos, m->insertion_type);
Better not use current_buffer here, but m->buffer.
> + ex->mark.type = Lisp_Misc_Marker;
> + ex->mark.next = BUF_MARKERS (current_buffer);
> + BUF_MARKERS (current_buffer) = &ex->mark;
Can't you use attach_marker or some such, rather than hand-coding the
insertion of those markers into BUF_MARKERS?
> + ex->next = current_buffer->excursions;
> + current_buffer->excursions = ex;
> + XSETBUFFER (buf, current_buffer);
> + return buf;
> }
BTW, why use an extra `excursions' field rather than just use a new
Lisp_Object type for "struct excursion"?
I think that would be cleaner to either make them into
Lisp_Pseudovector or Lisp_Misc.
> - /* If buffer being returned to is now deleted, avoid error */
> - /* Otherwise could get error here while unwinding to top level
> - and crash */
> - /* In that case, Fmarker_buffer returns nil now. */
Where did this test go?
> +/* Used to setup base fields of Lisp_Marker. */
> +
> +#define INIT_MARKER(mark, buf, cpos, bpos, itype) \
> + ((mark)->buffer = (buf), (mark)->charpos = (cpos), \
> + (mark)->bytepos = (bpos), (mark)->insertion_type = (itype), 1)
Why "1"?
Stefan
next prev parent reply other threads:[~2012-07-24 9:37 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-23 17:07 [RFC, experimental] save_{excursion,restriction} Dmitry Antipov
2012-07-23 23:45 ` Stefan Monnier
2012-07-24 5:16 ` Dmitry Antipov
2012-07-24 9:37 ` Stefan Monnier [this message]
2012-07-24 11:28 ` Dmitry Antipov
2012-07-24 22:05 ` Stefan Monnier
2012-07-25 9:38 ` Dmitry Antipov
2012-07-25 23:44 ` Stefan Monnier
2012-07-26 5:14 ` Dmitry Antipov
2012-07-26 23:24 ` Stefan Monnier
2012-07-24 6:31 ` Ivan Andrus
2012-07-24 9:14 ` Stefan Monnier
2012-07-27 3:51 ` Chong Yidong
2012-07-27 8:00 ` Dmitry Antipov
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=jwvmx2pfrde.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=dmantipov@yandex.ru \
--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).