From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Lars Ingebrigtsen Newsgroups: gmane.emacs.devel Subject: Re: Text property searching Date: Mon, 16 Apr 2018 20:26:59 +0200 Message-ID: <87muy3ypl8.fsf@mouse.gnus.org> References: <87lgdo5bb3.fsf@mouse.gnus.org> <87in8r16b0.fsf@mouse.gnus.org> <87d0yz15a3.fsf@mouse.gnus.org> <87604r143y.fsf@mouse.gnus.org> <87wox7yrz8.fsf@mouse.gnus.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1523903124 6527 195.159.176.226 (16 Apr 2018 18:25:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 16 Apr 2018 18:25:24 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 16 20:25:20 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f88oa-0001aT-84 for ged-emacs-devel@m.gmane.org; Mon, 16 Apr 2018 20:25:20 +0200 Original-Received: from localhost ([::1]:35221 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f88qf-0002AX-3R for ged-emacs-devel@m.gmane.org; Mon, 16 Apr 2018 14:27:29 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33013) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f88qX-00028b-F7 for emacs-devel@gnu.org; Mon, 16 Apr 2018 14:27:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f88qU-00017E-BR for emacs-devel@gnu.org; Mon, 16 Apr 2018 14:27:21 -0400 Original-Received: from hermes.netfonds.no ([80.91.224.195]:44890) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1f88qU-00014t-4y for emacs-devel@gnu.org; Mon, 16 Apr 2018 14:27:18 -0400 Original-Received: from 46.67.12.60.tmi.telenormobil.no ([46.67.12.60] helo=corrigan) by hermes.netfonds.no with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1f88qQ-0001YC-30 for emacs-devel@gnu.org; Mon, 16 Apr 2018 20:27:16 +0200 Original-Received: from larsi by corrigan with local (Exim 4.89) (envelope-from ) id 1f88qG-0007al-Tc for emacs-devel@gnu.org; Mon, 16 Apr 2018 20:27:04 +0200 In-Reply-To: <87wox7yrz8.fsf@mouse.gnus.org> (Lars Ingebrigtsen's message of "Mon, 16 Apr 2018 19:35:23 +0200") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 80.91.224.195 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:224662 Archived-At: Below is a draft of the documentation of this function. Does it all make sense? :-) Should we perhaps go for a shorter name for this function? It's a bit of a mouthful, but I don't really have any ideas for a good, snappy name here... -- Function: text-property-search-forward prop value predicate Search for the next region that has text property PROP set to VALUE according to PREDICATE. This function is modelled after =E2=80=98search-forward=E2=80=99 and f= riends in that it moves point, but it returns a structure that describes the match instead of returning it in =E2=80=98match-beginning=E2=80=99 and= friends. If the text property can=E2=80=99t be found, the function returns =E2= =80=98nil=E2=80=99. If it=E2=80=99s found, point is placed at the end of the region that h= as this text property match, and a =E2=80=98prop-match=E2=80=99 structure= is returned. PREDICATE can either be =E2=80=98t=E2=80=99 (which is a synonym for = =E2=80=98equal=E2=80=99), =E2=80=98nil=E2=80=99 (which means =E2=80=9Cnot equal=E2=80=9D), or a predicate that will be= called with two parameters: The first is VALUE, and the second is the value of the text property we=E2=80=99re inspecting. In the examples below, imagine that you=E2=80=99re in a buffer that lo= oks like this: This is a bold and here's bolditalic and this is the end. That is, the =E2=80=9Cbold=E2=80=9D words are the =E2=80=98bold=E2=80= =99 face, and the =E2=80=9Citalic=E2=80=9D word is in the =E2=80=98italic=E2=80=99 face. With point at the start: (while (setq match (text-property-search-forward 'face 'bold t)) (push (buffer-substring (prop-match-beginning match) (prop-matc= h-end match)) words)) This will pick out all the words that use the =E2=80=98bold=E2=80=99 f= ace. (while (setq match (text-property-search-forward 'face nil t)) (push (buffer-substring (prop-match-beginning match) (prop-matc= h-end match)) words)) This will pick out all the bits that have no face properties, which will result in the list =E2=80=98("This is a " "and here's " "and this= is the end")=E2=80=99 (only reversed, since we used =E2=80=98push=E2=80= =99). (while (setq match (text-property-search-forward 'face nil nil)) (push (buffer-substring (prop-match-beginning match) (prop-matc= h-end match)) words)) This will pick out all the regions where =E2=80=98face=E2=80=99 is set= to something, but this is split up into where the properties change, so the result here will be =E2=80=98"bold" "bold" "italic"=E2=80=99. For a more realistic example where you might use this, consider that you have a buffer where certain sections represent URLs, and these are tagged with =E2=80=98shr-url=E2=80=99. (while (setq match (text-property-search-forward 'shr-url nil nil= )) (push (prop-match-value match) urls)) This will give you a list of all those URLs. --- Hm... it strikes me now that the two last parameters should be optional, since (text-property-search-forward 'shr-url) would then be even more obvious in its meaning. --=20 (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no