The No-Alignment-of-the-Rest Problem

[purchase]

Original text from my mixed-up thread :

[ For my problems with large differences within the texts, spanning many lines, and then BC NOT seeming to be able to bring then-identical-lines-again parts of text afterward into accordance again, I cannot bring details now yet since I simply did not get into some rearranging in the original programs yet and thus have not understood yet how to solve these problems for me, manually.

But it seems that BC's feature "x filtered lines" between differences, put up for identical lines, works well for identical lines (of course), and for SOME blank lines only (?), whilst it's not able to compress MANY blank lines "on one side" when there ain't but a few, or NO such blank lines "on the other side".

Perhaps I'm erroneous here, and perhaps I didn't set some option right ??? (see below)


I know that BC - as its contenders - is not able to bring straightforward mixed up "lines" / paragraphs, as XDiff should be. Of course, such a feature would be extremely helpful for a comparison after heavy manual rearrangement / editing of your texts : You'd have your original text, would work on its "architecture" a lot, and then you would like to know, "which paragraphs (from the original text) are maintained in my text as it is today, and which lines / paragraphs / subjects did I delete within my editing process ?".

Please note that I'm not criticizing BC for not having that feature yet, but please comment on your plans of integrating such a feature. If you do not plan to integrate it, I'd accept that for BC's very big value outside of this lacking and would be willing to use XDiff for those special purposes : I know that for most people, myself included, that special need is for very special purposes only, perhpas 10 p.c. of their comparing needs or less. ]


And now for the screenshot you asked me since I did get this problem in a way which makes it easy for me to post the integral (!) screenshot here. So please comment on this, as for me, total beginner with BC, I think (perhaps totally erroneously), that BC should align those items since they are all there, and in the right order, but for those alignments, a lot of blank lines should automatically be inserted ???

Please let me explain : I use BC for comparing trees from different outlining programs, here Ultra Recall and ActionOutline, therefore the "ur" and "ai" parts of the filename. The same problem would subsist, came those files from outlines within the same outlining program, btw.

Since there is / seems to be NOT ONE comparing program that's able to compare outlines (even within the same outlining program, as said), I must do, for comparing, an EXPORT to .rtf format, from both programs, and then compare, within BC, the two .rtf files - that's why I've got so much problems not with real differences (that can be easily searched for then, within the source files) but with BC's "false" (?) differences where all would be well, had BC inserted DIFFERENT number of blank lines into the two .rtf files, thus aligning further identical lines that are NOT different in fact.

But please see for yourself, and please comment. I store those .rtf files, in order to follow your instructions where to look for what elements, or something - perhaps it's all my misunderstanding of how BC works.

But finally, for the screenshot :

[Aaron]

Hello,

Would there be matching lines in between these difference sections? I would suspect that there is a match, which then prevents these lines from aligning with each other.

Do you outlining programs support any export options on the command line? If so, this command line could be plugged into BC3 to run automatically instead of needing to do it manually.

[purchase]

Hello Aaron,

Sorry, my false assumptions. BC works without fault here. One of the two source programs (UR) did mix up the headings in exporting, whilst the item contents were exported correctly. Opening the "Plus" signs within BC revealed that BC did its work like anybody could expect. I have great problems with BC's GUI / user interaction, but its core functioning with text comparing seems to be faultless, up to now. All the differences it shows in the screenshot are REAL differences, by fault of UR, and not pseudo-differences by any "alignment errors" or such within BC - there ain't any !

Both thumbs up!



I'll do comparing from rtf files created by AO in the future, and it does not seem to be able to integrate with BC. BTW, because of the integration of BC (former / light version though it seems) with MultiEdit, I tried ME, and was very disappointed, especially considering ME's price. Several other editors (which I have all bought) work better for me, hence my great interest in your "command line" hint. How such a (partial) integration could be done please, in general? NO : I won't bother you with that now, I see real help for that within the help file that I'll try to understand first! ;-)

[Aaron]

Hello,

I'm not sure if I follow all of the last paragraph, but you can create an Open With (Tools menu -> Options dialog) to execute any command line/external program on your current selection or open files.

You can also create an External Conversion if you were looking to process your text through another program, generate a temp file, and then compare that temp file, all automatically just when opening files of a specific extension.
http://www.scootersoftware.com/suppo...rnalconversion

[purchase]

Hallo Aaron,

I didn't want to rant against MultiEdit, I just wanted to say for less than 200 dollars apiece, I own 3 competiting editors that all do a lot more for me than ME could do.

I don't know if you wanted to give this link with respect to this subject:

Moved Text is Considered Important
or How to sort moved XML nodes in RESX files

but reading that has given me a new idea for my question in the other thread; I asked if it was planned to integrate something like XDiff, i.e. comparing mixed-up paragraphs / lines.

