From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Barry OReilly Newsgroups: gmane.emacs.devel Subject: parse-partial-sexp to stop at any depth change (and Re: Fontifying outside of region passed to registered JIT lock function) Date: Fri, 22 Nov 2013 17:14:52 -0500 Message-ID: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1135e5fce8b47204ebcb57e0 X-Trace: ger.gmane.org 1385158495 9539 80.91.229.3 (22 Nov 2013 22:14:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 22 Nov 2013 22:14:55 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 22 23:15:01 2013 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 1Vjz08-0002t2-8E for ged-emacs-devel@m.gmane.org; Fri, 22 Nov 2013 23:15:00 +0100 Original-Received: from localhost ([::1]:41340 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vjz07-0002TC-JJ for ged-emacs-devel@m.gmane.org; Fri, 22 Nov 2013 17:14:59 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53204) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vjz04-0002T4-0W for emacs-devel@gnu.org; Fri, 22 Nov 2013 17:14:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vjz02-0003Di-5P for emacs-devel@gnu.org; Fri, 22 Nov 2013 17:14:55 -0500 Original-Received: from mail-ob0-x232.google.com ([2607:f8b0:4003:c01::232]:55236) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vjz01-0003De-Uh for emacs-devel@gnu.org; Fri, 22 Nov 2013 17:14:54 -0500 Original-Received: by mail-ob0-f178.google.com with SMTP id uz6so1959641obc.37 for ; Fri, 22 Nov 2013 14:14:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=hE0YNretCN+uRV497GGvLWGj4N/bbB1wuC5ZJlKJE2s=; b=HltNu8I5OhG3B1n5fuaoc3OdxJvVJbaS/r9sdP1gJJzRjcTcAGYtqYw3N4AER6OLsT YATcnlSM9bvKoIKdi1VstxcjPjxn+MwhLLALMlyz08dRzZmA7UPPsjfpbOzm6Vw6YpLo d/pjKNcPd2RlKTAr2Gqyo3Zr6/3i4XCp07Q/i7APwfiA1vpEHa44g4nm4AQnk6O4TSiQ weJiFBY3WJYC16Ec/tTOOUsP6Z1Ahh/Vz6NoE574j8m+S3jZLX8EULdIKmLcixnSMOuK UKzuUgyBIS1WuNnniDAux0UlQh/jq+ycTdVkge4L9qskYC2NfuDW+0LxuoCN/8n+Oju+ 3nFw== X-Received: by 10.60.73.137 with SMTP id l9mr12658760oev.32.1385158492596; Fri, 22 Nov 2013 14:14:52 -0800 (PST) Original-Received: by 10.76.156.103 with HTTP; Fri, 22 Nov 2013 14:14:52 -0800 (PST) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4003:c01::232 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:165584 Archived-At: --001a1135e5fce8b47204ebcb57e0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable > insert a "display only" close-paren (with suitable coloring). There's probably less potential to cause user confusion if it colors existing parens rather than color parens that are not really a part of the file content. > 1- do add the face on the text before the beginning of the region. > The problem there, is to make sure this face is kept up-to-date > later on (e.g. removed if you add revert to the previous > indentation). For that you'll want to add a jit-lock-multiline > text-property. I found the right colors seem to display at the right times if I: =95 For initial fontification: do add the face outside the region =95 For fontification after changes: rely on a new jit-lock-after-change-extend-region-functions hook to expand the region Since that is working, I began investigating the performance. One issue is my usage of parse-partial-sexp. This function's interface doesn't make it easy to stop if there's a change of depth either up or down, so for code simplicity I went one char at a time: (parse-partial-sexp (point) (1+ (point)) nil nil parse-state nil) To see if this was responsible for performance degradation, I hacked the C implementation to allow a caller to specify "stop at a change of depth either up or down" and used it. The performance improvement was huge. Now, I could write code that would do two sexp parses concurrently, searching for a change of depth up and a change of depth down, saving the result of the furthest parse so as to not create an O(n*n) algorithm. Rather than complect my code in this way, what would you think of extending the parse-partial-sexp in one of two ways: =95 If TARGETDEPTH is t, stop when any change of depth occurs =95 If TARGETDEPTH is a vector of integer depths, stop when any of those depths is reached. I figure I can't be the only one who would want to have parse-partial-sexp stop at any change of depth. May I prepare a patch to provide this? --001a1135e5fce8b47204ebcb57e0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
> insert a "display only" close-paren (with s= uitable coloring).

There's probably less potential to cause user= confusion if it colors
existing parens rather than color parens that ar= e not really a part of
the file content.

> 1- do add the face on the text before the beg= inning of the region.
>=A0=A0=A0 The problem there, is to make sure t= his face is kept up-to-date
>=A0=A0=A0 later on (e.g. removed if you = add revert to the previous
>=A0=A0=A0 indentation). For that you'll want to add a jit-lock-mult= iline
>=A0=A0=A0 text-property.

I found the right colors seem = to display at the right times if I:

=A0 =95 For initial fontificatio= n: do add the face outside the region
=A0 =95 For fontification after changes: rely on a new
=A0=A0=A0 jit-loc= k-after-change-extend-region-functions hook to expand the
=A0=A0=A0 regi= on

Since that is working, I began investigating the performance.
=
One issue is my usage of parse-partial-sexp. This function's interf= ace
doesn't make it easy to stop if there's a change of depth either up= or
down, so for code simplicity I went one char at a time:

=A0 (= parse-partial-sexp (point)
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 (1+ (point))
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 nil
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 nil
=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 parse-state=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 nil)
To see if this was responsible for performance degradation, I hacked
t= he C implementation to allow a caller to specify "stop at a change of<= br> depth either up or down" and used it. The performance improvement was<= br>huge.

Now, I could write code that would do two sexp parses concu= rrently,
searching for a change of depth up and a change of depth down, = saving
the result of the furthest parse so as to not create an O(n*n)
algorithm= . Rather than complect my code in this way, what would you
think of exte= nding the parse-partial-sexp in one of two ways:

=A0 =95 If TARGETDE= PTH is t, stop when any change of depth occurs
=A0 =95 If TARGETDEPTH is a vector of integer depths, stop when any of
= =A0=A0=A0 those depths is reached.

I figure I can't be the only = one who would want to have
parse-partial-sexp stop at any change of dept= h. May I prepare a patch
to provide this?

--001a1135e5fce8b47204ebcb57e0--