It might be nice also having something like PointFormat, where multiple format transformations to the current selection are needed before a final Say to output:
I'd also vouch for PointAt to load in output buffers or %output% to the pointer as RegexpReplace "^.*" can be funny with certain characters if not escaped or replaced before-hand due to regex limitations.
Ah, just for illustrative purposes, would be a bit much trying to process multiple outputs at once to be fair Also makes sense just having one command that would do the work of both ideas at once. ← Edit: Ignore this please. Got confused.
Oh sorry, you’ve got the idea absolutely spot on.Use just seems redundant if UseFormat already does the job of loading an output into current input and uses format strings. ← Edit: Ignore this please. Got confused.
I was also just guessing the function of | as if it were for processing both %outputs% but that seems a bit much
OK, thanks for the extra explanation. I just wanted to be sure I wasn't missing anything and needed that extra bit of detail to follow your assumption about processing both outputs.
Yes, Use "output" would produce the same result as UseFormat "%output%", but the former can be implemented in a more performant way.
What to you think about the naming of the functions Use and UseFormat compared to PointAt and PointFormat? I feel that Use* is a little bit more direct.
I'm splitting this to a separate topic so that this suggestion can be tracked independently from the discussion about SayFormat.
I had thought of Point purely because it’s a pointer-based system and that’s how I got my head around learning it, but that’s only ever really referenced as such in the documentation: Developing Tag Sources – Mp3tag Documentation
Use does feel more appropriate given the point of a pointer is simply that’s what you use to manipulate data in its current input.
Current might be more to the point overall. I’ll leave it to a majority vote on what
Now that I really think about it, UseFormat might actually have better utility not as a method for loading content into the current input, only to transform what’s currently inside it similarly to SayFormat. That would give far better purpose for Use as the opposite function of Say.
Apologies, realise I went round in a circle there. Two separate commands for two separate uses as I originally pitched in my first post.
Currently I use in my scripts the command: regexpreplace "^.*" "text with %outputs% inside"
to copy the contents of one or more output buffers, optionally surrounded by arbitrary characters or strings, to the input buffer.
If this could be replaced one to one by the command use "text with %outputs% inside",
the scripts would surely run faster, be easier to understand and not any more need escaping of special chracters for regular expression like the \ . Although it brings no new feature in, in my opinion this is enough benefit to be worth the effort.
A command useformat "string" seems to me to be not necessary, because its function would be already available with sayformat "string" and the new use "%output%".
This. Means its not just outputs that can be used but ANY string.
That’s where I got myself confused along the way because @Florian had the two named ideas under the same concept but really they would have completely different usecases.
Use strictly for loading into current input, UseFormat for transforming what is already in current input.
UseFormat means you don’t have to send SayFormat back and forth from temp outputs and current input if you need multiple commands to process the current input. SayFormat would then be the last step equivalent to SayRest.
What result do we expect from the following command?
UseFormat "sort(%_current%)"
Should it append the sorted string at the end of the input buffer or clear the input buffer after it is read?
The current implementation of SayFormat lets me suspect, UseFormat would also append the sorted string to the end of the unsorted and that doesn't seem useful to me.
Maybe I wasn't clear in my initial description of the two proposed functions, let's try again.
The initial motivation was to use the contents of an output variable as the current input. This would make the current workaround using RegexpReplace "^.*" "%output%" obsolete.
The new function would replace the current input buffer, and would not emit anything to the current output.
I'd still go with two separate functions, one that serves as a counterpart to Say, and another that serves as a counterpart to SayFormat.
Function Use S
Example: Use "some text and %output%"
(this is equivalent to what the current workaround with RegexpReplace "^.*" does, except for the need to escape)
Function UseFormat S
Example: UseFormat "some text and $sort(%_current%,-)"
(this is something that isn't possible at the moment, only via SayFormat to a temporary output and then applying the RegexpReplace "^.*" workaround)
with the actual benefit being UseFormat could use most format strings, not just $replace().
Fair point though as all Say commands do append rather than alter an existing value. That being said - and at the risk of complicating it again - unless there’s a need for an n parameter for Use and UseFormat to add newer content to the end of an existing current input similar to a Say command, it's simpler the two commands just replace existing content.
Or likely it just takes whatever text's given including %_current% if present then replaces all of current input? That would bring us back to UseFormat being a fancier Use!
But I guess that's the only complication. UseFormat would be commonly used with %_current% to manipulate mainly the current input anyway so it still means Use has a far more direct purpose. Again, SayFormat hasn't exactly replaced Say... yet.
My performance test shows that the new Use commmand is round about 20% faster than the corresponding Regexpreplace and everything I've tested works fine here.
Thank you for providing the new tools.
Also makes sense just having one command that would do the work of both ideas at once. ← Edit: Ignore this please. Got confused.
Two separate commands for two separate uses as I originally pitched in my first post.
- unless there’s a need for an n parameter for 
