From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [RFC, experimental] save_{excursion,restriction} Date: Tue, 24 Jul 2012 05:37:59 -0400 Message-ID: References: <500D84B6.50303@yandex.ru> <500E2FB7.4080006@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1343122700 10193 80.91.229.3 (24 Jul 2012 09:38:20 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 24 Jul 2012 09:38:20 +0000 (UTC) Cc: Emacs development discussions To: Dmitry Antipov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 24 11:38:20 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1StbZG-0007c6-01 for ged-emacs-devel@m.gmane.org; Tue, 24 Jul 2012 11:38:14 +0200 Original-Received: from localhost ([::1]:37740 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1StbZF-0004eG-C9 for ged-emacs-devel@m.gmane.org; Tue, 24 Jul 2012 05:38:13 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:37498) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1StbZC-0004dz-0k for emacs-devel@gnu.org; Tue, 24 Jul 2012 05:38:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1StbZ6-0006IY-5A for emacs-devel@gnu.org; Tue, 24 Jul 2012 05:38:09 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:58436) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1StbZ5-0006IT-Vm for emacs-devel@gnu.org; Tue, 24 Jul 2012 05:38:04 -0400 Original-Received: from fmsmemgm.homelinux.net (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id q6O9c1d1024170; Tue, 24 Jul 2012 05:38:02 -0400 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 27602AE2FE; Tue, 24 Jul 2012 05:37:59 -0400 (EDT) In-Reply-To: <500E2FB7.4080006@yandex.ru> (Dmitry Antipov's message of "Tue, 24 Jul 2012 09:16:39 +0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0.9 X-NAI-Spam-Rules: 2 Rules triggered SBJ_END_BRKT=0.9, RV4288=0 X-NAI-Spam-Version: 2.2.0.9309 : core <4288> : streams <789718> : uri <1173379> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:151854 Archived-At: >> 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