You could save bookmarks as .url files on your computer and put tags in the url file names.
FARR and FARR aliases can then be used to search among those bookmarks.
Long ago I made the tool Tourl to do just that.
Two caveats:
- 1. to be able to search not only the title of the bookmarked page but also its url you need to put (parts of) the url in the filename. Tourl has hotkeys for doing that.
- 2. Tourl is old, maybe some parts of the code need an update to run with the latest version of Autohotkey. But you can try it out and the source is included in the download.
-Nod5
This comment caught my attention because it referred to some of the things (including capture and linking of content, keywords and bookmark/URL) that I was after in this request:
Feature request: select/display Grid column data > horizontal rows in Memo pane. (Though I did not specifically state in that post what my requirements were.)
I am intending to use CHS (Clipboard Help & Spell) as my de facto bookmarks database for all browsers.
The background to this:My view is that bookmarks are arguably an archaism. They were probably undeniably a "good idea" - and quite useful too - for whatever our "requirements" were construed to have been
at the time they were invented, but they would not seem to have really evolved all that much since then to meet what our requirements might have evolved into today. In other words, bookmarks would seem to be more of a customary hangover from the days when our requirements were otherwise than what they might be today.
Nowadays though, look what happens when I, for example, bookmark this page in Firefox: (press Ctrl+D)
This current manifestation of this bookmark form in Firefox v38.0 Beta includes:1. A field containing the string "page name" (data captured at this point) for edit/acceptance.
2. A field containing the string"URL" (data captured at this point) for edit/acceptance.
3. A field displaying the Folder name for storing the bookmark (the user either accepts the default or selects another folder).
4. A field for entering string(s) for "Tag name" - an optional data entry/edit/selection field.
5. A field for entering string(s) for "Keyword" - an optional data entry/edit/selection field.
6. A field for entering the string "Description" - the
de facto page subject name, with optional data edit/entry.
This website page bookmark data/metadata is stored in a proprietary Firefox bookmark database, which is apparently different to the proprietary IE bookmark database, which is apparently different to the proprietary Google Chrome bookmark database, etc.
Since one may understandably wish to use
the same bookmarks in the same browser but using
different PCs in different physical locations, or across
different browsers in the
same or
different PCs, then there is a potential problem - in that this is a recipe for potential bookmark duplication, loss and confusion.
The problem is compounded when one realises how one has to use
a search system peculiar to each browser if one wants to access those bookmarks in those proprietary browser bookmark databases. Then, of course, there's the problem of syncing or backup/recovery of those proprietary browser bookmark databases. It's all a manmade PITA, but at least it's avoidable - which is why I pretty much abandoned the use of those proprietary browser bookmark databases, though they are useful for my children's browsing.
I refuse to accept being locked-in to any given browser like that, as I use up to 3 browsers, and I want to be able to
standardise the use of bookmarks across browsers, without having to worry about tripping over duplication/loss, differing standards or other idiosyncrasies.
Thus, one of the objectives of my CHS feature request (above) is that one could perhaps start to move towards having a "browser-agnostic" bookmark database holding a common set of bookmarks for all browsers to use.
Certainly, CHS would seem a logical tool to capture the bookmark data and store it, and as for accessing it for use in a browser, then possibly (say) FARR could even be the medium of access linking to CHS for this database. There is after all a "set" of DC tools that could possibly be integrated to provide the required functionality to meet a given requirement:
For example:
Re: Feature request : input field...
let me consider the possibility of having chs interact or hand off to another tool as it pastes -- that might make it easy to do what you want and keep chs from getting over complicated.
-mouser
I thought this looked very positive.
We shall see.
