Consider adding fill-active-human

[dgr]

Problem/Opportunity
Currently, Etaoin has a fill-active API for filling in the active element. This is convenient because it automatically queries for the active element. Etaoin also has fill-human and fill-human-el APIs for filling a queried or specified element with human-like behavior (delays, typos, etc.). There is no convenience API for filling the active element while using human-like behavior, however.

Proposed Solution
Add a new API, fill-active-human that simply queries for the active element and then calls fill-human-el. Parameters would roughly match fill-human / fill-human-el, but without the query or element to fill (since that will be provided by the active element).

Alternative Solutions
The alternative is simply to leave things the way they are. fill-active-human is strictly a convenience API offering no fundamentally new functionality that cannot be achieved less-conveniently using existing APIs.

Action
I can submit a PR if this sounds like good functionality.

[lread]

Yeah, if this would be useful to you and others, Dave, feel free to submit a PR!

[onetom]

human- as a prefix would sound better, imho.
fill-active-human sounds a bit like joda speak...
or as if some "active human" would be being filled as a result of calling this function...

without being familiar with the implementation, i would even expect to just have a single as-human modifier macro, which would just do some dynamic binding to affect the how the fill function works.

[dgr]

IMO, there's no great solution here. First, I tried to make this fit in with Etaoin's existing naming scheme. Etaoin uses -human at the end of something to indicate that it uses human-like delays and mistakes to fill something in. Another reasonable, though less optimal, IMO, choice would have been fill-human-active, which I considered but rejected because of the way the other functions were named. That eliminates some of the "active human" issue. If somebody has real heartburn and wants to suggest an alternative name, I'd be open to that. I don't think the modifier macro is a good idea. My general philosophy is that functions should just do what they say they do, without modifying behavior based on dynamic global state.

[lread]

Sounds good, I don't think we want to rename/rework existing working functionality too much.
For example, there is the somewhat oddly named wait-has-text-everywhere, which is probably due to English not being the first language of the author, but the docstring explains its intent.

[dgr]

After staring at this some more, I think we should change names from fill-active-human to fill-human-active. I think that actually fits in better with the overall Etaoin naming scheme.

[onetom]

fill-human-active has the same un-english-ness and ambiguity to it as fill-active-human, though, since we are not filling any humans here. human is just an adjective of fill.

but english is my 2nd language too, so my gut-feel is probably not the most representative in such matters.

First, I tried to make this fit in with Etaoin's existing naming scheme

it's not necessarily a good principle, if it became apparent over time, that the scheme was not the best...
im all for backwards compatibility, but also for intuitiveness.