|
Post by George on Dec 19, 2023 15:37:40 GMT -5
Robert: I can guess what you're thinking. Profile data should be loaded and updated globally and then shared with any tab that needs that profile. That way everyone is using one consistent version of the Profile
No, absolutely never. If I'm playing in one tab switching stuff like SOURCE from ANSI to EBCDIC and visa versa (or any other Profile values), I sure as h*ll don't want any other tabs that happen to be open and using the same profile to 'accidentally' pickup any of my 'playing around' profile changes. Those playing around changes are just that - temporary playing around that I will 'undo' before shutting that tab down. And if I forget and leave some temporary changes in effect, that's my problem, not a problem caused by some built-in, automated propagation of changes to all active tabs.
Forget this one.
George
|
|
|
Post by Stefan on Dec 20, 2023 6:45:50 GMT -5
Robert, George, I'm still working on testing the latest beta. Robert has done a champion job so far. I also noted that the status line field for OVR/INS/... etc was too small and increase it from 4 to 8 chars. If that's too much for some screens, perhaps we could consider shortening the "TAB" part to "TB" and save a char position.
Quick explanation about why I requested (TabBNDS) as a profile setting. The entire TAB insert mode feature set is most useful when editing a file consisting of columnar data. Especially since EFT allows us to assign profiles to specific files, we can 'tailor' the EDIT function's behaviour when changing such data. In this respect, (TabBNDS) it is like any other profile setting which adapts EDIT's behaviour to be more data-specific. Examples are CASE T or CHANGE DS, etc. We don't expect users to 'remember' when they want those settings for certain files, so why should TabBNDS be different? It would be be ON for files where the user finds it useful, and OFF elsewhere.
Incidentally, I noticed that TabBNDS ON/OFF does not appear in the PROFILE list unless the (TabBNDS) primitive has been executed. Maybe TABBNDS OFF should be the initial default for all profiles.
I also agree that all profile values should be enjoy the same mgmt support, so there should be a TABBNDS ? | ON | OFF command and a suitabe GET_PROFILE$("TABBNDS") function. How would that command/function react if TABBNDS is entirely absent from the profile?
I'm pretty sure that a bug has crept into the colorisation tables. OPTIONS - HILITES section. Both the BG1 and BG2 values for NAVY have changed to the FG value. I don't recall doing that at any time in the past, so that is unexpected.
Still testing the COMMENTS and TABSHIFT scenarios.
|
|
|
Post by George on Dec 20, 2023 9:28:24 GMT -5
Stefan: A Prof display always shows TabBNDS regardless of whether it has been used or not. I agree on adding a TABBNDS command. And it's missing from the PROF EDIT dialog, I'll do that as well. OPT HILITES seems to be fine here. George
|
|
|
Post by Stefan on Dec 21, 2023 4:31:08 GMT -5
George,
You're quite right about Profile & TabBnds. My Bad! I was comparing latest beta with a previous version side by side and failed to realise which version I was using at the time.
Options Hilites
I have a tailored OPTIONS HILITES environment, because I never use 'reverse video' highliting. I prefer to highlite using commands like FIND 'whatever' +RED.
Hence my OPTIONS HILITES look like this...
Note the brown (usually called) NAVY line. BG1 and BG2 should be black for this entry.
I've reset the entry as required and shall keep an eye on it to see if/when it changes again. (Ignore the all BLACK line - that's deliberate because I needed a way to 'hide' text altogether. Given that I run with a black background, a Black FG on black BG provides that effect.)
As an aside.... I also note that if I set any BG1 to a new colour, the same colour is applied to BG2 as well. But I can set BG2 independently. Did it always work that way?
A thought about the COMMENTS feature... (forgive me if I missed it, but my initial reading didn't show me how COMMENTS addresses laguages which require a lead and a trail char sequence)
I like the <start-col> <step> combination. Why do we need to enter the character sequence (e.g. " ' ") to be used to start a comment? The required character sequence is readily available in the COMMENT<n> entry in the relevant AUTO file. You could therefor use a syntax like COMMENTS <n> <start-col> <step> where <n> matches the 'n' in the AUTO file's COMMENTn statement.
If you felt so enclined, this approach will also give you the 'end-comment' character sequence for laguages which require a pair, e.g. /* ..... */ So for an AUTO file entry like COMMENT9 11 /* */
the matching COMMENTS statement to "use char sequence /* in column 50, step 5, and place end char sequence */ in col 79"
COMMENTS 9 50 5 79
The syntax could thus become.
COMMENTS <n> <start-col> <step> <end-col>
where <endcol> is the end-column for the comment-closing character sequence. It would be ignored if the AUTO file's COMMENTn statement did not specify a pair of comment characters.
Hmm... It could even be shortened to COMMENTn <start> <step> <endcol> in the profile display to empohasise the synergy between the profile setting and the AUTO file.
My testing continues - albeit with constant interruptions. Sorry.
|
|
|
Post by George on Dec 21, 2023 10:25:43 GMT -5
Stefan: I wanted the starting character string because (Comments) accepts any of the 9 allowable comment definitions, and the search for comments does not return which one triggered it. It only enters the beginning comment string.
Specifying which COMMENTx is interesting, but it requires all AUTO files be consistent in the COMMENTx definitions. e.g. COMMENT1 would always be the one (Comments) uses. Maybe making COMMENT1 be the controlling one by default might be possible? I don't know.
[INSERTED] Also, inserting the closing comment marker (e.g. */) is fine if you run normally in OVR mode, as you do. But I run normally in INS mode and that would mean entering the comment text and then hitting (Delete) until the */ is dragged back into view, or (EraseEOL) and then typing */ again. Agan, not sure what to do here.
Not in the current Beta, but I've corrected an omission when Crosshair cursors are active. It was not handling the dotted line used by the new TABS mark lines in TabBNDS mode. Still a couple more omissions to do, maybe if we can settle what (Comments) does I can shove them in too.
George
P.S. Yes setting BG1 propagates to BG2, but not the other way. The idea was to simplify things for users who never run in banding mode.
[INSERT 2] The other reason for having the comment start string as an operand rather than picking it up from the AUTO COMMENTx was because I wanted to allow for specifying trailing spaces. e.g. I like PB comments to be ' Comments ... rather than 'Comments ... But then I could always add a space and hope that doesn't upset users who DON'T want one. [/INSERT 2]
|
|
|
Post by mueh on Dec 22, 2023 2:50:49 GMT -5
Hi George ! Beta 23355 breaks following sequence of keyboard primitives if there is a parameter on cmdline for MI macro . (SaveCursor)(CmdHome)(SetInsert)[MI ](RestoreInsert)(RestoreCursor)
With 23355 the parameter on cmdline is executed before the MI is inserted on cmd line . ( parameter results in invalid cmd msg ) In 23351 the MI macro name is inserted before the parameter on cmd line . Thanks
|
|
|
Post by Jo on Dec 22, 2023 10:46:58 GMT -5
23355: (BackSpace) does not work as expected, the Curser-Position does not move. 23313 was ok
Jo
|
|
|
Post by George on Dec 22, 2023 12:13:10 GMT -5
Jo: Hmmm, that BS problem cropped up in one of my interim versions, and I know I corrected it then.
Regardless, I fixed it again. Sorry it escaped into the wild.
George
|
|
|
Post by George on Dec 22, 2023 12:18:41 GMT -5
MUEH: Don't recollect any changes in that area, but it certainly doesn't work now. I'll have a look.
George
[UPDATE] I lied, there was a change, I'll try again. [/UPDATE]
|
|
|
Post by George on Dec 22, 2023 13:21:48 GMT -5
Stefan: After reviewing our thoughts on this, I think using the data from the AUTO COMMENTx is best, so I think the command will be:
COMMENTS comment-# col-start col-incr col-end
where: comment-# is the # of the COMMENT# statement in the AUTO file which defines the comment format col-start is the desired column number where comments should start. The cursor will be placed after the literal + 1. col-incr is an incr to col-start to add until past any long code lines col-end is where to place the ending comment marker (when a /* */ type comment) NOTE: the end marker is only added when the session is in OVR mode, not in INS mode
e.g. COMMENTS 1 50 5 79
George
|
|
|
Post by Stefan on Dec 22, 2023 13:58:09 GMT -5
George, You beat me to it. I was about to suggest that "end-comment" may not be needed as I have a current workaround... I limit lines to 90 bytes in length, so any "end-comment" sequence like */ is usually in column 89.
I set a TAB in column 89 and created this keyboard map, assigned to the big '+' key on the 102-key keyboard,
(SaveCursor)(NewLine)(BackTab)[*/](RestoreCursor)
It generates the */ in col 89 on the current cursor line.
|
|
|
Post by George on Dec 22, 2023 15:17:17 GMT -5
Stefan: Well, what do you think. Is the end-col support worth it? My feeling is - no.
George
|
|
|
Post by Jo on Dec 22, 2023 19:24:08 GMT -5
George: (BackSpace) now ok on 23356, thanks
(comments) seems to have problems with leading blank. On my REXX profile I use COMMENTS set to: 34 5 ' -- ' 1) On a blank line: it works as expected, -- is on pos 35 followed by 1 space 2) On a non-blank line with NO existing comments: it works as expected, -- is on pos 35 (or 40,45,...) followed by 1 space 3) On a non-blank line WITH existing comments: -- is repositioned on pos 34 missing the leading blank
Same on MACRO profile with COMMENTS set to: 49 5 " ' "
Jo
|
|
|
Post by George on Dec 23, 2023 11:48:48 GMT -5
Jo: I'm sure the leading blank is the trigger, with existing comments the line is 'taken apart' and rebuilt. Haven't looked back at the code (yet) but I'm sure it will be full of TRIM$, LSET$ etc. which would 'lose' the space. I'll review it and try and make it cope.
George
[UPDATE}
Jo: The COMMENTS command has now been altered (see the post 3 above yours), so the comment identifier is now picked up directly from the AUTO file. In fact the 1st COMMENTS operand is now the single specific COMMENTx descriptor to be used. And doing it that way precludes having a comment start literal containing a leading space.
Next Beta you will have to respecify the COMMENTS command in the new format, sorry, that's what Beta's are for, to tweak and adjust things.
[/UPDATE]
|
|
|
Post by Stefan on Dec 31, 2023 11:35:55 GMT -5
Stefan: Well, what do you think. Is the end-col support worth it? My feeling is - no. George Hi George,
HAPPY NEW YEAR!
Nobody forgets the start-comment marker but it's easy to forget to code (or casually lose) end-comment markers. But I jump ahead...
Some feedback on the new functions in v3.0.23357
(Comments) primitive and profile setting
To illustrate, assume this Environment: AUTO file: Defines COMMENT1 11 /* */ 0 PROFILE specifies: COMMENTS 1 55 5 89, TABS ON, tabs set at columns 40, 50, 55, 60, 65, 70, 75 and 89
Your Documentation says: 1) On a blank line: Your comment identifier will be entered at the comment column, and the cursor positioned after it. If a paired comment style, and the edit mode is OVR, the closing comment identifier will also be inserted. 2) On a non-blank line with NO existing comments. Same as 1) but moved right if the code length requires it. Any closing comment identifier will not be inserted. 3) On a non-blank line WITH existing comments. The code and comments are separated and rejoined, placing the comments in your desired comment column. Again, comments are adjusted right if required by the code length. Note: Comments will also be 'dragged left' if they are beyong the desired comment column. For this case 3), the cursor is not moved
Observations: Case (1) Works as described above, EXCEPT the */ closing sequence occupies cols 90-91 instead of cols 89-90. I guess a leading blank has crept in by mistake.
Not sure why edit mode must be OVR - it could also be useful for folks who run with DIN.
Case (2) Why is the closing */ not also inserted in this case, as it was for a blank line Case (1)? Most of the 'annoyance' of comments is messing about with or forgetting to code the end markers for languages which require them. Asis, the implementation addresses the start marker but rather neglects the end marker. The effect I anticipate is that /* is placed at col 55 (or the first available Tab stop after this) and */ is in col 89 (or following "/* " if after col 89).
CASE (3) If comments are 'dragged left', the *\ closing sequence should 'stick' in the closing col 89 and not be dragged further left. The effect I'd expect is that both /* and */ obey the COMMENTS 1 55 5 89 statement, whenever possible. So the 'rejoined' line should include a comment portion where */ is in column 89 if possible, padding or shortening the comment portion as necessary. Obviously, if the initial comment is too long, and there are no trailing in-comment to compress, the */ will appear beyond col 89.
TabSHIFT primitive
Assume same environment as above.
Observations
(TabShift) is rather unpredictable in terms of how far data is shifted. I can't quite decide, but I think this is a bad effect. This is unhelpful when dealing with columnar data (and especially so when the columns are of unequal widths, but let's not go there!).
Example: =TABS> * * * * * * * * * =COLS> ----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9- 000001 A short statement /* comments to far right */ Note - that the /* occupies cols 55-56. - that there are also tabs stops at cols 40 and 50. - that under normal conditions, you cannot see the TAB positions unless you run with COLS ON (underlines the tab cols).
1) Say the cursor is in col 55, ie. under the / of the /* sequence. (TabShift) will move everything from col 55 onwards right by 5 bytes, so /* is now at col 60. Exactly as expected.
2) But if you start with the cursor in col 22. (TabShift) will move everything from col 22 onwards (i.e. blanks & comment) by 18! bytes (col 40 minus col 22). This seems kind of logical - the cursor advanced to the next tab stop (col 40) and took the data with it. But nothing is aligned any more! So what just happened?
Intent: The user/cursor is in 'blank space beyond the source stmt' and expects the SHIFT to affect only the next data item (i.e. the /* comment */ portion) by a distance of 5 bytes. To achieve that, the cursor MUST BE EXACTLY AT or EXACTLY 5 bytes FROM the nearest CORRECT tab stop. The user cannot 'see' the earlier TABS, which generate the 18 bytes and, without which the SHIFT would be even worse - 33 bytes (col 55 minus col 22).
Proposal: To avoid this kind of error, (TabShift) needs to be sensitive to blank areas within a line.
(1) Code change: If there are only blanks between the cursor and the next TAB position, (TabShift) behaves like (Tab) This allows the user to repeatedly press the (TabSHIFT) key until it gets to the right tab position and then shift the data correctly.
(2) I am still trying to understand the effect, if (TabShift) did a 'DIN'-type shift instead of a 'INS'-type shift. Would that help at all? I am struggling to work through that scenario without having a system to hand that does this. If (1) or (2) is not acceptable,
(3) Documentation for (TabShift) needs to spell out that the primitive operates on the cursor . The shift always starts from the cursor position, relative to the next tab position. Hence, the amount of movement (shift) you get is different depending on how far the cursor is from the next tab stop to it's right. This can lead to unexpected results, especially because the SHIFT is a 'INS' shift, so all distances between subsequent data columns are maintained asis.
Further Observations
Given both the (COMMENTS) and (TABSHIFT) are keyboard primitives, I think that the (PA2) primitive should be able to 'undo' what is effectively a 'typing effect'.
This would bring the new functions in lone with other advanced keyboard functions such as MARK/COPY/PASTE, etc
|
|