And heureka, your text gave me the idea - I'm eager to share with anybody having had the same problem - that with any decent editor, you can sort lines / paragraphs alphabetically, and once that'll be done (with COPIES of your original files, of course), you can run the usual BC compare. This way, the problem is resolved, and you can see which lines / paragraphs are in both texts resp. which of them are unique to one of them only, and this independently of their respective positions in those texts.

Thus, thank you very much for this (for me) incredibly helpful hint!

[Chris]

You can actually sort directly in Beyond Compare 3's Text Compare. Select "Tools > File Formats". Select the format for your files. In the Conversion tab, change Conversion from "None" to "Sort", then save the changes.

[purchase]

Hello Chris,

Thank you very much for your hint I wasn't aware of.

Of course, my task would be to sort lines first, and to combine files into greater ones, to be compared to other combined one, so in my case all things except for comparing are better done within an editor. It's a rather special problem that even shouldn't exist: I had done distributions of short clippings from big files into special ones, some by copy and paste, some by cut and paste. So in the end, some clippings are well there where I wanted them to be, and only there, some are there, but also at unwanted places, and some others again are where there should not be, without being where they should be.

Now imagine all this not with "some" but with several k of clippings and within a bunch of many files; tries to manually sort that chaos out were unfruitful in the past, of course...

One thing: I'll purchase very soon also since I'm not only up to do a transition from files within one program into another program, and sorting old things out, but I'll need BC in the future for real work, week after week (but I'm happy to have this need for further use since without, I would be tempted at least to not open my purse):

So, and since you're responsive and helpful at Scooter Software, this hint (that might have occured to you indeed, without my mentioning it): You are aware, then, that for such one-time projects like mine, at this moment, the TRIAL version of BC might perfectly do, without a need to buy? Many trial softwares are too much crippled; but the BC trial might be too generous in several aspects! ;-)

[Aaron]

Hello,

If you run with the Sort file format, save and refresh your file (passing it through the sort, again), and re-save, it should re-sort as well.

And, yes, we are aware of our trial.
We want to make sure it is fully featured for our customers to test with, and our time limit is only days-of-use to prevent the countdown clock from shutting down the application before they have been able to sufficiently test it.

[purchase]

Hello Aaron,

1) I'll try.

2) I didn't want to go into specifics, but that's it indeed, I've never seen any other software that could be used for months, for free...! ;-)

3) Here's my (extremely good) experience with that big file transfer (details first, conclusion last):

Procedure:

- As said, I am using BC these days for checking the transfer of about 80k of items, within ca. 150 files, from 1 outlining program (Ultra Recall) to another one (Action Outline which has no import function).

- For this, I copy and paste the (all-items-expanded) tree of each file in prog 1 and paste it into the (empty, except for the root item) tree of a new file in prog 2.

- Then, a macro jumps forth and back between the 2 progs, and within tree and content field in each prog, copying the contents of all items in prog 1 and pasting them into the corresponding fields of prog 2, using the Win clipboard.

- This takes long hours since you must allow for delays between each step, and especially after every "select all", "copy" and "paste" commands (3 sec. each functions well for most items); I run all this on 2 computers, and very long trees (1,000 items and more) I transfer by night.

- After this, I "export" into .rtf format, every such file, from UR and from AO, and then I compare the corresponding .rtf files within BC.

Result:

- UR's .rtf export is virtually without fault (but its tree export feature often mixes up some entries, that's why I build the trees in AO from direct copy and paste from UR trees and not with UR's tree export), but the screenshot above shows one single (!) fault in it:

- The screenshot here shows something really weird, since on the right side (AO = arrival), the contents of many items are the one of the respective preceding (!) items in the left pane (UR = source). That's not extraordinary in such, since if the macro above misses 1 item on the arrival side, that's what will be the transfer result for all further items.

- Digging deeper, though, revealed that the copy-n-paste of the tree itself, from UR to AO, had been left out 1 item (but not its sub-items!), instead of doubly (or not) filling it up on arrival and that's why I had such trouble with that piece of transferred text. So the hint is, also look for possible rare exceptions to the usual problems.

- Many a compare problems arose simply from the fact that AO's rtf export feature is not reliable, so the copied tree (and its contents) is probably ok, but you cannot be sure, and the comparison (between the 2 exported rtf files, not between the 2 real trees) shows false differences (= that do NOT exist between the 2 original outline files).

- AO's rtf export has a lot of problems (but not always) with item titles, so in the rtf files, they are preceded by \par; setting this up as "unimportant diff" in BC will take care of that.

- In other cases, AO exports to rtf some items twice, in order, and then some items later it does it again: Nothing to do about it, except for checking manually within the target file: Are blocks of texts twice, there (AO's export feature being at fault, AO's outline tree being without the unwanted copies).

