... to determine/print the current external progarm being run.

This fixes issue #716

Make mqtt_putnodedat() use a 1-based node number, like the other putnodedat()
functions.

The bug (misuse of mqtt_putnodedat) was actually in js_system.c, but fixed the
API to match the common expectation.

DD File Lister: New sort option in the config file: PER_DIR_CFG, which has Synchronet sort the file list according to the file directory's configuration

See merge request !399

Eric Oulashin authored 1 year ago and Rob Swindell committed 1 year ago

DD File Lister: New sort option in the config file: PER_DIR_CFG, which has Synchronet sort the file list according to the file directory's configuration

DDLightbarMenu: DrawPartial() width check update (previously it wasn't re-drawing the last character of the item text)

See merge request !398

DDLightbarMenu: DrawPartial() width check update (previously it wasn't re-drawing the last character of the item text)

Hopefully, we'll find out why the random test fails sometimes...

The patch that sets the read timeout every time for getData() was
flawed, because getData() itself will sometimes set the read timeout
for the next call.

The patch was intended to ensure that the write timeout never
clobbers the read timeout, so now we track if getData() explicitly
set the timeout and if it did, we don't reset it.

It appears that if the timing is "just wrong", a large POST can
cause TLS to fail.  This has shown up as an inability to edit
pages in the wiki.

This is not a fix however, but simple a workaround until this is
root-caused.

If DL was passed a parameter equal to or greater than the number of
lines from the current line to the last line in the region, it would
try to move a negative-sized box up, which resulted in a crash.

This fixes that three ways:
1) Do not allow moving boxes with negative X/Y sizes
2) In dellines, clamp the lines to the number that could be deleted
3) Don't move lines up of all rest of the lines are being deleted

May fix the issues seen updating wiki pages, may not, but is a less
invasive patch either way.

The caller of this function must clobber the passed in pointer,
and we're returning NULL meaning we would be overwriting the pointer
to the allocation.

If this *does* work, it means that potentially a huge chunk of our
error checking hasn't actually worked in release builds or builds
that use the FORTIFY option.

At some point, we should consider making it default.

Since this script supports/expects UTF-8 character sequences for UNICODE
characters (not a CP437 translated version of mappable chars).

K_CP437 changed to K_UTF8 with the inverted logic. If you have code/script
that can handle UTF-8 input, then you need to specify K_UTF8 in calls to
inkey, getkey, getstr. Or else, you're going to get a CP437 translated
version of any non-ASCII (UNICODE) UTF-8 chars, if there's a mapping
available. This only impacts UTF-8 terminals.

There are just so many places in Synchronet where UTF-8 input could cause
problems, it makes sense to translate UTF-8 to CP437 by default and make
true UNICODE/UTF-8 handling the exception.

Sorry Nightfox, you'll need to remove the K_CP437 detection/use code you
just added to SlyEdit.

This creates a .PHONY target for each file so that if a header is
renamed, the impact will be the files that include it being rebuilt
instead of the previous behaviour where the build would simply fail
and complain that the file doesn't exist.

SlyEdit: Support for entering UTF-8/Unicode characters; using K_CP437 to have Synchronet convert to CP437 internally

See merge request !397

SlyEdit: Support for entering UTF-8/Unicode characters; using K_CP437 to have Synchronet convert to CP437 internally

We don't want CI to die because someone somewhere upgrade a compiler.

NOTE: CI does release builds, which means that -Wall is not enabled.
      WALL=1 could be added if we want that, but it's likely too
      soon to take that step.