todo.sr.ht

An issue common to both clapconf and clapenv is that Parse() also validates the input. When all we're dealing with is command-line args, this is fine, but when multiple engines can provide data, it causes a sort of race condition for mandatory arguments. If conf and env are loaded first, then we have an issue when the user tries to use command-line args that are also specified in (e.g.) environment variables: claptrap will throw a "too many arguments" error. If conv and env are loaded last, then the validation performed during Parse() happens before the values from conf and env are loaded.

Providing a non-validating Parse (say, claptrap.Load()) and exposing Validate would allow the tools to load any missing values and then call Validate themselves. In this case, we'd constrain the tools to be run after claptrap.Load(), and have them call the claptrap.Validate() when they're done:
claptrap.Load(nil)
clapenv.Load()

#2 #clapconf doesn't support multi-values in the configs 1 year, 10 months ago

Ticket created by ~ser on ~ser/claptrap

TOML supports multi-values, e..g.
ip="10.89.23.2"
ip="10.89.23.3"
ip="10.89.23.4"
and claptrap supports multi-values:
cmd.Add("--ip...", "", "a list of IP addys")
but clapconf doesn't support putting multiple values into a multivar arg. This is because claptrap doesn't support multivar DefaultValues, and clapconf sets the DefaultValue.

This is a "deep" issue requiring changes to the claptrap API

#1 Improve autocomplete 1 year, 10 months ago

Ticket created by ~ser on ~ser/claptrap

claptrap's json dump with CLAPTRAP_USAGE_JSON is context sensitive; that is:
$ CLAPTRAP_USAGE_JSON=true <program>
will output the entire tree, whereas:
$ CLAPTRAP_USAGE_JSON=true <program> <command>
will dump the subtree for <command>. It should therefore be possible to make _clapcomplete_ work on the first subcommand level by generating WORDS with:
local WORDS=($(CLAPTRAP_USAGE_JSON=true $1 $2 | jq -r "$JQR"))
This needs to be dynamic, of course; COMP_CWORD holds the number of arguments being passed in, but (at this moment) that exhausts my knowledge of the autocomplete mechanism.

I would love if someone donated a patch for this.

#1 Patches available in a fork 1 year, 10 months ago

Comment by ~ser on ~psic4t/qcard

On Tue Oct 11, 2022 at 12:00 PM CDT, Matthias Debus wrote:

qcal and qcard are my first Go projects, so some refactoring from a more skilled person than me is more than welcome. :)

Yeah, I just saw qcal in your list; I'll be looking at that, too.

I'm pretty busy at the moment so I don't have time for many new features in qcard, but I'll be happy to merge your patches.

Same here; this will be the fourth project I've picked up sending patches for; I'm quickly running out of bandwidth. That's another reason why I don't want to do a hard fork.

With qcard, I would like it to be able to replace vdirsyncer. I think it's only a few more lines of code, now that it supports both ical and local ics. I don't know if that counts as a "local cache."

My patches bounced from the todo.sr.ht email; the mail server said they were too big, over 16k. That doesn't seem like a large patch to me, but I may be using git send-email wrong. Anyway, I sent them to the public mailing list, which was probably bad form, but there you go.

--- SER
Sean E. Russell
Age: age195vpft7nzsy83medxagqqsge0lrcuf9txe3z2znlu2wsk69cdu4sx8nfvp
Minisign: https://ser1.net/.well-known/minisign.pub
GPG key: https://ser1.net/.well-known/pgp.asc
Matrix: @ser:matrix.org

#1 Patches available in a fork 1 year, 10 months ago

on ~psic4t/qcard

Hi Sean,

thanks for putting work in qcard! I wrote it out of the same need - replacing khard which wasn't what I wanted.

I removed the binary from git, so you are welcome to send patches.

There are two significant bundles of work. The first adds local vdir support. AddressBooks can be defined as pointing to a local directory of .ics files -- this is how the local caches of tools like vdirsyncer look. qcard can act entirely offline with a vdir. This fits great. Please send a patch.

The secord commit refactors the code: it removes dead code, localizes variables that don't need to be global (and reduces global variables in general), renames variables following Go naming conventions (type thingStruct struct is discouraged as being redundant), replaces functions with methods where appropriate, generalizes some specialized functions, and generally cleans things up. qcal and qcard are my first Go projects, so some refactoring from a more skilled person than me is more than welcome. :)

