|
|
Post by Stefan on Apr 2, 2021 5:21:17 GMT -5
George,
How about extending CUT in EDIT to work similarly to CUT in FM?
Given that in FM, CUT now supports multiple separate 'C' and 'CC..CC' line commands I had hoped the same might be true in EDIT. I know I can 'CUT APPEND' lines to the clipboard but that requires multiple CUT executions which is tiresome. I've long wanted (correct me if it's there and I've not found it) a simple way to to Copy/Move a selection of separate lines/blocks of lines to a single destination. The ability to simply place multiple 'C' and/or 'CC..CC' on several non-adjacent lines and have SPFLite copy (or move for 'M/MM') them to a single 'A/B' destination remains elusive. An enhanced CUT (like in FM) followed by a single PASTE would be an excellent work-around for that use case. I certainly need to move/copy several, otherwise unrelated lines to a single place, much more often than I want to copy something 'x' times to every 'n'th line that follows. |
|
|
|
Post by George on Apr 17, 2021 15:35:15 GMT -5
Stefan:
Why not try using Tags. CUT supports a Tag operand. I know it's not the same, but frankly, there's no way on earth I will try and support multiple CC line ranges in edit. It's totally non-ISPF compatible, as well as being completely incompatible with the internal structure.
Maybe a place for some macro support to handle adding the Tags to multiple lines.
George
|
|
|
|
Post by Stefan on Apr 24, 2021 9:39:58 GMT -5
Alas, what I would like is to reduce (or at least avoid the further increase in) the strange foibles that have crept into the SPFLite command structure over time. From a user perspective, I neither know nor do I care, that the same commands in FM in EDIT are actually two different commands. If they are called the same name, I expect them to do broadly the same thing in broadly the same way, albeit in a manner appropriate to the environment.
From the user's perspective, FM appears as the simpler environment, so if CUT accepts non-contiguous line selections there, it is reasonable to expect the same construct to work for CUT in EDIT sessions. And given the simpler FM environment, it is reasonable that some CUT operands that apply to EDIT sessions do nothing in FM because they are not relevant to that environment. Arguing the reverse is more difficult, because the concept of "line selection for cutting" is common to both environments, so why have two similar but different techniques? Or rather why have a technique in the simpler FM environment which is more useful/flexible? EDIT can only achieve the same effect via Excluded or User lines. I might already have some of those so I cannot use CUT flexibly. The concept of selecting lines via X/NX or U/NU, etc is well established in EDIT. But 'X' has already been subverted in FM and thus a new 'selective CUT' solution had to be considered. So we accept non-contiguous use of 'C' (maybe even standardised to 'S' in a later release). (By the way, v21112 HELP documentation for CUT does not mention that multiple, non-contiguous, 'C' selections are acceptable.) But there's other stuff too that is complex for no reason. Hands up who actually uses the abbreviation 'FF' to FIND things in an edit session instead of just 'F'? ...I'll wager - nobody. And FF clashes with a completely different function in FM. Why isn't FIND-IN-FILES called FiF, by all means with an alias of FF for those who have become used to it. And consider dropping FF as an alias for FIND in EDIT. IMHO, there should not ever be a need for the HELP documentation to have 3 entries for a command like FIND, let alone a statement like "The Find in Files command FF should not be confused with the new FF alias for the edit primary command FIND; the two commands are not related"
(The use of 'new' in that statement suggests that FF was added afterwards - I wonder why?)
|
|
|
|
Post by George on Apr 24, 2021 10:32:54 GMT -5
Stefan: Who uses FF in Edit? -- I do. After doing the search in FM, and selecting a 'found' file for edit, what's the first thing that 99% of users do first? -- Search for the same string in the edit file. So I do a simple RETRIEVE and hit (Enter). What do you do, type in the FIND command again? RETRIEVE, edit FF to F and hit (Enter)?
As to extending Edit line selection to multiple disconnected line ranges. You can 100% forget that. I won't try to justify/explain why that is so. Just telling you it will never happen.
I know you and other users don't care about internal reasons for FM/Edit differences, that's my domain. I've been working away on SPFLite for over 17 years. Believe me, if there's a way to do something, I'd find it. I don't shoot down ideas/suggestions for no reason.
George
|
|
|
|
Post by George on Apr 25, 2021 10:08:18 GMT -5
Stefan: Another point, you ask why, in the simpler FM environment, multiple CC ranges are supported, yet in the more complex Edit environment they are not.
Your question contains the answer - the FM side is simpler, and easier to modify because of it's simplicity compared to Edit.
George
|
|
|
|
Post by Jo on Apr 28, 2021 4:53:09 GMT -5
Stefan, I use FF in Edit/Browse after a FF in Filemanager, using PF12 (CRETRIEV). One more FIND: I wrote a simple FIND Macro for use as a FM-Linecommand. It does a FF FMGet_FileName$ to find the selected Filename in the current FM display (Filelist, directory, ..  . I use that to find all modules including the selected file (#INCLUDE, ::Requires, %Include, .include) Jo |
|
|
|
Post by George on Apr 28, 2021 9:03:33 GMT -5
|
|
|
|
Post by Stefan on May 1, 2021 4:05:09 GMT -5
George,
I had read that section years ago, but admit I forgot about it.
I appreciate you need another way to invoke the 'other' way of operation for the FIND command and thus FF in EDIT was born.
But I still maintain that either the FF in EDIT or the FF in FM should be changed to something else.
Hence my suggestion of FiF for Find-in-Files.
|
|
|
|
Post by George on May 1, 2021 9:38:06 GMT -5
Stefan: I appreciate the desire, but personally going to FiF in FM would cripple my (and others) ability to just do a Retrieve and (Enter) to do that initial search in Edit. And we can't use some variation of RFIND as all the data for that is Tab related, so the new Edit tab has no previous Find operands.
I think until some alternative ideas appear, things will remain as they are.
George
|
|
. I use that to find all modules including the selected file (#INCLUDE, ::Requires, %Include, .include)