Den ons 18 nov. 2020 22:[email protected] <[email protected]> skrev:
> BPJ,
>
> Thanks for the feedback and idea, and i'll check out your tool.
>
Thanks. Note that I just pushed a rather vital fix for a bug which I
introduced earlier today!
/bpj
You know, that's my fallback plan, to script it up and do substitutions
> based off of user input if necessary. I've done something very similar
> before, and its workable.
>
> But I submit to you that being able to do it via an editor would be an
> order of magnitude more scalable and usable. You could put in helpful
> keybindings to speed up data processing, use certain keys to calculate
> derivative windows to help users evaluate their input, and use the editor
> within a script to present multiple cases to end users for them to process
> one after another.
>
> My goal was to have users take about 20 seconds per use case with the help
> of scripting, in-vim macros, and vim's very useful perl and python
> bindings. It would reduce error rates as well.
>
> If you had a clean Implementation for this, you could make vim the center
> for a whole new class of applications based off of data processing. Again,
> think excel for unix.
>
> In any case, if I was going to provide low-level support for this in vim
> itself, I'd make it so that there was a file of type template, where:
>
> 1. the state of the default text of the file could be tagged as uneditable
> - ie: the vim cursor could only edit certain parts of the file based on
> tags given by the user. All vim keys would 'skip over these uneditable
> parts and go directly to the next user entry portion
> 2. the default state of the file would be insert mode, with helpful key
> macros to go to the next line.
> 3. The editable parts would have callbacks associated with them. Each
> callback could be then specified in the file in the form of a python or
> perl piece of code which either would set input or calculate input.
>
> So my original example would look something like this. Each time a user
> would enter in value, the callbacks would be re-executed and any updates
> would be made to the script. If a value is undef, it would show up as a red
> piece of text.
>
> I maintain that this would be very powerful. My personal application is
> making training cases for a nn, but I could see all sorts of applications
> for it.
>
> Ed
>
> Dear <<<person>>>>
>
> We received your order for <<<name>>>, price <<<price>>>,
> quantity <<<quantity>>>, total <<<total>>>
>
> Please look over the above information to make sure that this is correct.
>
> <<<email>>>
> __CODE__
> {
> 'person' => sub { $person = $_[0] },
> 'name' => sub { $name = $_[0] },
> 'price'. => sub { $price = $_[0] },
> 'quantity' => sub { $quantity = $_[0] },
> 'total'. => sub { $total = $price * $quantity }
> 'email' => sub { if (($_[0]) && _is_email($_[0])) { _mailit(
> $_[0], $text) }
> }
>
>
> On Wednesday, November 18, 2020 at 9:51:02 AM UTC-6 BPJ wrote:
>
>> Den tis 17 nov. 2020 23:[email protected] <[email protected]> skrev:
>>
>>> I'm not sure I made myself clear - this particular application needs to
>>> be interactive.
>>>
>>> In other words, you enter in values in one location, it calculates
>>> derivative values in another location, and you keep working on it until you
>>> are satisfied that you are in fact done with it. That is why vim stuck out
>>> as a possible solution - it really needs an editor. All my example was
>>> meant to do was show what I had in mind.
>>>
>>
>> I had the same need a couple of years ago. The script I wrote for the
>> purpose (and just updated for publicizing) does not work from inside an
>> editor but does interactively replace placeholders (format configurable) in
>> a text file with prompted-for values, optionally silently inserting already
>> "known" values on subsequent occurrences of the same placeholder. You can
>> also optionally preload a default key-value mapping from a YAML or JSON
>> file and/or save the collected/modified data to a YAML file.
>>
>> https://github.com/bpj/placeholder-prompt
>>
>>
>>> so have people attempted this? if so which api should I be looking at..
>>>
>>>
>>>>> --
>>> --
>>> You received this message from the "vim_use" maillist.
>>> Do not top-post! Type your reply below the text you are replying to.
>>> For more information, visit http://www.vim.org/maillist.php
>>>
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "vim_use" group.
>>>
>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to [email protected].
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/vim_use/c3b018f8-bd51-44a6-900f-adbc7dbd22een%40googlegroups.com
>>> <https://groups.google.com/d/msgid/vim_use/c3b018f8-bd51-44a6-900f-adbc7dbd22een%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>> --
> --
> You received this message from the "vim_use" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups
> "vim_use" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/vim_use/434cf3d5-2634-402a-90a8-e1c5bef04a45n%40googlegroups.com
> <https://groups.google.com/d/msgid/vim_use/434cf3d5-2634-402a-90a8-e1c5bef04a45n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_use/CADAJKhDodORhZRdiPv2dG4iDeXzHkCSrTUYMfcF6Z8EmHNg94g%40mail.gmail.com.
