From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/87557 Path: news.gmane.org!.POSTED!not-for-mail From: Harry Putnam Newsgroups: gmane.emacs.gnus.general Subject: Re: any partial or rudamentary documentation of new nnselect work somewhere? Date: Sat, 13 May 2017 09:44:22 -0400 Organization: Still searching... Message-ID: <86fug8vpl5.fsf@local.lan> References: <86r301wqx2.fsf@local.lan> <87y3u9bk86.fsf@hanan> <867f1oxwsb.fsf@local.lan> <87fugcz2fu.fsf@hanan> <86o9uzwnh4.fsf@local.lan> <87a86ioosl.fsf@ericabrahamsen.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1494683121 12363 195.159.176.226 (13 May 2017 13:45:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 13 May 2017 13:45:21 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) To: ding@gnus.org Original-X-From: ding-owner+m35772@lists.math.uh.edu Sat May 13 15:45:17 2017 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from mxfilter-048035.atla03.us.yomura.com ([107.189.48.35]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d9XMC-00034H-RM for ding-account@gmane.org; Sat, 13 May 2017 15:45:16 +0200 X-Yomura-MXScrub: 1.0 Original-Received: from lists1.math.uh.edu (unknown [129.7.128.208]) by mxfilter-048035.atla03.us.yomura.com (Halon) with ESMTPS id 67386c99-37e2-11e7-b087-b499baabecb2; Sat, 13 May 2017 13:45:19 +0000 (UTC) Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by lists1.math.uh.edu with smtp (Exim 4.87) (envelope-from ) id 1d9XLX-0007xv-SK; Sat, 13 May 2017 08:44:35 -0500 Original-Received: from mx1.math.uh.edu ([129.7.128.32]) by lists1.math.uh.edu with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1d9XLV-0007xN-Aw for ding@lists.math.uh.edu; Sat, 13 May 2017 08:44:33 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtps (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.87) (envelope-from ) id 1d9XLU-0001fR-3F for ding@lists.math.uh.edu; Sat, 13 May 2017 08:44:33 -0500 Original-Received: from [195.159.176.226] (helo=blaine.gmane.org) by quimby.gnus.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1d9XLS-0003TC-MM for ding@gnus.org; Sat, 13 May 2017 15:44:30 +0200 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1d9XLK-0001ua-R6 for ding@gnus.org; Sat, 13 May 2017 15:44:22 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 81 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:WoKSh2vw+YlpX+yDZyXodVzOkPA= List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:87557 Archived-At: Eric Abrahamsen writes: > Harry Putnam writes: [...] >> I could search on exact code in perl groups for example ... and return >> exact bits of code with careful use of perl regex. >> >> Later on I added more (perl) code that created a directory and filled >> it with symlinks to the actual messages where my regex found hits. I >> could then pull that directory into gnus as an ephemeral group or >> nndoc inside gnus. >> >> All very clunky and probably duplicating functionality already in gnus >> but in a primitive and homeboy way. Also very slow. > > It does duplicate what's possible in Gnus (this could be done even with > Gnus as it stands now), using an external indexing program like namazu > or notmuch. The one big caveat would be that these programs almost > certainly wouldn't index perl code correctly -- I haven't tried it, but > I'd be very surprised if they did it right. That was roughly my thinking at the time...(about indexing) I considered trying to incorporate one or another of the indexing search tools available. But, first off, I didn't know how to do that... but might have fumbled my way thru. But, second and more important... indexing perl or other kinds of code; I new would be a loser. And that was my primary objective at the time. Back then there was a tool called glimpse that was still under development (although, barely) that does have a near regex capability and is also an indexing tool... but once again the indexing doesn't do well with code. So, decided to put up with slowness of full-fledged perl regex searching. Decided indexing just didn't go with the kind of searchs I was interested in. You would know vastly more than I about the capabilities of any of the search tools available now. But I believe you are right in thinking they would not index code very well at all. > The generalized search functionality that I'm working on (built on > Andy's nnselect branch) would let you create all kinds of weird search > engine behavior. In theory it wouldn't be hard at all to create a "grep" > mixin class for the indexed search engines, that accepted an additional > "grep:" key, and ran the grep over the results of the initial search. > Ie, you could enter the search string: > > subject:"having a problem" grep:"my ($smith, $jones) = @a;" since:3m > > The subject: and since: keys would be passed to the underlying search > engine (notmuch or mairix, etc), which would return a first round of > results very quickly. The results are in the form of filenames, so the > grep: key could then be used to do a second pass over those files. A > best-of-both-worlds situation. > > That sounds pretty useful. Maybe there's no need for a mixin class at > all; this could be a standard feature of the indexed search class. If > grep wasn't available on the system, you'd just get a polite note to > that effect. > Actually, there's already a regexp syntax: surrounding text with forward > slashes. Search engines that don't handle regexps could simply transform > "body:/(.*)/" into "grep:(.*)"... > > Hmmm... Yes, yes, and away you go... That two phase bit sounds really useful. I am really sorry to be of no help at all. If you fellows have any low level scut work that needs doing, and I do mean `low level'... that is, no coding required. I realize that is a piss poor offer, and there probably is nothing like that involved... but still ... just in case .. the offer stands.