[Surfraw-devel] Some ideas for improvements (feedback please!)

[Gabriel Lisaca]

Hi Jason,

I wasn't subscribed to the list so I don't have your previous email to 
reply directly to.  I am subscribed now.

Re bash completions:

> I'm not convinced about this as the additional complexity of an elvis
> would potentially discourage new contributors (not that we are
> inundated, but it is worth considering), 
If it's a question of complexity, perhaps having a two-tiered approach 
would help?

By that I mean allowing users to declare the options an elvis takes--the 
side effects of which would be to generate completions output and 
possibly option parsing code in the future.  I don't suggest any use of 
`eval` to do this.

Something like:

     # For argument- and non-argument-taking options with overridable 
metavars.
     mkopts -foo -bar=CUSTOM_METAVAR -baz=

     # More complex declaration for a *single* option.
     # Just thinking for future uses.  I don't know how this should work.
     mkopt -spam=

     # Yes-no options.  Error if no "="?.
     mkoptsyn -ham= -spam=

These would then be recommended by the documentation to just include the 
lines at the start of elvi.  There's already a lot of copy-pasting for 
elvi anyway, declaring them shouldn't hurt too much.

To allow for more customisability for just completions, the 
`w3_complete_hook` I recommended before would be supported.

Just throwing some suggestions out there.  User-definable completions 
would be great :)

> it would also significantly
> impact the current test approach.

How so?  I'm not familiar with how Surfraw is tested.

> >Some open questions (for b):
> >
> >1. What should the name be? `w3_completion_hook`?  That seems too
> >long, and what does the `w3` prefix even mean?
> >
> I think it should be read as w³ :)
Oh I wasn't clear, sorry.  I meant what is the `w3` prefix meant to 
accomplish?  I know that underscores are used for namespacing, but in 
Surfraw's case, it seems to mean multiple things:

1. Public API: The `def*` and `set*` functions are public too.
2. Functions meant for web-specific code: `w3_config{,_hook}`, 
`w3_global_usage`, and `w3_config{,_hook}` beg to differ.

Re new config file hierarchy:

I've implemented them in my fork [1] of the repo on GitLab.  I don't 
know how the documentation should change its recommendations so I 
haven't touched them.  Thoughts?

There are provisions for backwards-compatibility among my changes, but 
they're brittle.  It doesn't handle the case where the basename of the 
local config file is not "conf" or "config", and consequently doesn't 
read *anything* from the hierarchy (except inherited environment 
variables of course) in that case. The old convention for config files 
is still followed though: ".surfraw.conf" should still work.

[1]: https://gitlab.com/Hoboneer/Surfraw/-/tree/new-config-hierarchy

Cheers,
Gabriel