- In other cases (= especially or only?) after special rtf commands, blocks of text (that are well in UR and in AO's tree) are cut off just in the rtf file; I suspected BC of not rendering well those parts, so I opened the missing parts within MS Word and within a text editor: AO had not exported those parts, BC was just showing all that was there (and not more than that, of course).

- These problems (of AO, not of BC) were aleatoric, and were neither connected with any "special" characters within the texts itself nor with embedded pictures, etc., nore with any formatting: Just sloppy programming of AO's export function.

- In many (all such?) cases, special characters within the original texts caused deep trouble within AO's rtf-export files, making any comparison impossible. Those characters were braces {}, and also brackets [].

- The solution for this was to make copies of the original AO files to work on: Replace all those characters by a single special one, not causing any trouble (e.g. a space), entering the braces and brackets into BC's grammar as "not important" (since they were all left intact in the UR-exported-rtf file), make an rtf-export file from this new AO file (existing just for comparison reasons), and finally compare the UR-rtf file with this special AO-rtf file.

- I had done the compare, not fearing the above-mentioned problems, but a possible problem with my macro. Indeed, with some VERY long texts (or MANY pictures) in those contents field, copy and paste was not successful, but the content of the preceding item was put within a text field in AO then. Yet, I had overestimated this problem which didn't occur but less than 10 times, for 80k of items. (With macro delays of 10 sec instead of 3 sec, I would perhaps avoided this problem altogether, at a cost of 3 times the transfer time.) This shows that, given a minimum of processing time for selecting, copying and pasting, the Win clipboard works like a charm.

BC in that:

WITHOUT ANY FAULT WHATSOEVER, every time I think BC could have "read" some rtf command in any faulty way, rendering the results not correctly, I dig deeper, and finally, EVERY time, BC has rendered all things exactly the way they are, whereas the problems lay elsewhere: Be the situation as weird as it wants, BC correctly SHOWS all given problems, and does NOT CREATE any problem whatsoever.

After having done such a big project with BC, I post my experience for 2 reasons:

- Yes, transfers of such a big size can "manually" (= by simple macro that is) done, and can then be checked with BC:

- Yes, BC is FAULTLESS, even within such big projects (and within a format like .rtf which isn't that easy at all, as AO's often failing export proves), and is hence your reliable assurance you'll get your transfer done without fault. (And BC's speed is tremendous.)

[purchase]

1)

I'm now trying to compare lists.

One list is alphabetical; I put it into pane 1, by clipboard.

The other list is mostly identical with the first one but in aleatoric order; I need to check for any differences. So I put it into pane 2, by clipboard.

Of course, BC tries to compare those lists, 1 line by 1, which is totally unfruitful. Since you told me that BC can sort, I search buttons, menu entries, right mouse click menu entries, and the help file, for a sorting command, but I cannot find any hint; searching the help file for "sort" brings some column things I don't understand, but nothing I can use for sorting the content of pane 2.

So, for this time, I go back to my editor to sort the list, copy the sorted list from there, and then compare within BC.

For next time, what should I do, to profit from BC's in-built sorting capabilities?

2)

Seems I've encountered a missing function in BC (I've got a tendency to do so in every program I work with):

So I import my second list into pane 2, and look for differences. Then, what I want to do, is quite naturally do a control-a, control-c in pane 1, in order to just get those differences, into another file, i.e. I want to put the lines that are in file a but not in file b, but only those, into the clipboard, for further processing.

Of course, my control-a does not only select the visible lines (with the button "show differences only on", but the whole text in pane 1, i.e. ALL lines of that text, so there would be a special command needed for doing such a "comparison by subtraction" within BC, and that's not there?

Or then, a sort command, in the way of, "put all different lines within the two files on top, while pushing all similar lines to the end" - that way, the differences would form a BLOCK on top of each respective pane (let's say, first the block of pane 1, then the block of pane 2, the lines within each in original or in abc order), and those blocks could then be selected and copied into the clipboard.

Do I miss functionality of BC, or can there be done something in this way, at this moment?

(Since my list comparison with BC fails totally up to this point, I must try to do that comparison within a programmable editor, perhaps: Searching for lines 1...1000 of file a, in lines 1...1000 of file b, deleting each line in file b if there's a hit, i.e. identity of the lines. But I naïvely thought that task was easy for a compare program.)

Please comment.

[Aaron]

Hello,

For point 1: Use the "Sorted" file format. This can be done on each pane individually by clicking the file format name in the pane's status bar (probably "<default>"?), or by clicking the dropdown arrow next to the File Format button, next to the Rules button, and selecting it for both panes, or by using the Session Settings dialog, Format tab.

For point 2: You will want to use the Display Filters to show only the text you want to copy/paste. Ctrl+A will only select the visible text, so you can Ctrl+A, Ctrl+C the visible text once the display filter is set to Only Differences (or Only Left Differences if you right click the Display Filters and set to Toggles).

[purchase]

Hello Aaron,

Thank you very much for these hints. Didn't see your answer (page break between page 1 and page 2), got discouraged. These are important features, will try again - did a lot with editors in the meantime.