I'm pretty busy at the moment so I don't have time for many new features in qcard, but I'll be happy to merge your patches.

Regarding your German: Also, ich verstehe dein Deutsch, aber es klingt lustig. :)

Greets, Matthias

On 11.10.22 13:12, ~ser wrote:
I've been doing some work on qcard in my fork:
https://git.sr.ht/~ser/qcard
in the hopes of eventually replacing khard, which isn't too machine-friendly (for scripting). However, you checked in the compiled binary at one point, so all of the patches, regardless how small, are over 10MB and can't be submitted through email.

There are two significant bundles of work. The first adds local vdir support. AddressBooks can be defined as pointing to a local directory of .ics files -- this is how the local caches of tools like vdirsyncer look. qcard can act entirely offline with a vdir.

The secord commit refactors the code: it removes dead code, localizes variables that don't need to be global (and reduces global variables in general), renames variables following Go naming conventions (type thingStruct struct is discouraged as being redundant), replaces functions with methods where appropriate, generalizes some specialized functions, and generally cleans things up.

My next two areas of focus will be writing some badly-needed unit tests, and I may look at the bespoke ICAL parsing code and see if using an ICAL library that implements RFC 6350 more completely.

As I mentioned, I tried to submit a patch, but that qcard binary defeated my mail server. I think if we can delete that and get sync'd, I can use the standard patch process.

I'd like to collaborate, rather than hard fork; please let me know if you're interested in doing that. It would also be useful to know if/what you're working on and the direction you're going -- I have some specific needs I want to accomplish, for my own purposes, and would be focusing on those.

If you want to merge my changes, you'll have to remote add my repo and merge them on your desktop; after that, the qcard binary will be gone and I can submit patches. There are only the two commits, so at least the review won't be horrible.

Ich kann gut Deutsch lesen, habe aber vor 20 Jahren durch Eintauchen gelernt und wurde dar??ber informiert, da?? mein geschriebenes Deutsch fast unverstandbar ist. Also, ich schreibe lieber English.

Cheers,

-- View on the web: https://todo.sr.ht/~psic4t/qcard/1
-- message me on Matrix: @psic4t:data.haus

#1 Patches available in a fork 1 year, 10 months ago

Ticket created by ~ser on ~psic4t/qcard

I've been doing some work on qcard in my fork:
https://git.sr.ht/~ser/qcard
in the hopes of eventually replacing khard, which isn't too machine-friendly (for scripting). However, you checked in the compiled binary at one point, so all of the patches, regardless how small, are over 10MB and can't be submitted through email.

There are two significant bundles of work. The first adds local vdir support. AddressBooks can be defined as pointing to a local directory of .ics files -- this is how the local caches of tools like vdirsyncer look. qcard can act entirely offline with a vdir.

The secord commit refactors the code: it removes dead code, localizes variables that don't need to be global (and reduces global variables in general), renames variables following Go naming conventions (type thingStruct struct is discouraged as being redundant), replaces functions with methods where appropriate, generalizes some specialized functions, and generally cleans things up.

My next two areas of focus will be writing some badly-needed unit tests, and I may look at the bespoke ICAL parsing code and see if using an ICAL library that implements RFC 6350 more completely.

As I mentioned, I tried to submit a patch, but that qcard binary defeated my mail server. I think if we can delete that and get sync'd, I can use the standard patch process.

I'd like to collaborate, rather than hard fork; please let me know if you're interested in doing that. It would also be useful to know if/what you're working on and the direction you're going -- I have some specific needs I want to accomplish, for my own purposes, and would be focusing on those.

If you want to merge my changes, you'll have to remote add my repo and merge them on your desktop; after that, the qcard binary will be gone and I can submit patches. There are only the two commits, so at least the review won't be horrible.

Ich kann gut Deutsch lesen, habe aber vor 20 Jahren durch Eintauchen gelernt und wurde darüber informiert, daß mein geschriebenes Deutsch fast unverstandbar ist. Also, ich schreibe lieber English.

Cheers,

#4 Announce 2 years ago

Comment by ~ser on ~ser/quasiauto

Twitter, reddit, gemini