I started this thread as a derivate from this Smart Edit thread, since indeed, KEdit is a very interesting (but not too much known) thing:
https://www.donation...ex.php?topic=33574.0EDIT: I just found this intro pdf:
http://www.wolffinfo...hes%20(DATABASE).pdf - and they ain't called "Russian editors" but "Eastern Orthodox editors"
They don't develop it further and say so - no unicode / UTF8 -, but some weeks ago, a minor update has been released (1.61., from 1.60). It costs 129 bucks (not the update!).
It's the commercial version of the "Russian editor" type (XEdit / Rexx and their emulators), i.e. the one that permits to work on "subsets" of your lines (so you can have the same functionality for free, with some competitors, never trialled those though) - it's similar to, but not identical with, a "folding editor", or more precely, it IT a folding editor, but which on top of folding, allows for folding cascades.
I trialled KEdit, was very intrigued by this concept. Let me explain:
- you say you just want all lines with "abc" in them
- then you get a result in which you work as if the whole text didn't comprise but these lines (so it's different from a search results table as in askSam or in an editor like TSE): it IS a search results table, but you work within the "search results"
- now you say you just want all lines withOUT "xyz" (with the "more" command, cf. the "less" command below)
- so you'll get a SUBSET of the previous thing, i.e. since you didn't revert to "whole text body" before, you're now with the subset "+abc -xyz"
- you can do this in cascading style many times (don't know if there is a limit to this cascade)
Now for the problems (and that's why I didn't buy it), PLEASE CORRECT ME IF I'M WRONG:
1) You can't easily get back in this cascade: first result, "all abc lines", second result, "all abc lines without xyz in them" - now, in order to go back to "all abc lines", you have to revert to "all lines", then you opt anew for "all abc lines", or you do the "less" command.
Of course, in this example, this is not a real problem, but then, if within a cascade of 5 or 6 such subsequent subsets, you want to go back from step 6 to step 4 or step 3 (e.g. for then doing different subsets from that point on): helluva!
2) Similarly, within such a cascade of refining your "search" / "selection", even without going back, you'll get lost, early on, i.e. with KEdit, you always will have a legal pad near your keyboard, on which you'll write down your refining cascade by hand - that's really a pain in the youknowwhere. Ok, some people might be able to memorize their 5 or 6 consecutive steps here; I get lost in step 3, or even in step 2 if my multitasking capabilities had been in demand in-between.
3) You can only do one subset at a time, meaning, you cannot enter "(+abc -cde) / (OR) ( (+ ijk) OR (+lmn) ) or such, whilst you can do exactly this in a prog like askSam.
Such a feature would have resolved both the above-mentioned problems 1 and 2, since you'd have your search code within the command line, and you'd made adjustments of your "search" command there: would be good both for "going back", as for "remembering the current state". Cf. the askSam search line which works exactly this way.
In fact, you CAN do it by command line, in KEdit, in the style, e.g.
"ALL ~WORD /abc/"
which means, "all lines not containing "abc" as a word (irrevantly of "abc" as part of a word). But you CAN'T COMBINE such commands in your command line, and that's big problem.
4) As with every "folding editor", you only see the lines in question, whilst for many tasks, you'd need the text beneath those lines. In askSam, e.g., you can put the hit table into one window, select hits there, edit the "lines beneath" (= the respective records) within your main window, switch back to your hit table, select another line / record there, etc. (Of course, you can have your hit table beneath your records, or to the right of them, but in this latest variant, buy a large screen in order to "get" the context of these lines, so a second screen for this is perfect for making heavy use of this feature.)
It's MyInfo 5 that had found a really very clever solution to this problem: In fact, MI, in version 5 - well, that was 2 years ago... -, it had a unique feature, allowing for appearing, by option, two more subsequent lines (regular style) beneath each search result line (bold). Thinking about it, you'll quickly grasp that this not only made MI 5 rather suitable for programming needs, but especiall for client db's, and such: Knowing you've got such a fine feature on your fingertips, you'll do the very first 3 lines of your clients' / prospects' records in a special, so a to search for content within line 1 of these records, then have specific content even within your hit table, and not only after going from there into specific records.
So this was a (rather hidden) gem of MI 5 (that the developer didn't even advertize, whilst it was unrivalled (is there similar function in other sw? please tell me!) - and from MI 6, it's absent, the developer saying it will be back some day. (So much for using sw from a 1-developer venue for your business.)
MI has got other details that are much better than the corresponding solution (if there is any) in UR, and people have understood this lately: UR's forum is as dead (if you do abstraction from my posts there) as MI's forum has been a year ago: With absence of UR development, and MI going steady (if slow indeed), more and more people go to MI, and I certainly don't blame them. (UR will - AGAIN - be on bits in some days: it's becoming ridiculous: with a little development on their side, they could easily sell UR full price instead.)
5) Minor problem, but a very ironic one: For its outstanding "subset of lines" feature, i.e. its "USP", KEDit does NOT have any keyboardcut, so you must do a macro activating the menu. This would have been really easy to implement, and this absence is ridiculous: Yeah, hide your best feature, make it difficult to reach. (Ok, not really difficult for us macro / AHK users, but you see what I mean.)
So where's the real advantage of KEdit? It lies in its facility to directly EDIT these "hits", as said above, and this means, it's not so much suited for programming and data mining (whilst that's a little bit its false "promise" though (I mean, seeing that feature, your first idea is to use it in this big way, then realize it's not possible, for the problems listed above), but for text editing, for writers (!!! hence your find!) and for translators, editors of texts written by others, etc.:
In fact, you search for some search term, or even for some synonyms ("abc OR def OR ghi"...), and then, you edit some of them, right within the "hit table" you'll get, no need for switching back and forth between search results and real text, as in programs of the other kind (AS, TSE, UR (Ultra Recall), MI (MyInfo) and many more). At the end of the day, THAT's the real purpose of this program, and in this task it excels.
Again, if there are errors in my description, please correct me, since that would mean that KEdit's range of usefulness would be far greater than described above.
(If you trial KEdit, know that you can filter the lines in the form hitline, hitline, hitline, or in the form hitline, "x lines not displayed", hitline... - the latter is default, and it makes it ugly (and I don't have the slightest idea in what task this feature might be of use) - but you can do without and then have much cleaner results.)
(You also can do subsets by "selection level", but it doesn't seem to be possible to combine this with the filtering above, so I don't think you'll get specific headers, together with their text body, as you (partly and cleverly made) got in MI 5 (point 4 above), and as for "selection level alone, I didn't find a task in which this feature'd make sense for me. Theoretically, the "selection level" command is very clever, but I couldn't find a way to assign a certain selection level to a certain "more" command, i.e. you do a "more" command, then could do a "set selection level" command, but not, it seems, just for these "more" hits / lines, i.e. the "selection level" setting then would mix up those "new" lines with the old ones, i.e. assign the same selection level to all of them, which is not what we would want. AND the "selection level" is line-specific, not group-specific, meaning you cannot use it to have "+abc" = sl1, "more def" = sl2, and so on - such a function could come handy, but doesn't seem to be there - so in the end, I never understood what they think "sl's" might be meant for.)
(And yes, instead of filtering lines, you can have marked them yellow, i.e. see the hits within the global context.)
Can't read John McPhee's New Yorker 1/2013 article on KEdit, since the link is for subscribers only, and buying the issue, here in Europe, wouldn't cost me 6,99 but 25 euro or something, magazine prices triple and quadruple over the Atlantic - but perhaps he explains even better than I did why for writers / editors, i.e. certainly for specific POST-PROCESSING tasks of long texts (technical as well belles lettres), KEdit is indeed a hidden gem.
P.S.: A last hint: Such plain text editors make you lose any traditional previous formatting, which certainly is not acceptable. So there are two solutions: Working with mark-up codes from the beginning, or doing the export to html (from Word / .rtf / any formatted text), then working on this intermediate text from then on. "Post-processing", I said. Btw, it's easy to do a macro that will re-code your ugly html codes "back" into some more pleasant to the eye, e.g.
from <b>bold words</b> or such (sorry this line resolved into bold text here, but you know the <> coding)
to |bold words|| or such,
then work on this text, then have another macro doing the back-to-html transposition (the same would apply to traditional publishing: from formatted text to html (since that export is often very stable when export to .rtf isn't necessarily stable, not to speak of either's product's respective neatness), then macro translation into "intermediate mark-up" (with which you can live visually), then post-processing, then macro translation to the respective codes for PageMaker, InDesign, Framemaker...), but this formatting issue is certainly the reason why goodies like KEdit remain exotic and ain't further developed.
