On Thu, Aug 31, 2023 at 10:58:27AM +0200, Michiel van den Heuvel wrote:
so if you think it would be a good use of *your* time, then go ahead.
After some somewhat more synchronous communication, it might be.
are you asking for a chat channel?
i'm @ossi:kde.org on matrix, ossi on libera.chat irc (if the matrix
bridge feels like working), and @ossilator on various social media and
chat sites.
i could create an official project channel (on matrix?), but
historically it seems a bit ... superfluous.
On the subject of more things I could do, is there a way to reproduce
the 2 regressions?
congrats, you forced me to actually research what the regressions are.
*grumble* :-D
for the imap thing, i suspect any mail with a large enough attachment
will do. maybe the imap compress extension needs to be in use, and/or
tls. no idea.
(possibly) related threads:
https://sourceforge.net/p/isync/mailman/isync-devel/thread/Y00lhIm7VdrJzG/D%40ugly/#msg37721793
https://sourceforge.net/p/isync/mailman/isync-devel/thread/87h740x2xe.fsf%40wavexx.thregr.org/#msg37675548
https://sourceforge.net/p/isync/mailman/isync-devel/thread/87edk45p9o.fsf%40b3l.xyz/#msg37883904
for the other problem, there is
https://sourceforge.net/p/isync/mailman/isync-devel/thread/f4d61b60-7a93-6b78-90d1-b96b285caa9c%40quaternum.net/#msg37708463
which contains a speculative analysis.
there is https://sourceforge.net/p/isync/bugs/69/ which may be actually
the same thing (sounds similar, but i'm not going to think about it at
this time of day). it has a patch attached, which is certainly
under-tested, and needs a sanity check, possibly resulting in a complete
rewrite.
speaking of tested, if you _really_ wanted to go overboard, you could
add a proper unit testing suite. so far only the core syncing algo is
tested, in a way that is really an integration test (which has the
advantage of testing a bit more as a side effect, but it's slow and
inelegant). this would also nicely fit with formalizing the error
reporting.
Subject: [PATCH] Add IncludeCmd directive to config parser
+static char *
+check_excess_tokens( conffile_t *cfile )
+{
+ char *arg = NULL;
+
i generally prefer early returns (and even goto) over temporaries.
int
getcline( conffile_t *cfile )
{
...
+ else if ((arg = check_excess_tokens( cfile )))
+ conf_error( cfile, "excess token '%s', not executing
"
+ "potentially malformed command\n",
arg );
my thinking was that the error message would be printed already by the
check function (hence "check", not "get"). i don't think the extra
verbosity about the specific consequence adds all that much value.
then the check function can just return an int.
oh, one thing i totally failed to notice: this is a noteworthy new
feature, so it should get an entry in NEWS. something like "Added
support for scripting arbitrary parts of the config file.", before the
currently last two entries, i think.
and you should add yourself to the end of the main contributor list in
AUTHORS.
regards
_______________________________________________
isync-devel mailing list
isync-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/isync-devel
