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.
- 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.
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
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.
I thought this looked very positive.
We shall see.