[emacs-w3m:13852] [emacs-w3m/emacs-w3m] Ideas for making search engines more powerful (#107)

----==_mimepart_6148a6fd50ec8_375ac7603217a4
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

I've been playing with the search engine features of emacs-w3m recently and I'm really enjoying them, but I have some ideas on how they could be improved. Some of these are related, and so rather than open many separate, interdependant issues, this is a dump of my thoughts, which can be hopefully be teased out into something more definite based on the following discussion. 

I define quite a few of my own search engines, and for all of them I also define an abbreviation. This means modifying both `w3m-search-engine-list` and `w3m-uri-replace-alist`. The format for the first list is not obvious. I think it would be better to have a single method for defining a search engine, which could work something like this:

```elisp
(defengine DuckDuckgo
	   :action "https://lite.duckduckgo.com/%s"
	   :coding utf-8
           :description "The search engine that respects your privacy"
	   :abbreviation "ddg")
```

Only the `:action` field would be mandatory. It could also be possible to specify a different `:name` field, providing a string to display search engine with, though this would default to the string of the symbol used in the def (`DuckDuckgo`). The `:abbreviation` would be automatically handled for use in `w3m-uri-replace-alist`. It might even be possible to define a global function which generates a default abbreviation from search engine (e.g. the shortest unique prefix of its name). Using a more structured approach to defining engines in the first place would make more complex stuff like this easier I think.

Personally, I would also find it useful to have a `:description` field, separate from the name of the engine. This would be a sort of docstring for the search engine, expected to span multiple lines and maybe include minimal markup (like actual docstrings). This would be displayed in a function `w3m-describe-search-engine`. It might be useful to have a similar `describe-search-engines` (plural), which lists all currently registered engines and gives some minimal information (a bit like `describe-repeat-maps`). Not everyone might find this particularly useful though, so it could be optional, like docstrings in `defun` declarations.

Finally, I think it would be great to include some support for history and/or suggestions in search engines. There are lots of ways this could be done: a good start might be being able to specify a different history file (`:history-file) for each engine, and maybe the format history is read and written in. Then there could be a few different functions available for generating lists of suggestions (specify which one the engine uses under ``:suggestion-functio`)`, some of which could use the history. This would allow for things like frecency suggestions to be implemented.

Most of the optional fields would have global defaults which could be set in customizable variables, so that the behaviour of *all* engines could be changed without having to set them all manually (e.g. if you wanted to keep all of your history in one file, or only use search engines with a certain, non-standard coding (!?)).

I have some ideas about implementing most of this, and would be happy to take it on as a project to improve my elisp a bit.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/emacs-w3m/emacs-w3m/issues/107
----==_mimepart_6148a6fd50ec8_375ac7603217a4
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

<p></p>
<p>I've been playing with the search engine features of emacs-w3m recently and I'm really enjoying them, but I have some ideas on how they could be improved. Some of these are related, and so rather than open many separate, interdependant issues, this is a dump of my thoughts, which can be hopefully be teased out into something more definite based on the following discussion.</p>
<p>I define quite a few of my own search engines, and for all of them I also define an abbreviation. This means modifying both <code>w3m-search-engine-list</code> and <code>w3m-uri-replace-alist</code>. The format for the first list is not obvious. I think it would be better to have a single method for defining a search engine, which could work something like this:</p>
<div class="highlight highlight-source-emacs-lisp"><pre>(defengine DuckDuckgo
	   <span class="pl-c1">:action</span> <span class="pl-s"><span class="pl-pds">"</span>https://lite.duckduckgo.com/%s<span class="pl-pds">"</span></span>
	   <span class="pl-c1">:coding</span> utf-8
           <span class="pl-c1">:description</span> <span class="pl-s"><span class="pl-pds">"</span>The search engine that respects your privacy<span class="pl-pds">"</span></span>
	   <span class="pl-c1">:abbreviation</span> <span class="pl-s"><span class="pl-pds">"</span>ddg<span class="pl-pds">"</span></span>)</pre></div>
<p>Only the <code>:action</code> field would be mandatory. It could also be possible to specify a different <code>:name</code> field, providing a string to display search engine with, though this would default to the string of the symbol used in the def (<code>DuckDuckgo</code>). The <code>:abbreviation</code> would be automatically handled for use in <code>w3m-uri-replace-alist</code>. It might even be possible to define a global function which generates a default abbreviation from search engine (e.g. the shortest unique prefix of its name). Using a more structured approach to defining engines in the first place would make more complex stuff like this easier I think.</p>
<p>Personally, I would also find it useful to have a <code>:description</code> field, separate from the name of the engine. This would be a sort of docstring for the search engine, expected to span multiple lines and maybe include minimal markup (like actual docstrings). This would be displayed in a function <code>w3m-describe-search-engine</code>. It might be useful to have a similar <code>describe-search-engines</code> (plural), which lists all currently registered engines and gives some minimal information (a bit like <code>describe-repeat-maps</code>). Not everyone might find this particularly useful though, so it could be optional, like docstrings in <code>defun</code> declarations.</p>
<p>Finally, I think it would be great to include some support for history and/or suggestions in search engines. There are lots of ways this could be done: a good start might be being able to specify a different history file (<code>:history-file) for each engine, and maybe the format history is read and written in. Then there could be a few different functions available for generating lists of suggestions (specify which one the engine uses under ``:suggestion-functio</code>)`, some of which could use the history. This would allow for things like frecency suggestions to be implemented.</p>
<p>Most of the optional fields would have global defaults which could be set in customizable variables, so that the behaviour of <em>all</em> engines could be changed without having to set them all manually (e.g. if you wanted to keep all of your history in one file, or only use search engines with a certain, non-standard coding (!?)).</p>
<p>I have some ideas about implementing most of this, and would be happy to take it on as a project to improve my elisp a bit.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">&mdash;<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/emacs-w3m/emacs-w3m/issues/107">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/ALIUPN5CY4TWZGNQ3IHIL7LUC5GP3ANCNFSM5EMGPB7Q">unsubscribe</a>.<br />Triage notifications on the go with GitHub Mobile for <a href="https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&amp;mt=8&amp;pt=524675">iOS</a> or <a href="https://play.google.com/store/apps/details?id=com.github.android&amp;referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub">Android</a>.
<img src="https://github.com/notifications/beacon/ALIUPNZSRT3NKNHJHUWUIYDUC5GP3A5CNFSM5EMGPB72YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4O5LROLA.gif" height="1" width="1" alt="" /></p>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/emacs-w3m/emacs-w3m/issues/107",
"url": "https://github.com/emacs-w3m/emacs-w3m/issues/107",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>
----==_mimepart_6148a6fd50ec8_375ac7603217a4--