|
Post by George on Dec 31, 2023 12:17:50 GMT -5
Stefan: I agree that (Comments) must handle paired comments better, I'll tackle that.
Same for (TabShift). I think both suggestions are appropriate. 1) If remaining cols to next tab stop are blank, just do a (Tab), and 2) It should assume a DIN mode.
Now the PA2 type 'undo' - afraid not, PA2 reverts to the previous state after an Attention interrupt. Your examples COPY/PASTE/etc are all done at Attention time, so they are 'covered' by PA2.
George
[UPDATE] Posted a new Beta with the (Comments) and (TabShift) changes.
Have a go.
[/UPDATE]
|
|
|
Post by Stefan on Dec 31, 2023 15:35:24 GMT -5
George,
As I said re (TabShift) - I'm not yet sure using 'DIN' mode is an improvement over the present 'INS' mode during the shift. It might throw up other issues.
I'll try the new beta next year
However, regarding (PA2)...
To avoid any confusion, the MARK/COPY/PASTE to which I referred are the keyboard primitives, not the Primary COPY or PASTE commands. e.g. Select/hilite some text with a mouse drag Press Ctrl-C - (Copy) primitive
Reposition the mouse Press CTRL-V - (Paste) primitive Press PAUSE - (PA2) primitive and the pasted text will disappear
Actually, I've just realised that the above is only partially true. You can use (PA2) to toggle 'undo'/'redo' the (Paste) primitive, BUT NOT if the (Copy) area rectangle selected text on more than one line.
Anyway, are you sure about (PA2) "AFTER" an Attn interrupt? I'm pretty sure the (PA2) primitive (like the 3270 RESHOW key) only works BEFORE the Attn Interrupt.
e.g.
1) Open a file in EDIT 2) Overtype one or more lines with nonsense characters
3) Press (PA2) key and the original text reappears - no harm done. Repeated (PA2) toggles between the nonsense and the original text.
But 1) Open a file in EDIT 2) Overtype one or more lines with nonsense characters 3) Press <ENTER> key, i.e generate an ATTN interrupt 4) Press (PA2) key and nothing changes.
So it seems to me that (PA2) can get you out of jail BEFORE an ATTN Interrupt, but you need to use the Primary commands UNDO and REDO to do the same AFTER an ATTN interrupt.
|
|
|
Post by Stefan on Jan 1, 2024 13:33:47 GMT -5
Hi George,
Observations with beta version 23365 (COMMENTS) primitive(Case 1) Fixed. */ closing marker appears in correct columns.
(Case 2) Fixed. */ closing marker is added for lines with existing text
(Case 3) Odd things... When user inserts more text which bumps the /* start marker along, a subsequent (Comments) 'restructure' places the start of the comment block at the next available tab stop. All Good! However... 1) The */ end marker also moves right beyond col 89 by the same distance, even if the entire comment block is blank. Suggest: The 'bump right' process should use DIN mode, not INS mode.
2) If the user presses (Comments) key repeatedly, the */ end marker keeps moving right. 3) If the comment block is 'dragged left', the */ end marker moves with it by the same amount. If the end marker was IN or BEFORE col 89, it is placed in col 89. All Good! But if it was beyond col 89, it does not assume its place in col 89 even when there are enough trailing-blanks within the comment to allow it. Suggest: Always place */ end marker in col 89 unless comment-text is too long to allow this. If so, place */ at the end of the comment text.
4) If the text part of the line ends in the column before a tab stop, (Comments) will place the /* starter marker immediately adjacent to (i.e. touching) the end of the text. Thinking especially about users who do not use AUTO-Hiliting, it might be better to leave a gap after the text, and place the /* comment marker at the next available tab stop.
(TABSHIFT) primitive Works much more predictably now that it behaves like (Tab) when there's blanks between cursor and the next Tab stop. It does not appear to use DIN mode, but I am glad that it doesn't.
This image shows a file with data in evenly-spaced columns - the sort of thing I had in mind when I suggested TabShift. Imagine using (TabShift) with the cursor at Line 000097, col 16, ie under the +S.
With INS mode, +S shifts to col 24 and all other columns get bumped along by the same amount. All neat and tidy.
With DIN mode, +S shifts to col 24, which would now contain +S +ED, with the remaining columns unchanged.
Depending on the length of the data in each column, DIN mode would get very messy indeed. So INS mode is really helpful here.
I appreciate that some may deploy (TabShift) to bump the /* comment */ block along by one tab stop. With (TabShift) using INS mode, that shifts the */ end marker beyond col 89. It's no big deal, because one press of the (Comments) key will rectify the effect, assuming there are sufficient trailing-blanks within the comment.
|
|
|
Post by George on Jan 2, 2024 12:22:19 GMT -5
Stefan: I think I've addressed all your points. Check out Beta 24002
George
|
|
|
Post by Stefan on Jan 5, 2024 11:01:58 GMT -5
Hi George, (COMMENTS) Primitive Case 3 - item 1,2 and 3 are addressed. Thank you - Item 4 remains unresolved. "If the text part of the line ends in the column before a tab stop, (Comments) will place the /* starter marker immediately adjacent to (i.e. touching) the end of the text.
Thinking especially about users who do not use AUTO-Hiliting, it might be better to leave a gap after the text, and place the /* comment marker at the next available tab stop." Although neither BASIC nor REXX do, some compilers/interpreters may not recognise the comment and throw up an error.
This screenshot may help.
The profile is using COMMENTS 1 55 5 89
Line 000164 shows the placement BEFORE the (Comments) primitive is executed The 'xxxxx' text part ends in column 54 and the /* comment string starts in column 58.
Line 000165 shows the effect AFTER the (Comments) primitive was executed
- The (Comments) primitive has place the misaligned comment by placing the /* in column 55, i.e touching the xxxxx text. I think if the byte immediately before the tab stop (col 54 in the case) is not blank, the (Comments) primitive should place the comment at the next tab stop (col 60 in this case)
|
|
|
Post by Robert on Jan 5, 2024 11:11:42 GMT -5
Issues with 24.003 beta
George,
1. While editing the clipboard with a large file (13,000 lins) I got a crash:
SPFLite V(3.0.24003) @ 2024-01-05 11:01 SPFLite has encountered an execution exception (C0000005)
Last Interactions were: K=BACKSPACE K=BACKSPACE K=ENTER K=CLIPCLEAR K=HOME K=ENTER P=CLIP K=HOME K=ENTER P=COPY 'D:\_ADKATT\_KLD\A..ADKATT.KLD' K=ENTER P=undo K=ENTER P=redo K=NEWLINENS K=NEWLINENS K=ENTER L=TR 2 13932 0 32 . TR 2 13932 0 32 . K=ENTER P=UNDO Module Back Trace: 05 PCMDUNDOREDO 04 CMDASSIGN 03 POSTKEYBOARD 02 MAINDKEYPROCESS 01 MAINCDOKEYSTRING 00 REALPBMAIN
2. While editing the clipboard, and issuing a few line commands like TR/ I got a warning that the UNDO file names were corrupted.
3. While trying to issue a primary-command macro, I got an error that the command was not found. Doing a PRO display, I see that the MACLIB entry was populated with the full path name of my MACRO folder, which for me was C:\Users\Owner\Documents\SPFLite\MACROS
When I switched to production SPFLite 23.313 which had MACLIB NONE in effect, the macro now worked. As this changed the profile in question, when I went back to the beta, the macro worked there also.
R
|
|
|
Post by George on Jan 5, 2024 11:45:58 GMT -5
Stefan: Thought I had handled that, but not quite. Changed a > to >= and all is well. It now properly moves over to the next Incr position.
George
|
|
|
Post by George on Jan 5, 2024 12:13:56 GMT -5
Robert: Well, what I see 1st is an seemingly Well, that's an odd set of commands
Clear the clipboard CLIP (which would have started a new CLIP tab with nothing in it) COPY a file into the empty CB UNDO that copy REDO the UNDO TRIM all lines UNDO the TRIM
Somewhere in all the UNDO REDO UNDO processing there's a bug. And I have a snowball's chance in Hell of finding it.
I can chase the MACLIB handling, it's hard to picture how the filename got into the PROF, but it sure looks like a bug.
George
|
|
|
Post by Robert on Jan 5, 2024 14:29:37 GMT -5
The commands are the result of running a macro I wrote called FCLIP, which I use to directly copy a file from an FM list to the clipboard. FYI here it is:
' FCLIP.MACRO ' ' This macro allows you to copy a file to the Windows clipboard from a line-cmd field in FM. ' SPF_Loop_Check(0)
USES "FILE"
IF is_fm = 0 OR is_line_cmd = 0 THEN HALT("FCLIP must be entered in an FM line cmd area")
DIM Fnum AS LONG = VAL(Get_Arg$(1)) DIM Fname AS STRING = FMGet_FileName$(Fnum) DIM Fpath AS STRING = FMGet_Path$(FNum) DIM fullname AS STRING = Fpath + Fname
// make sure file really exists. if it didn't it would be weird IF FILE_Exists(fullname) = %False THEN HALT("FCLIP file does not exist ?")
SPF_Post_Do("(ClipClear)(Home)(EraseEOF)[CLIP](Enter)(Home)[COPY '" + fullname + "'](Enter)") HALT(0) R
|
|
|
Post by George on Jan 5, 2024 14:36:39 GMT -5
OK Robert, thanks. Hopefully I can duplicate the crash. Although I'm sure you've used this macro many times with no problem.
George
|
|
|
Post by Robert on Jan 5, 2024 14:50:34 GMT -5
The macro works correctly in prod 23.313 release. It only failed under the new beta.
Now that you can see the macro code, do you see anything in it that I did wrong?
R
|
|
|
Post by Robert on Jan 5, 2024 16:37:42 GMT -5
The fact that I got one of those "UNDO file name is corrupted" messages suggests there is some lurking bad code that is stepping on memory somewhere. In other words, another nightmare debugging session. Sigh.
R
|
|
|
Post by George on Jan 7, 2024 10:11:17 GMT -5
Robert: FCLIP works just fine here, I can't get a failure.
There is a minor error. (EraseEOF) should be (EraseEOL). I noticed the visual Beep when it ran, so searched for what triggered it.
Is there a lurking bug? Very likely. But with any bug it becomes the old "If it can't be repeated, it can't be found". Scanning code for stuff like this just doesn't work.
George
|
|
|
Post by Robert on Jan 7, 2024 10:47:42 GMT -5
Wow, I never saw that EraseEOF typo until you pointed it out. Will correct and see if any issues reoccur.
R
|
|
|
Post by Robert on Jan 7, 2024 11:52:23 GMT -5
I retried the (corrected) FCLIP on a file about 5000 lines long, using the 23.313 prod version, and again got the File Names in the UNDO control area do not appear to be valid. So, whatever is going on is not new to the current beta.
R
|
|