Forum Posts Feed
Looking for information manager that combines strengths of X1, Evernote, TreeProjects, GloboNote, My Notes Keeper, Clipboard Help & Spell,
< Next Topic | Back to topic list | Previous Topic >
Posted by 22111
Nov 13, 2014 at 03:23 PM
Re Tagging
If you’re willing to do tags in file names (be it in the form of original name incl. or plus some key words, or in the form of added codes: #keyword, £keyword, !keyword and similar), you not only will have got “exportable” tagging (which is not the case with most dedicated tag tools), but you also have tremendous possibilities in at least three counts:
- You quickly add new tags in almost any file manager (even FC), by “multi rename” or similar: You control-click files in order to constitute a group (or you search for some common element in their names, then do some fine-tuning by control-click on the result, discarding some, adding others), then batch “rename”, i.e. add a new tag to the group (in most dedicated tag tools, this is not as easy)
- Ditto for further drilling down the tags: You search for some tag, again in almost any file manager, and from the results, you discard (= de-select) any file of which the tag in question is not to be fine-tuned (yet); to the remaining selection, you apply (for visually acceptable filename tags, refer to my post here where I list acceptable tag forms (= nothing new then, but less ugly than most)) the batch rename, replacing the old tag by the new, more specific one (this is a recurrent problem when your file number increases); then, perhaps, you will search for the files with the original tag, and rename that original tag to something more specific, too (ad libitum)
- You can use your usual file manager for finding-by-tag(s), or even some tools like Voidtools Everything (double click on the hit will open the file)
If you absolutely abhor tags in file names, or in general, for additional, useful i.e. accessible (!) info, there’s another free tool, Search My Files (Nirsoft), by which you can even search for files by their ADS (which is more than rare), and there are tools by which you can quickly add/alter ADS data/tags. (And yes, you could do both, writing and reading ADS, by AHK, too, which will only make sense, of course, if you’re willing to script the necessary results pane, too. And yes, it would be easy to shuffle tags from file name into ADS or back, or then, in a little db, or from a dedicated db into the respective file names or ADS or whatever direction you want that add-on info go; if you opt for a dedicated tag tool, make sure that the tags you assign therein will be “exportable”, whatever their target location some day may be: another db, ADS, file name or other multiple virtual folders.)
There’s plenty of ways to group individual files, just take care that assigning tags and tag combinations is as easy and fast, as is selectively (!) renaming, and as is finding them, and don’t accept proprietary, non-exportable tags. (This exportability to other locations is another reason, beyond more precise search results, for choosing “encoded” file name tags: whilst a keyword transfer you will probably have to do manually, transfer of .keyword can be fully automated. And last, if you make your file name tags easily exportable, that will probably help a lot to implement them to begin with in spite of your not being entirely happy with them. And as explained in that other thread here, you could have hierarchies in the like of .a, .aa, .ab…, .b, .bf, .bfo…)
This being said, if you’re more comfortable with monster outlines, trial FLP and its NEAR search option(s) upon them.
Posted by 22111
Nov 13, 2014 at 03:26 PM
There’s another post of mine at the bottom of page 3 which I somewhat hid by the above one.
Posted by 22111
Nov 20, 2014 at 08:07 PM
Re Search
If money is not your priority, enterprise search tools might be a viable solution, e.g.
http://www.toolsjournal.com/tools-world/item/145-10-of-the-best-enterprise-search-tools
You have to distinguish 2 kinds of search:
a) in which file is what (i.e. the search term and its context which) I’m looking for; it’s clear as day that here, non-indexing search tools are near worthless; of course, there’s a variant of this search where parts of file names should suffice (hence the importance of Voidtools Everything and similar), in order to get to the right file (or, as described above, to narrow down the number of files to be searched for their respective context)
b) to which context in my current file (or files group, e.g. if in MS Word, you cut off your manuscript of 10 parts into 10 files) should I jump, for editing that context (given that my search term occurs dozens or hundreds of times throughout my manuscript), with the obvious variant of some more elaborate, compound search term, a and b, a/or b and c, a not c in the “vicinity”, etc.; the beauty of this b) alternative being that here, non-indexing search tools are not really needed
In both alternatives, you would need “hit tables”, and in both alternatives, you would need a tool that is able to search (and in alternative a), to index) your respective file format(s); for alternative b), it’s obvious most people would discard an application (e.g. outliner) if the in-built search functionality does not come with such a hit table, and would therefore consider quite insane that somebody wanted to go back (in my case: literally) from UltraRecall to ActionOutline, for example.
Alternative b)
As described above, both FL Pro and Lite search .ao files as if they were .rtf files, so I get my hit table (and for an ordinary file, in some seconds), but then, as said above, I manually have to enter a more specific search term, from those results, within AO, in order to get to that part in my file I want to edit (or to inspect), because FL (Lite at least) does not allow for selecting a part of a hit line, for then to copy it to the clipboard. (For AO search, I could not enter a and b occurring within the same text line, but of course I could select the given search term in the relevant hit, together with some words before or afterwards, then search that selection within AO, all by macro after the selection having been made by mouse; as said, this is not possible in FL.)
That’s why I looked into FileSeek, and indeed, for alternative b), i.e. for searching just one file (or a little file group), it presents some obvious advantages over FileLocator (Lite, can’t say about Pro):
- it shows you not only the immediate context of your hits, but 1, 2, 3… lines above and/or beneath that hit term line (Pro, 9$)
- it allows for copying any parts of those hits (’ contexts) (even the free version): not in the hit table, but in a display field beneath it (and which in the case of the free version will only replicate the hit line, but copyable)
It’s clear as day that for editing a big manuscript in any text processing environment that doesn’t come with a hit table itself, FileSeek (especially Pro) is of extreme utility:
- you will have two screens or one large one, both tools are visible at the same time
- you search in FS if it’s a common (not rare) search term
- you browse in the hit table (which displays those lines, with their context lines, in Pro)
- in Pro, you even can do a search within search, a thing the developer of FL refuses to do (see the thread on this subject here), to narrow down your hit list
- you select some more words around the relevant hit (even in Free; you could even automate this, i.e. include the selection of the line begin and then of a string of some 40 chars, into your macro)
- you start a macro (see previous) which switches back to your text processor, goes to file begin, calls search, enters the above string (which does not even need to include your original search term), triggers the search…
... and the whole workflow will be almost as smooth as if you had a correct search functionality within your text processing applic…
with the additional advantage that most in-built hit tables over there would vanish by editing one of the hits, or at the very least you would have to jump forth and back within the same applic, whilst your external (here: FileSeek) hit table will remain visible and functional all the time.
Now, what about the file format? Can FileSeek search .ao or other exotic file formats? No and yes (not: yes and no): Rename your exotic file to .rtf, and it will search it (in the case of .ao and in many other cases, I’m sure) as does FileLocator from start on; but in order to do a “live” search, i.e. a search on the (in case, previously saved) file open in your text applic, you can’t rename the suffix?
No problem, just tweak the Win registry (it’s explained in the FileSeek help file). (And yes, keyboard shortcuts are rare for FS, unfortunately (whilst the language setting, once for a lifetime, has got its own shortkey, hilariously), so my FS macros contain lots of mouseclicks into controls, but that’s just another example of the desirable priority of a tool’s or an applic’s core functionality as your “buying” criterion over lesser ones: over quirks that can be overcome by scripting or a 20-bucks macro tool.
Alternative a)
Similar tricks have been discussed for indexing search tools, cf. http://forums.x1.com/viewtopic.php?t=728 (2004) and http://forums.x1.com/viewtopic.php?t=2958 (2007), i.e. an indexing search tool that refuses to index your seemingly “exotic” file, would perhaps index it, more or less, once it will be tricked into believing it’s a “known” format (in fact, a congeneric one); “viewer” problems should not prevail, just a (even cluttered, see above) hit table production will be so much more than you get out of the box. And yes, in most cases, dtSearch would be an immediate solution, hence its price, and its renown (not to mention the beauty of such search tools in general, displaying (hopefully) all the results from various sources for you at the same time).
And yes, doing proper tagging in your filenames will greatly reduce your waiting time if you need to fulfill a) tasks with b) tools (e.g. because X1 “isn’t there” and dtSearch is too expensive).
Posted by 22111
Nov 20, 2014 at 10:14 PM
I misunderstood the term “file handler”, and I did something wrong. In fact, “file handlers” would be third-party programs that would have to be installed; there are NOT registry entries. And, FileSeek searches .ao files, as well as it does .rtf files, without any renaming to .rtf or whatever, and notwithstanding the fact that in the “File Handlers” list in the program, you cannot enter an additional suffix (e.g. .ao”). As for the context lines of hit lines, since those .rtf \par entries get their own line, so often, in order to get (some of) the line above and below, you must show 2 lines above and below, but as said, this context display will not elongate the hit list, but is done in an extra window.
Thus, FileSeek is probably your tool of choice for many a one-file search of files in various formats. (As for searching in file groups, I’ll stay with File Locator, but FileSeek has joined it, and Everything, in my autostart folder, for continuous, concurrent use, each of them providing its respective strengths for particular tasks. Btw it’s extremely difficult, in AHK and such, to maintain an up-to-date repository of your key assignments, your functions, and your applications (= scope for the scriptlets); think about (outcommented) tags in your code, and then hit tables, and search-in-search, again: way better than trying to resolve it with cloned items, db’s and such (this applies to outliners AND to editors).)
Posted by yosemite
Nov 21, 2014 at 03:46 AM
Search can never be too good. Truly instant results, with context, and as-you-type, liberates whole new ways of thinking and working. To me the key is speed. I have used both X1 search and dtSearch in their pricey enterprise versions, at previous workplaces, a couple years back, and they are awesome.
I doubt anything cheap is going to have their power anytime soon. Maybe on Mac - it’s already pretty good and they’ve actually been improving. Windows Indexed search is also pretty good, but they haven’t made any significant improvements in over a decade. I reckon in their push to mobile that search performance will diminish and/or “simplify”, not grow.
I too would love an integration of file manager / outliner / super-search. Maybe someday. But it would be very hard to do, and I don’t think there’s a large market for it. So… expensive.