XeroOl <xerool@protonmail.com> writes:

> I've been working on a branch that improves the code-generation for match
> and also introduces matchless and a bare (or) pattern.

Thanks for submitting this! Apologies for the slow response.

>     > * Replace :multival? with :top? to indicate when it's OK to accept a
>     >   multival and when to disallow it.
>
>     I don't like this change, because the difference between
>     `top-level?` and `opts.top?` is unclear to a reader of the code.

Aha, I see. Yeah, given that these two have very similar but not

This looks great; thank you!

It also occurs to me that this will be necessary when we upgrade the
version of fennel in TIC-80 since it also needs to display compiler
errors without having support for ANSI escape codes.

Going to go ahead and apply this; thanks.

One thing I realized should be clearer is that it's a bit nicer when
there's a single patch rather than a series of commits for most
contributions. Not a big deal here but I'll make a note in the
guide for contributors so it's clear for next time!

-Phil

~frozenfire <frozenfire@git.sr.ht> writes:

> +in order to post to it. To send a patch use the [actual email][4] and not the 
> +url) We also accept code contributions on the [GitHub

Thanks; hopefully that makes it clearer for future contributors.

Applied and pushed.

-Phil

Joel Kuntz <joel.kuntz.92@gmail.com> writes:

> I recently updated from fennel 1.0.0 to 1.2.1 and noticed that the
> compile errors had changed, they now used ANSI escape codes instead of
> the ^^^^^. While the old behaviour wasn't essential for me, the ANSI
> escape codes caused problems as my output wasn't going to a standard
> terminal (Unity game engine UI text area). When I realized
> [Unity supported a form of
> bbcode](https://docs.unity3d.com/Packages/com.unity.ugui@1.0/manual/StyledText.html)
> I started my quest to customize these escape codes, which has led to
> this patch.

Awesome! Thanks for the patch. You're on the right track here.

Phil Hagelberg <phil@hagelb.org> writes:

> I'm pleased to announce we have a date set for the next FennelConf. It
> will be on the 12th of November.
>
>     https://conf.fennel-lang.org/2022

Just a reminder that this is happening tomorrow! We've got a great list
of talks lined up:

    XeroOl - fennel-ls
    Phil Hagelberg/technomancy - Programming with Local Capabilities
    Andrey Listopadov - ob-fennel
    selfsame - Designing a Fennel Fantasy Console

Jesse Wertheim <jaawerth@gmail.com> writes:

> We've discussed adding `faccumulate` for a while, more or less as soon
> as `fcollect` came to be. Personally, I've found its absence more
> jarring now that `fcollect` is part of the language, so I figured I'd go
> about adding.

The contributing guide has this to say:

> We have a high bar for adding new features to the language. Once you
> have identified a problem and have sketched out a potential solution there are
> four main questions to consider:
>
> * How common is the problem?

Hi folks! I've just released version 1.2.1 of Fennel.

It's not a big release but there are some bugs in 1.2.0 that are kind of
a bummer.

## 1.2.1 / 2022-10-15

### New Features

* Add `fennel.install` function to the API for adding the searcher
* Add missing `table?` predicate to fennel API to go with `list?`, `sym?`, etc

### Bug Fixes

Hello!

Sorry for the late notice but I just wanted to let people know we've got
the monthly Fennel online group meeting coming up in 40 minutes.

No registration is required. To join, use this jit.si link
https://meet.jit.si/FennelUserGroup

See you there!

-Phil

Andrey Listopadov <andreyorst@gmail.com> writes:

> Current REPL integration has a lot of room for improvement both in the
> usage part of the comint interface and regarding sanitizing sent
> code.  This branch aims at using comint filtering features and proper
> redirection to make interactive editing less buggy.

This looks really promising, thanks for working on it! I'm guessing this
is in response to the previous thread about whether a new protocol is
necessary for the repl or whether we can rely on the prompt detection to
see whether the repl is ready for more input?

It looks like this code leans a little more on existing comint features
to recognize the prompt, which makes sense, as this is a problem that

Andrey Listopadov <andreyorst@gmail.com> writes:

> On second thought, maybe we can actually get away with just message ID
> and direction.
>
> 1234	->	(foo bar)
> 1235	->	,complete f
> 1234	<-	:baz
> 1235	<-	fn	for	fcollect
>
> This way all REPL has to keep a look at is incoming message ID, and
> provide it back to the sender. Then no complex capability system is
> needed.
>