|
|
Post by Stefan on Jun 2, 2020 8:55:03 GMT -5
Hi George,
Some suggestions about the new DIFF command. It might be helpful ...
- if 1COL | 2COL were allowed abbreviations for 1COLUMN | 2COLUMN
- if ALL | ONLY were allowed abbreviations for DIFFALL | DIFFONLY (also more consistent with other primary commands)
- if DIFF used a named clipboard, like CLIP DIFF or even CLIP DIFF2-4 (for input from tabs 2 and 4) - if the 'Deleted lines' default text colour were one less likely to be chosen as a theme's background colour. For folks who use a black background, the distributed choice (black) leaves large areas of 'space' where deleted lines should be. At first I thought the command didn't work, until I realised the hilighting is customisable. Perhaps pink as a default option?
Observations:
The 2Column view provides a visual indication what happened to which file to create each difference. The hiccup with 2Column view is it's width limitation. Depending on the available width of the window, you cannot 'see' the change if it occurs more than half way along the original screen width. Making the window wider brings a significant performance degradation.
Comparing versions of my dictionary file (approx 35000 lines, average line length is 25 chars, maximum 125 chars), The LOOP DETECTED dialog popped up 13 times with window width at 155 cols. The same comparison with a window width of 330 cols finished the comparison after 22(!) LOOP DETECTED pop-ups.
|
|
|
|
Post by George on Jun 2, 2020 9:51:42 GMT -5
Stefan:
Sure I suppose abbreviations are OK, but since these settings are retained, would you be altering them that often?
Using a named clipboard means a) writing it from the DIFF command to disk and b) reading it back into the CLIP session. I was trying to avoid doing I/O for stuff which is all located in memory already. I'm not sure I want to go this route. Meanwhile if you want to save the results, do a CUT .ZF .ZL DIFF2-3 to save it.
Comments from others?
As to colors, it impossible to choose default colors that will do everybody. I gave up trying years ago. You prefer black screens, I prefer white, others like blue, or green etc.
Timing, hmmm, never tested with such large files, but a first try says there is something holding this back. I believe we're seeing something like the Network file writes, as this is pushing clipboard line counts far further than we've probably done before.
I'll have a go at improving this, meanwhile ..... have to live with it.
The problem with 1Col vs 2Col lengths wont go away, I simply can't overlay some horizontally scrolling 2 column support onto the current screen handling. The best that could be done might be to allow the right hand side only to be 'full-length'. But the left would still be truncated. Otherwise - 1Column mode.
George
|
|
|
|
Post by George on Jun 2, 2020 10:34:43 GMT -5
Robert: I have the =ALL defined as well, just didn't want to use it here. Yes ALL seems to work as well (forgot about it).
I'll have a look at the doc to make sure it's correct.
George
|
|
|
|
Post by Stefan on Jun 2, 2020 10:52:52 GMT -5
Hi George,
I mostly prefer 1COLUMN mode anyway.
It's not not that I wanted to SAVE the results from the DIFF. While playing about with this, I had several open tabs entitled just "(CLIP)". Hard to spot which was which. I figured that as I can issue "CUT Stef" and generate a different clipboard to the Windows standard one, and then issue "CLIP Stef", the resulting tab is named "(CLIP) - Stef". I don't know if under the covers you implement this via file I/O, but if DIFF did the same including the numbers of tabs from whence the data was taken (if it was taken from open tabs) it would usefully identify which (CLIP) session we are looking at, e.g the tab would be called "(CLIP) - 2-4". Even if it just said "(CLIP) - DIFF" would be helpful.
Another thought I've been mulling over was if named Clipboards could benefit being associated with an individual PROFILE setting, e.g "(CLIP) - XYZ" would be treated as if XYZ were the filename extension and thus be matched to a profile called XYZ and even an XYZ.AUTO.
You've written the DIFF logic now, so this is perhaps mute, but I was working on a similar compare function and the display would have used AUTO highlighting. The idea was that a single char in col-1 could be '>' for inserted line, '<' for deleted line and '~' for changed line. The AUTO hilighting is simply using COMMENT1 to 3 for those chars in col-1 to show whichever colour you like. Like you, I figured the clipboard would be a useful temp storage area for the results.
|
|
|
|
Post by George on Jun 2, 2020 11:14:39 GMT -5
Stefan: I'll look at the < > ~ thing. Why would using AUTO support be preferable to the current two custom themes?
Interesting, the slowdown is not in the DIFF code, but the Clipboard handling. I Altered the DIFF code to build the Clipboard string using StringBuilder (like the new WRITE support) and it Cut my loop warnings from 5 down to 2 for my test data, so I added some breadcrumb messages and it now points right at CLIP loading (and eventual freeing) as the bad guys. i.e. I can DIFF two 45,000 line files almost instantly, but the CLIP loading is a disaster.
George
|
|
|
|
Post by George on Jun 2, 2020 12:58:51 GMT -5
OK, the DIFF command on large files now works properly. It was all caused by inefficiencies in clipboard handling. I had to revise DIFF, CLIP and CUT to 'do things better'.
DIFF on 45,000 line files, is almost instantaneous, hitting END on the CLIP session is also almost immediate. I overlooked the fact that a CLIP session places all the data back into the Clipboard.
I think it might be wise to have END of a DIFF CLIP session always do it as a CANCEL, leaving 50K+ lines in the clipboard is probably not advisable.
Meanwhile if you have a large DIFF, doing a CANCEL out rather than END will save you time and avoid leaving large amounts of data in the CB.
George
|
|
|
|
Post by Stefan on Jun 3, 2020 7:59:10 GMT -5
Stefan: I'll look at the < > ~ thing. Why would using AUTO support be preferable to the current two custom themes? Interesting, the slowdown is not in the DIFF code, but the Clipboard handling. I Altered the DIFF code to build the Clipboard string using StringBuilder (like the new WRITE support) and it Cut my loop warnings from 5 down to 2 for my test data, so I added some breadcrumb messages and it now points right at CLIP loading (and eventual freeing) as the bad guys. i.e. I can DIFF two 45,000 line files almost instantly, but the CLIP loading is a disaster. George Hi George,
Re: Performance
I accidentally drew similar conclusions about CLIPboard rewriting & freeing. Comparing my large files, at one point I had three open CLIP session with 40+K lines in each (but of course, only one clipboard). Closing SPFLite with the top right X window control, the whole thing hung up - I had time to make a cup of tea! So writing the data back to the clipboard (3 times!) is clearly slow and, in the case of DIFF results, probably not required.
I was going to suggest that it may be much faster writing the DIFF results to a temp file and opening an edit session on that, rather than use any clipboard. Give it a filetype/extension of DIFF and the AUTO and PROFILE aspects take care of themselves. Only hiccup is, how to delete the file at the end - a part of SPFLite shutdown perhaps? Alternatively, if you do use the clipboard, you could give it a name.
Re: Leaving large amounts in clipboard
When SPFLite reads data from the clipboard into the CLIP session, does it clear the clipboard? If it doesn't, the data is still there regardless of how the CLIP edit session is terminated.
If you used a named clipboard, you could change SAVE/END commands to spot the special case and (1) not do the rewrite (if req'd with a suitable message to the user) and (2) clear or kill the clipboard afterwards, releasing the storage it owns. You can be as draconian as you like because the Windows clipboard remains untouched throughout.
Re: Would AUTO be preferable
I assume your DIFF command sets the hilite colours when writing data to the clipboard, or maybe CLIP does it. I didn't have that option.
Best I could do is to insert a char at the front of the line and use an AUTO file that interprets that/those chars as a 'full line' Comment in the desired colour. Using AUTO in this way means you could distribute a DIFF.AUTO file with the product without the need for changes to the OPTIONS - SCREEN dialog just for DIFF (or other commands that may come along in the future)
(I already have a REXX program which generates a BAT file with loads of comments as well potentially dangerous ERASE commands. It loads that file into SPFLite to allow user review/edit before execution and hilites it using :<somechar> triggers for different colours. In BAT files, the sequence <colon><anychar> is treated as an 'invalid label' and the rest of the line is ignored, ie a comment. So those sequences effectively act as attribute bytes for the SPFLite display, making the file easier to read, while not affecting its subsequent execution.)
|
|
|
|
Post by George on Jun 3, 2020 11:27:16 GMT -5
Stefan: I may explore the File approach. If I create temporary clipboard names starting with an _ , like _DIFF2.3 using the tab numbers, then they'd get cleaned up from the \CLIP folder after 2 days.
Yes, you're right, after loading the clipboard, it is not cleared. I think some extra cleanup code it certainly warranted.
The DIFF command just identifies the line type, the colourization is added when the CLIP screen is loaded.
Would adding the < > ~ chars to the left end of the 1COLUMN display help in any way?
George
|
|
|
|
Post by Stefan on Jun 9, 2020 5:57:23 GMT -5
George,
If you added < (deleted), > (added) and ~ (changed) markers in column1... On it's own, it would help a little, but it would enormously improve readability if the CLIP session for DIFF output could be AUTO colorised, e.g. by a kind of DIFF.AUTO file. Such a DIFF.AUTO file needs just 3 Comment<n> entries. Example below is for a 'black background theme' COMMENT1 1 < 1 DIFF Line deleted
COMMENT2 10 > 1 DIFF Line Inserted
COMMENT3 14 ~ 1 DIFF line changed Talking of colorisation files,... I can't recall if SPFLite ships with an AUTO.AUTO file or not. I found this one useful when editing/creating .AUTO files, because you can 'see' what colour each number represents as you type them.
; SPFLite Colorize file for file type AUTO
;
COMMENT1 11 ; 0
;
DELIMS =
;
; Mark up Scheme numbers according to colour
WORD 1 1
WORD 2 2
WORD 3 3
WORD 4 4
WORD 5 5
WORD 6 6
WORD 7 7
WORD 8 8
WORD 9 9
WORD 10 10
WORD 11 11
WORD 12 12
WORD 13 13
WORD 14 14
|
|
