From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Michael Heerdegen Newsgroups: gmane.emacs.devel Subject: Re: [elpa] master 5640cd0 04/12: el-search: some comment changes Date: Mon, 12 Oct 2015 11:46:20 +0200 Message-ID: <878u78s9lf.fsf@web.de> References: <20151011103325.2269.2052@vcs.savannah.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1444643212 14143 80.91.229.3 (12 Oct 2015 09:46:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 12 Oct 2015 09:46:52 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 12 11:46:43 2015 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 1ZlZgo-0007Uc-Az for ged-emacs-devel@m.gmane.org; Mon, 12 Oct 2015 11:46:42 +0200 Original-Received: from localhost ([::1]:54158 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZlZgk-00008B-En for ged-emacs-devel@m.gmane.org; Mon, 12 Oct 2015 05:46:38 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37600) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZlZgh-000084-6w for emacs-devel@gnu.org; Mon, 12 Oct 2015 05:46:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZlZgc-0003bd-7P for emacs-devel@gnu.org; Mon, 12 Oct 2015 05:46:35 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:36525) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZlZgc-0003bS-0h for emacs-devel@gnu.org; Mon, 12 Oct 2015 05:46:30 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1ZlZga-0007JY-6q for emacs-devel@gnu.org; Mon, 12 Oct 2015 11:46:28 +0200 Original-Received: from ip-90-186-2-115.web.vodafone.de ([90.186.2.115]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 12 Oct 2015 11:46:28 +0200 Original-Received: from michael_heerdegen by ip-90-186-2-115.web.vodafone.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 12 Oct 2015 11:46:28 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 53 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip-90-186-2-115.web.vodafone.de User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) Cancel-Lock: sha1:wkI+GYLSf0uy6q4vT0ReGXQIL5c= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:191309 Archived-At: Artur Malabarba writes: > On 11 Oct 2015 11:33 am, "Michael Heerdegen" > wrote: > > + ;; FIXME: an interesting alternative would be to really integrate it > > + ;; with Isearch, using `isearch-search-fun-function'. > > + ;; Alas, this is not trivial if we want to transfer our optimizations. > > (interactive) > > (el-search-pattern > > (el-search--read-pattern > > Can you explain why? I've been thinking of making some refactorings to > isearch (after the feature freeze) and I could try to extend > isearch-search-fun-function to cover your use case if it's not too > hard. That's great news. When I added the "this is not trivial if we want to transfer our optimizations" to the comment, I didn't take changing isearch itself into account. I use two optimization techniques at the moment: (1) Cache the current expanded pcase call, to avoid costly repeated pcase expansion. Probably not problematic wrt isearch. (2) The most time consuming part while searching is getting to the start of the next sexp, because it is done so often. The optimization I recently added factors the function that does that into two parts: - The first part is called only when starting a new search. It performs costly tests (calling syntax functions), moves out of comments, and such stuff. It guarantees to leave point at a position that fulfills a certain set of conditions, let's call it C. - The second part is very fast. Once C holds, it's sufficient to call it repeatedly. (2) makes a huge change in efficiency (factor 5 or so). The problem is that because of (2), it's not possible to pass a function to isearch that finds the next match from any place and is optimized in that way. If you have an idea how to optimize the "move point to the next start of an expression" further or better, I'm open ear. BTW, I don't yet have implemented backward searching. Regards, Michael.