* Emacs interface to Recoll other than Helm? @ 2017-11-07 15:30 Angel de Vicente 2017-11-07 15:37 ` Kaushal Modi 2017-11-07 15:51 ` Joost Kremers 0 siblings, 2 replies; 9+ messages in thread From: Angel de Vicente @ 2017-11-07 15:30 UTC (permalink / raw) To: help-gnu-emacs Hi, I've started using Recoll (https://www.lesbonscomptes.com/recoll/) to index my files. It works quite nicely, so now the next obvious step is to try to run it from inside Emacs (I can do it simply from a terminal, but ideally I would like to get the output formatted in a way similar to what you get when doing multi-occur: a buffer with all the search matches and with clickable files that will open the matched file). I've found that there is a Helm interface to it (https://github.com/emacs-helm/helm-recoll), but right now I'm using Ivy (http://oremacs.com/swiper/) and if possible I would like to avoid installing Helm just for the integration with Recoll (plus, I'm not sure if it will clash somehow with the installed Ivy?). Any pointers/suggestions/ideas welcome. Many thanks, -- Ángel de Vicente http://angel-de-vicente.blogspot.com/ ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Emacs interface to Recoll other than Helm? 2017-11-07 15:30 Emacs interface to Recoll other than Helm? Angel de Vicente @ 2017-11-07 15:37 ` Kaushal Modi 2017-11-07 16:17 ` Angel de Vicente 2017-11-07 16:43 ` Angel de Vicente 2017-11-07 15:51 ` Joost Kremers 1 sibling, 2 replies; 9+ messages in thread From: Kaushal Modi @ 2017-11-07 15:37 UTC (permalink / raw) To: Angel de Vicente; +Cc: help-gnu-emacs On Tue, Nov 7, 2017 at 10:34 AM Angel de Vicente <angelv@iac.es> wrote: > but right now I'm using Ivy > (http://oremacs.com/swiper/) and if possible I would like to avoid > installing Helm just for the integration with Recoll (plus, I'm not sure > if it will clash somehow with the installed Ivy?). > You will find Ivy-backend based plugins in the counsel library. About your question specific to Ivy+Recoll, it's already out there by the Ivy author himself: https://oremacs.com/2015/07/27/counsel-recoll/ -- Kaushal Modi ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Emacs interface to Recoll other than Helm? 2017-11-07 15:37 ` Kaushal Modi @ 2017-11-07 16:17 ` Angel de Vicente 2017-11-07 17:09 ` Angel de Vicente 2017-11-07 16:43 ` Angel de Vicente 1 sibling, 1 reply; 9+ messages in thread From: Angel de Vicente @ 2017-11-07 16:17 UTC (permalink / raw) To: help-gnu-emacs [-- Attachment #1: Type: text/plain, Size: 1600 bytes --] Hi, Kaushal Modi <kaushal.modi@gmail.com> writes: > On Tue, Nov 7, 2017 at 10:34 AM Angel de Vicente <angelv@iac.es> wrote: > >> but right now I'm using Ivy >> (http://oremacs.com/swiper/) and if possible I would like to avoid >> installing Helm just for the integration with Recoll (plus, I'm not sure >> if it will clash somehow with the installed Ivy?). >> > > You will find Ivy-backend based plugins in the counsel library. About your > question specific to Ivy+Recoll, it's already out there by the Ivy author > himself: https://oremacs.com/2015/07/27/counsel-recoll/ Funny, I had seen that webpage already and I tried to use the function in there, but it was giving an error (Error 127, whatever that is), but then I searched in the counsel.el file in my current version, and the function counsel-recoll is already defined there! Good, so with a fresh Emacs (I was overriding the counsel-recoll function) it works, but is not very convenient for my needs. counsel-recoll will give a dynamic list of files that match your search, and then you have to open the file and perform a search (with swiper, for example) to see if that was the stuff you were looking for (see the attached file counsel-recoll.png). But for this sort of thing, I think that it is nicer to have a buffer with the files where matches are found and with some context given. This is, for example, the type of output I get when doing a multi-occur find with Projectile (see attached file counsel-recoll-mo.png), and if possible I would like to try and get something like that, which I think it will more useful. Thanks, [-- Attachment #2: counsel-recoll.png --] [-- Type: image/png, Size: 247937 bytes --] [-- Attachment #3: counsel-recoll-mo.png --] [-- Type: image/png, Size: 344524 bytes --] [-- Attachment #4: Type: text/plain, Size: 61 bytes --] -- Ángel de Vicente http://angel-de-vicente.blogspot.com/ ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Emacs interface to Recoll other than Helm? 2017-11-07 16:17 ` Angel de Vicente @ 2017-11-07 17:09 ` Angel de Vicente 2017-11-07 20:19 ` Bob Proulx 0 siblings, 1 reply; 9+ messages in thread From: Angel de Vicente @ 2017-11-07 17:09 UTC (permalink / raw) To: help-gnu-emacs Sorry for the double post. I thought the post with the attached images had been rejected so I post it again with the images as links to some URL in the Internet. The rest of the message is basically the same. Angel de Vicente <angelv@iac.es> writes: > Hi, > > Kaushal Modi <kaushal.modi@gmail.com> writes: >> On Tue, Nov 7, 2017 at 10:34 AM Angel de Vicente <angelv@iac.es> wrote: >> >>> but right now I'm using Ivy >>> (http://oremacs.com/swiper/) and if possible I would like to avoid >>> installing Helm just for the integration with Recoll (plus, I'm not sure >>> if it will clash somehow with the installed Ivy?). >>> >> >> You will find Ivy-backend based plugins in the counsel library. About your >> question specific to Ivy+Recoll, it's already out there by the Ivy author >> himself: https://oremacs.com/2015/07/27/counsel-recoll/ > > Funny, I had seen that webpage already and I tried to use the function > in there, but it was giving an error (Error 127, whatever that is), but > then I searched in the counsel.el file in my current version, and the > function counsel-recoll is already defined there! Good, so with a fresh > Emacs (I was overriding the counsel-recoll function) it works, but is > not very convenient for my needs. counsel-recoll will give a dynamic > list of files that match your search, and then you have to open the file > and perform a search (with swiper, for example) to see if that was the > stuff you were looking for (see the attached file counsel-recoll.png). > > But for this sort of thing, I think that it is nicer to have a buffer > with the files where matches are found and with some context given. This > is, for example, the type of output I get when doing a multi-occur find > with Projectile (see attached file counsel-recoll-mo.png), and if > possible I would like to try and get something like that, which I think > it will more useful. > > Thanks, -- Ángel de Vicente http://angel-de-vicente.blogspot.com/ ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Emacs interface to Recoll other than Helm? 2017-11-07 17:09 ` Angel de Vicente @ 2017-11-07 20:19 ` Bob Proulx 2017-11-07 21:17 ` Angel de Vicente 0 siblings, 1 reply; 9+ messages in thread From: Bob Proulx @ 2017-11-07 20:19 UTC (permalink / raw) To: Angel de Vicente; +Cc: help-gnu-emacs Angel de Vicente wrote: > Sorry for the double post. I thought the post with the attached images > had been rejected so I post it again with the images as links to > some URL in the Internet. The rest of the message is basically > the same. Thank you for the second message with the links. For many people (me!) it is much easier to deal with that than inline images. As to the original large message with the inline images... Not to cause stress but to communicate the problems. Those large messages are always very painful for the lists.gnu.org mailing list server to process when sending to a large mailing list. This is a small list as there are only 1410 subscribed members. (And that does not count the people reading from the associated newsgroup through the mail2news gateway.) Other lists are truly huge with many more members. When sending inline images to a large mailing list the total bandwidth is a huge multiplier. Often things are very delayed due to those messages. An 800K message expands to 1.1T of consumed bandwidth to the entire list for just that one single message. Often the mailing list server will be running far behind trying to push bandwidth through the network. Which means we have been forced to start capping the size of messages on many mailing lists. Also for anyone using their mobile cell data plan those large messages eat up the data limit to the data cap very quickly. Large messages will either be automatically rejected or manually rejected or manually approved. One of the list moderators must have decided to send that one on to the list. If I had been at the keyboard reviewing that held message I would have rejected it. You would have gotten a rejection notice with an explanation and hints as to what could be done. Because of the human factor the actions taken are not always exactly the same. Just giving a view into the behind the scenes operations... :-) Bob ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Emacs interface to Recoll other than Helm? 2017-11-07 20:19 ` Bob Proulx @ 2017-11-07 21:17 ` Angel de Vicente 0 siblings, 0 replies; 9+ messages in thread From: Angel de Vicente @ 2017-11-07 21:17 UTC (permalink / raw) To: help-gnu-emacs Hi, Bob Proulx <bob@proulx.com> writes: > Angel de Vicente wrote: >> Sorry for the double post. I thought the post with the attached images >> had been rejected so I post it again with the images as links to >> some URL in the Internet. The rest of the message is basically >> the same. > > Thank you for the second message with the links. For many people > (me!) it is much easier to deal with that than inline images. Note taken. Sorry about that, I don't often send messages to mailing lists and I've been spoiled by e-mail where we often use it as a file transfer mechanism :-) -- Ángel de Vicente http://angel-de-vicente.blogspot.com/ ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Emacs interface to Recoll other than Helm? 2017-11-07 15:37 ` Kaushal Modi 2017-11-07 16:17 ` Angel de Vicente @ 2017-11-07 16:43 ` Angel de Vicente 2017-11-08 12:40 ` Angel de Vicente 1 sibling, 1 reply; 9+ messages in thread From: Angel de Vicente @ 2017-11-07 16:43 UTC (permalink / raw) To: help-gnu-emacs Hi, Kaushal Modi <kaushal.modi@gmail.com> writes: >> but right now I'm using Ivy >> (http://oremacs.com/swiper/) and if possible I would like to avoid >> installing Helm just for the integration with Recoll (plus, I'm not sure >> if it will clash somehow with the installed Ivy?). >> > > You will find Ivy-backend based plugins in the counsel library. About your > question specific to Ivy+Recoll, it's already out there by the Ivy author > himself: https://oremacs.com/2015/07/27/counsel-recoll/ thanks for the pointer. Actually I had tried to used the code in that page but it was giving me "Error 127", but then I realized I already have that version defined in counsel.el in my distribution of ivy/swiper. Now I manage to get it working, but I don't like the result too much since I get a dynamic list of files that match my query, but without any context, and then I have to open one by one and do a search inside the file. It looks like: http://picpaste.com/counsel-recoll-wDwS45L8.png What I would like is something more like what you get in the Recoll GUI (or, for example, when you do a multi-occur search), where you get a buffer with the files matching, together with some context and an easy way to open a particular file at the point where the match was found. Something like: http://picpaste.com/counsel-recoll-mo-uQUXHGey.png Any ideas? Many thanks, -- Ángel de Vicente http://angel-de-vicente.blogspot.com/ ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Emacs interface to Recoll other than Helm? 2017-11-07 16:43 ` Angel de Vicente @ 2017-11-08 12:40 ` Angel de Vicente 0 siblings, 0 replies; 9+ messages in thread From: Angel de Vicente @ 2017-11-08 12:40 UTC (permalink / raw) To: help-gnu-emacs Hi, Angel de Vicente <angelv@iac.es> writes: > What I would like is something more like what you get in the Recoll GUI > (or, for example, when you do a multi-occur search), where you get a > buffer with the files matching, together with some context and an easy > way to open a particular file at the point where the match was > found. Something like: > http://picpaste.com/counsel-recoll-mo-uQUXHGey.png OK, so I rolled up my sleeves and made a hack that works just fine (though for the moment it is very crude and most options are hard-coded). In case somebody else wants to try, I just defined the following function in my .emacs (I have ivy/swiper/counsel, ag and recoll installed): ,---- | (defun ag-recoll (string directory) | "Search using ag based on the findings of recoll. Search will be done in a given DIRECTORY, | and the STRING will be interpreted as concatenated by ANDs for recoll and with ORs for ag. | | The idea is that when I search, for example, for 'openacc mpi', recoll will give me all the | files that have those two words somewhere in the file, and ag will find lines that match | any of the terms. | | For the moment this is very crude, and most options to recoll and ag are hard-coded in the | ag-recoll.sh script, most notably that ag will look for a maximum of 10 matches in each file | to avoid huge lists with common searches." | | (interactive (list (ag/read-from-minibuffer "Search string") | (read-directory-name "Directory: "))) | (setq command-string (format "%s %s %s" "/home/angelv/localhacks/ag-recoll.sh" directory string)) | (setq regexp nil) | (compilation-start | command-string | #'ag-mode | `(lambda (mode-name) ,(ag/buffer-name string directory regexp)))) `---- which uses the ag-recoll.sh script: ,---- | #!/bin/bash | dir=$1; shift | ors=$(printf '%s|' ${@}) | recoll -t -b $@ dir:$dir | sed -e "s/file:\/\///" | xargs -d '\n' ag --max-count 10 --group --line-number --column --color --color-match 30\;43 --color-path 1\;32 --smart-case ${ors%|} `---- So, as an example, when I call ag-recoll with STRING 'openacc pgi' and DIRECTORY /home/angelv/Learning, the result is like this: http://picpaste.com/pics/ag-recoll-CdCrnsru.1510144253.png where each line is a hyperlink to the corresponding match in the file, you can use the common grep-mode commands to open a file, go to the next match C-x `, etc. I will be using this from now on, and if I find it useful I will try to make it more flexible (being able to pass arguments to recoll and ag, etc. [I'm a total noob with Emacs Lisp, so any suggestions on how to improve the code are very welcome]. Cheers, -- Ángel de Vicente http://angel-de-vicente.blogspot.com/ ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Emacs interface to Recoll other than Helm? 2017-11-07 15:30 Emacs interface to Recoll other than Helm? Angel de Vicente 2017-11-07 15:37 ` Kaushal Modi @ 2017-11-07 15:51 ` Joost Kremers 1 sibling, 0 replies; 9+ messages in thread From: Joost Kremers @ 2017-11-07 15:51 UTC (permalink / raw) To: Angel de Vicente; +Cc: help-gnu-emacs On Tue, Nov 07 2017, Angel de Vicente wrote: > I've found that there is a Helm interface to it > (https://github.com/emacs-helm/helm-recoll), but right now I'm > using Ivy > (http://oremacs.com/swiper/) and if possible I would like to > avoid > installing Helm just for the integration with Recoll (plus, I'm > not sure > if it will clash somehow with the installed Ivy?). > > Any pointers/suggestions/ideas welcome. I don't know if there's an ivy interface, but I've found that writing an ivy interface for something isn't all that difficult. The ivy manual at <http://oremacs.com/swiper/#api> has the info and some examples. Of course you'll need to know some Elisp in order to be able to do it... -- Joost Kremers Life has its moments ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2017-11-08 12:40 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-11-07 15:30 Emacs interface to Recoll other than Helm? Angel de Vicente 2017-11-07 15:37 ` Kaushal Modi 2017-11-07 16:17 ` Angel de Vicente 2017-11-07 17:09 ` Angel de Vicente 2017-11-07 20:19 ` Bob Proulx 2017-11-07 21:17 ` Angel de Vicente 2017-11-07 16:43 ` Angel de Vicente 2017-11-08 12:40 ` Angel de Vicente 2017-11-07 15:51 ` Joost Kremers
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).