Hello Fennel people!

As we are reaching the end of the year, it's time to get planning for
this year's FennelConf. (Well, I guess it would have been better to
start planning a little earlier, but here we are.) If you aren't
familiar with FennelConf, it is just a time where the Fennel community
comes together to share neat things they've been working on. You can see
videos from past events here: https://conf.fennel-lang.org/2023

I'm thinking that we should shoot for the 28th, which is the last
Saturday in December, but it's not set in stone yet. Normally we skip
the normal user group meeting during the month of FennelConf.

The main point is that you don't have to have a polished presentation;

For example:

    (tset package.loaded :hello.world {})

This can't use regular set because of the dot in the key.
---
 src/fennel-ls/lint.fnl | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/fennel-ls/lint.fnl b/src/fennel-ls/lint.fnl
index 580cbcf..5c5e844 100644
--- a/src/fennel-ls/lint.fnl
+++ b/src/fennel-ls/lint.fnl
@@ -83,7 +83,8 @@ the `file.diagnostics` field, filling it with diagnostics."
[message trimmed]

Andrey Listopadov <andreyorst@gmail.com> writes:
> Here's a quote from Planet Clojure readme:
>
>> Planet Clojure runs on Venus which is written in Python (a fine
>> programming language).

Well, I won't argue with that, but that is not the same as being a
language with a fine package management situation. I've wasted more time
than I care to admit wrestling with pip, virtualenv, etc. and it's
enough to make me avoid using anything written in python that has
dependencies, especially since Venus looks to be written for Python 2.

> A fun activity indeed. A while ago, someone on IRC had an idea of
> colloborative REPL, and we can set something up like this so people

Andrey Listopadov <andreyorst@gmail.com> writes:

>> So this might be the simpler fix:
>>
>> -(defcustom fennel-program "fennel --repl"
>> +(defcustom fennel-program "fennel"
>>
>> What do you think? Then you don't need any regex replace at all.
>
> Well, if someone specified this in their dir-locals it would not work
> for compilation and break suddenly. And speaking of dir locals,
> fennel-program can't be made safe variable, but fennel-args probably
> can be?

Andrey Listopadov <andreyorst@gmail.com> writes:

> I think, Fennel community could get some benefits from having a
> centralized feed of all Fennel-related blog posts, much like other
> programming language-oriented communities do.

This sounds cool! It might also give people more incentive to write
posts about Fennel on their blogs if they can get included here.

The main issue is that I would be tempted to rewrite an aggregator in
Fennel itself instead of using an existing off the shelf one, and then I
would procrastinate on setting it up until that project got done...

(This is mostly joking; I have no objection to using existing planet

Andrey Listopadov <andreyorst@gmail.com> writes:

>> +         (fennel-program (replace-regexp-in-string "--repl" ""
>> fennel-program))
>
> Now that I think of it, this might be a dodgy shenanigan.
>
> A set of compilation flags such as --add-fennel-path may be needed to
> view the compilation of the module, so this removal of --repl from
> fennel-program was a quick solution, as the repl usually is started
> with all necessary flags, otherwise it is useless. But using the repl
> startup command may be a wrong choice here. Perhaps we could add a
> configurable interface, such as fennel-flags, so people could
> customize it per project, and we could reuse it here?

andreyorst@gmail.com writes:
> From: Andrey Listopadov <andreyorst@gmail.com>
>
> * Q is no longer bound in all Lua buffers;
> * User can choose what lua major mode to use in compilation view;
> * Existing files are compiled in place, while non-visiting buffers are
>   compiled via a temporary file.  This ensures that existing files are
>   compiled with the correct surroundings;
> * Slight documentation fixes.
> * Automatically get arguments from fennel-program, to ensure
>   compilation in a more complex project.

This looks great; thank you! I'll go ahead and tag 0.9.2 with these changes.

Andrey Listopadov <andreyorst@gmail.com> writes:

> For some time I've been working on a library for making HTTP requests[1]
> asynchronously from Fennel without relying on anything but luasocket.  I
> have a library for asynchronous programming async.fnl[2] that implements
> a channel-based workflow, and uses debug.sethook for scheduling.  I've
> used this library in fnl-http, and faced a certain problem - how do I
> bundle async.fnl in such a way that fnl-http can still be a single file
> library for ease of use while making sure that users can still use
> async.fnl without being affected by the bundled version?

This is a really interesting post that I think deserves more thought
than I am able to dedicate to it right now! I hope to write up a reply
at some point after the game jam is over.

"chell sz." <chell@alterae.online> writes:

> I did some exploratory work in this area, and ran into a stumbling
> block. While the `utf8-len` function can be seamlessly substituted for
> the troublesome `length` invocations, the formatter still produces the
> wrong output. This appears to be due to the `identify-line`
> function[1], which is doing a lot of operations where it subtracts
> from a position in the string by 1.

Hm; I think there might be some confusion here; the file indentation.fnl
is not actually part of `fnlfmt` the CLI program. It's included as a
little bit of helper code that is meant for inclusion in text editors or
other contexts where fnlfmt's main strategy of "parse the whole thing
and then figure out formatting from there" isn't viable, for example

"chell sz." <chell@alterae.online> writes:

> When formatting lambdas defined with the λ keyword, if said lambda has
> a long parameter list, the parameter list is misaligned by one column
> [...]
> IDLE SPECULATION
> I think that whatever mechanism is being used to calculate string
> length is having UTF-8 issues with the 'λ' character, which in UTF-8
> is two bytes. This is further supported by the formatter displaying
> similar when presented with a function with multi-byte symbols in its
> name:

I think you're right; this is almost certainly a bug having to do with
the difference between `length' (which measures bytes) and the length in