--- a/Makefile	Wed Jan 20 14:14:38 2021 +0100
+++ b/Makefile	Thu Apr 08 21:17:59 2021 +0200
@@ -56,7 +56,8 @@
                 faq.md \
                 index.md \
                 versioning.md \
-                news/2020-01-13.diet.md
+                news/2021-01-13.diet.md \
+                news/2021-02-16.irccd-4-try.md
 SITE_HTML=      ${SITE_SRCS:.md=.html}
 
 .SUFFIXES:
@@ -85,8 +86,8 @@
 
 doxygen: ${WKRDIR}
 	mkdir -p irccd-${VERSION}/build
-	cmake -S irccd-${VERSION} -B irccd-${VERSION}/build > /dev/null 2>&1
-	cmake --build irccd-${VERSION}/build --target doxygen > /dev/null
+	cmake -S irccd-${VERSION} -B irccd-${VERSION}/build
+	cmake --build irccd-${VERSION}/build --target doxygen
 	rsync -a --delete irccd-${VERSION}/build/doc/doxygen/html/ doxygen
 
 www: ${SITE_HTML} man doxygen

--- a/faq.md	Wed Jan 20 14:14:38 2021 +0100
+++ b/faq.md	Thu Apr 08 21:17:59 2021 +0200
@@ -106,14 +106,29 @@
 is still quite minimal.
 
 Because irccd offers a runtime controllable mechanism with lots of commands (30
-at this time of writing), it increases the total number of lines of code and
-since it's written in C++, yes it requires some time to build. Please also note
-that irccd is excessively tested.
+at this time of writing), it increases the total number of lines of code. Please
+also note that irccd is excessively tested. We could argue that a lots of these
+command may be unneeded but I like that I can keep the daemon running for months
+without having to shut it down and restart it to change its nickname.
+
+The Javascript glue code also requires more than the half of the code base to
+bind the C code to the Javascript interpreter. Disabling Javascript reduces the
+total code by more than 60%.
 
-On the other hand, I must admit that I regret having used [boost][] for such a
-small project which definitely increased its complexity in some parts. But given
-its current stability and completeness, there are no plans to rewrite irccd in
-C.
+But in other hand, irccd still follows the UNIX philosophy of doing minimal
+things and be extended by the user externally through plugins. It also tries to
+stick to POSIX and use as much as possible simple and clean code. By itself,
+irccd's responsability is to poll IRC events, call plugins and hooks and that's
+it.
+
+Shouldn't irccdctl be named irccctl?
+------------------------------------
+
+Yes, technically speaking UNIX daemons may have a name `bard` and an optional
+utility `barctl` without the trailing 'd' to control the daemon. But since irccd
+has already two 'c' irccctl would be annoying to type especially since having
+three identical consecutive letter is unusual. So as an exception, the utility
+is named `irccdctl` rather than `irccctl`.
 
 What does irccd drink?
 ----------------------

--- a/index.md	Wed Jan 20 14:14:38 2021 +0100
+++ b/index.md	Thu Apr 08 21:17:59 2021 +0200
@@ -24,7 +24,8 @@
 News
 ----
 
-- (2021-01-13) Irccd is going on a diet. [More…](2020-01-13.diet.html)
+- (2021-02-16) Irccd 4 is available for testing. [More…](2021-02-16.irccd-4-try.html)
+- (2021-01-13) Irccd is going on a diet. [More…](2021-01-13.diet.html)
 - (2021-01-04) Bugfix release: irccd 3.1.1,
 - (2020-07-03) Minor release: irccd 3.1.0,
 - (2019-10-06) Bugfix release: irccd 3.0.3,

--- a/news/2020-01-13.diet.md	Wed Jan 20 14:14:38 2021 +0100
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,187 +0,0 @@
-% Going on diet
-% David Demelier <markand@malikania.fr>
-% 2020-01-13
-
-Irccd is going on diet
-======================
-
-Since my original irccd implementation in mostly pure C++11 in 2013, I was
-pretty happy with the result. It was small, lightweight with a clean code base.
-At this time it was also using Lua instead of Javascript but after several
-headaches maintaining support for every Lua version that break compatibility I
-was suggested (by a Lua user!) to use Duktape if I like Javascript.
-
-Anyway, for the version 2.0.0 I've started adding more features and splitting
-the code a lot. It was still fine but I faced several issues with my own code,
-especially in the timer and portable sockets selector (epoll, kqueue, poll) and
-so I decided to move to Boost for the 3.0.0 version.
-
-This was my main regret.
-
-Boost
-=====
-
-Boost is a indeed quality framework that is stable and proven. But it's bloat
-and terribly complex. The code base grown a lot to add generic support and
-required to use templates all over the place. I was quite disappointed about the
-status of the code no matter portable it was. The module [Program_Options][] is
-also total nonsense of complexity to parse simple options. I finally ended up
-writing my own portable [`getopt(3)`][options] in 69 lines of code.
-
-The build process also evolved in the wrong way, it now requires more than five
-minutes to build the entire project even though it only consists of roughly
-19000 lines of code (unicode support adds by itself 5000 lines of pure data).
-
-C++20 and beyond
-================
-
-When I first started learning C++11 I was really loving the new functionalities
-and would honestly not switch to it (from C) if it wasn't there. It's safer,
-more robust and cleaner in several aspects.
-
-But as a guy who needs to updates itself when there are new revisions, I've
-upgraded irccd to newer C++ versions each time they were broadly supported. And
-since C++20 I started scratching my head about the language complexity.
-Concepts, modules, ranges. All syntax are weird and unwelcoming, I personally
-think this language becomes more and more elitist.
-
-Future of irccd 4.0.0
-=====================
-
-Today I'm very glad  announce that I'm rewriting irccd in pure POSIX/C for the
-version 4.0.0.
-
-What's definitely better with C
--------------------------------
-
-- Compile time.
-- Proper error messages.
-- Less time spent on architecture (classes vs templates, polymorphism vs traits,
-  etc…).
-- Simpler code in most cases.
-- Less dynamic allocation.
-- Faster in many places.
-
-Compatibility
--------------
-
-Since irccd is following the [semantic versioning][semver], the 4.0.0 branch is
-allowed to do major breaking changes. But don't run away no many breaking
-changes will happen.
-
-What will change
-----------------
-
-### irccd.conf and irccdctl.conf files
-
-Both tools were using a custom crafted .ini file format. In various places it
-was quite unconvenient to use. For example configuring plugins require to write
-different sections such as:
-
-	[plugins]
-	hangman =
-
-	[plugin.hangman]
-	collaborative = false
-
-	[templates.hangman]
-	win = "congratulations!"
-
-Instead, the new files will be parsed using a custom DSL based on lex/yacc which
-have the benefit of being part of POSIX. The format isn't finalized yet but I
-can promise that it will look much better with some influences from the
-venerable [pf.conf(5)][] file from OpenBSD.
-
-### Networking protocol
-
-To stay simpler, the network messages between `irccd` and `irccdctl` will come
-back to a plain line based UTF-8 messages.
-
-Example:
-
-	MESSAGE freenode #botwar oh hi!
-	TOPIC freenode #botwar this is my new topic.
-
-Error messages will be written in human format and no longer provide specific
-error code either.
-
-### Windows support will be forwarded to second class citizen
-
-Windows isn't a platform I personally like because Microsoft is a company that
-does not cooperate in portability. Writing POSIX software in Windows is a total
-nightmare unless you run cygwin which is also annoying.
-
-Portability code will be added as much as possible as long as they don't pollute
-the code.
-
-### Native API
-
-Obviously by switching from C++ to C, the C++ API becomes totally obsolescent.
-The new exposed C API will be much simpler and less featureful than the previous
-C++ one. This is because I think exposed API must only be related to irccd and
-internal stuff must be kept as that.
-
-Also, the documentation of the exposed C API will be provided in manual pages
-only as doxygen has a poor interface. As always, manual pages will be available
-online as well too.
-
-### Unix transport only
-
-For simplicity reasons, the only transport supported will be based on UNIX
-domain sockets without SSL, without password. Instead users are encouraged to
-set permissions on the socket instead.
-
-This also reduce the code complexity a lot.
-
-What will be kept
------------------
-
-### The Javascript API
-
-Now you can breathe. The Javascript for the most part will be kept untouched
-with a few minor adjustments but your plugins should work without any
-modifications.
-
-### All irccdctl commands
-
-All `irccdctl` commands will be kept as-is without any modification.
-
-Questions and answers
-=====================
-
-Q: Why a bot in C? There are already ones!
-A: Yes, but no one uses Javascript as extending language and no one supports
-   rules and templates like irccd.
-
-Q: Is it a rewrite from scratch?
-A: No. Lot of code was simply converted from C++ to C by adapting some code
-   logic. The javascript being based on the C Duktape library did not need lots
-   of modifications. From scratch code is mostly: new transports, logs and irccd
-   main object.
-
-Q: Which C standard will it be written?
-A: Mostly C99 with few bits from C11 like atomics and noreturn.
-
-Estimated time of arrival
-=========================
-
-For now, the irccd 4 rewrite is on heavy progress and starts to be usable. It
-will be probably released during fall 2021.
-
-Please come back to see the advancement on this page.
-
-- [x] Native plugins.
-- [x] Javascript plugins.
-- [x] Connect to IRC servers and dispatch messages to plugins.
-- [x] Templates.
-- [x] Logs (syslog, console, files).
-- [x] Transport commands (almost complete).
-- [ ] Configuration files.
-- [x] Rules.
-- [x] `irccd` frontend.
-- [x] `irccdctl` frontend.
-
-[semver]: http://semver.org
-[pf.conf(5)]: https://man.openbsd.org/pf.conf
-[Program_Options]: https://www.boost.org/doc/libs/1_75_0/doc/html/program_options.html
-[options]: http://hg.malikania.fr/code/file/tip/cpp/options/options.hpp

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/news/2021-01-13.diet.md	Thu Apr 08 21:17:59 2021 +0200
@@ -0,0 +1,192 @@
+% Going on diet
+% David Demelier <markand@malikania.fr>
+% 2021-01-13
+
+Irccd is going on diet
+======================
+
+Since my original irccd implementation in mostly pure C++11 in 2013, I was
+pretty happy with the result. It was small, lightweight with a clean code base.
+At this time it was also using Lua instead of Javascript but after several
+headaches maintaining support for every Lua version that break compatibility I
+was suggested (by a Lua user!) to use Duktape if I like Javascript.
+
+Anyway, for the version 2.0.0 I've started adding more features and splitting
+the code a lot. It was still fine but I faced several issues with my own code,
+especially in the timer and portable sockets selector (epoll, kqueue, poll) and
+so I decided to move to Boost for the 3.0.0 version.
+
+This was my main regret.
+
+Boost
+=====
+
+Boost is a indeed quality framework that is stable and proven. But it's bloat
+and terribly complex. The code base grown a lot to add generic support and
+required to use templates all over the place. I was quite disappointed about the
+status of the code no matter portable it was. The module [Program_Options][] is
+also total nonsense of complexity to parse simple options. I finally ended up
+writing my own portable [`getopt(3)`][options] in 69 lines of code.
+
+The build process also evolved in the wrong way, it now requires more than five
+minutes to build the entire project even though it only consists of roughly
+19000 lines of code (unicode support adds by itself 5000 lines of pure data).
+
+C++20 and beyond
+================
+
+When I first started learning C++11 I was really loving the new functionalities
+and would honestly not switch to it (from C) if it wasn't there. It's safer,
+more robust and cleaner in several aspects.
+
+But as a guy who needs to updates itself when there are new revisions, I've
+upgraded irccd to newer C++ versions each time they were broadly supported. And
+since C++20 I started scratching my head about the language complexity.
+Concepts, modules, ranges. All syntax are weird and unwelcoming, I personally
+think this language becomes more and more elitist.
+
+Future of irccd 4.0.0
+=====================
+
+Today I'm very glad  announce that I'm rewriting irccd in pure POSIX/C for the
+version 4.0.0.
+
+What's definitely better with C
+-------------------------------
+
+- Compile time.
+- Proper error messages.
+- Less time spent on architecture (classes vs templates, polymorphism vs traits,
+  etc…).
+- Simpler code in most cases.
+- Less dynamic allocation.
+- Faster in many places.
+
+Compatibility
+-------------
+
+Since irccd is following the [semantic versioning][semver], the 4.0.0 branch is
+allowed to do major breaking changes. But don't run away no many breaking
+changes will happen.
+
+What will change
+----------------
+
+### irccd.conf and irccdctl.conf files
+
+Both tools were using a custom crafted .ini file format. In various places it
+was quite unconvenient to use. For example configuring plugins require to write
+different sections such as:
+
+	[plugins]
+	hangman =
+
+	[plugin.hangman]
+	collaborative = false
+
+	[templates.hangman]
+	win = "congratulations!"
+
+Instead, the new files will be parsed using a custom DSL based on lex/yacc which
+have the benefit of being part of POSIX. The format isn't finalized yet but I
+can promise that it will look much better with some influences from the
+venerable [pf.conf(5)][] file from OpenBSD.
+
+### Networking protocol
+
+To stay simpler, the network messages between `irccd` and `irccdctl` will come
+back to a plain line based UTF-8 messages.
+
+Example:
+
+	MESSAGE freenode #botwar oh hi!
+	TOPIC freenode #botwar this is my new topic.
+
+Error messages will be written in human format and no longer provide specific
+error code either.
+
+### Windows support will be forwarded to second class citizen
+
+Windows isn't a platform I personally like because Microsoft is a company that
+does not cooperate in portability. Writing POSIX software in Windows is a total
+nightmare unless you run cygwin which is also annoying.
+
+Portability code will be added as much as possible as long as they don't pollute
+the code.
+
+### Native API
+
+Obviously by switching from C++ to C, the C++ API becomes totally obsolescent.
+The new exposed C API will be much simpler and less featureful than the previous
+C++ one. This is because I think exposed API must only be related to irccd and
+internal stuff must be kept as that.
+
+Also, the documentation of the exposed C API will be provided in manual pages
+only as doxygen has a poor interface. As always, manual pages will be available
+online as well too.
+
+### Unix transport only
+
+For simplicity reasons, the only transport supported will be based on UNIX
+domain sockets without SSL, without password. Instead users are encouraged to
+set permissions on the socket instead.
+
+This also reduce the code complexity a lot.
+
+What will be kept
+-----------------
+
+### The Javascript API
+
+Now you can breathe. The Javascript for the most part will be kept untouched
+with a few minor adjustments but your plugins should work without any
+modifications.
+
+### All irccdctl commands
+
+All `irccdctl` commands will be kept as-is without any modification.
+
+Questions and answers
+=====================
+
+Q: Why a bot in C? There are already ones!
+:   Yes, but no one uses Javascript as extending language and no one supports
+    rules and templates like irccd.
+
+Q: Is it a rewrite from scratch?
+:   No. Lot of code was simply converted from C++ to C by adapting some code
+    logic. The javascript being based on the C Duktape library did not need lots
+    of modifications. From scratch code is mostly: new transports, logs and
+    irccd main object.
+
+Q: Which C standard will it be written?
+:   Mostly C99 with few bits from C11 like atomics and noreturn.
+
+Estimated time of arrival
+=========================
+
+For now, the irccd 4 rewrite is on heavy progress and starts to be usable. It
+will be probably released during fall 2021.
+
+Please come back to see the advancement on this page.
+
+- [x] Native plugins.
+- [x] Javascript plugins.
+- [x] Connect to IRC servers and dispatch messages to plugins.
+- [x] Templates.
+- [x] Logs (syslog, console, files).
+- [x] Transport commands (almost complete).
+- [x] Configuration files.
+- [x] Rules.
+- [x] `irccd` frontend.
+- [x] `irccdctl` frontend.
+- [ ] Excessive testing.
+- [x] Plugin `links` rewrite (was a native C++ plugin).
+- [x] New Irccd.Rule API.
+- [x] New Irccd.Hook API.
+- [x] Hooks.
+
+[semver]: http://semver.org
+[pf.conf(5)]: https://man.openbsd.org/pf.conf
+[Program_Options]: https://www.boost.org/doc/libs/1_75_0/doc/html/program_options.html
+[options]: http://hg.malikania.fr/code/file/tip/cpp/options/options.hpp

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/news/2021-02-16.irccd-4-try.md	Thu Apr 08 21:17:59 2021 +0200
@@ -0,0 +1,42 @@
+% Irccd 4 available for testing
+% David Demelier <markand@malikania.fr>
+% 2021-02-16
+
+Irccd 4 is available for testing
+================================
+
+For less than one month of work, irccd 4 is already available for extreme
+testing. All features are implemented, only tests and miscellaneous fixes or
+cleanup are still pending.
+
+There are some breaking changes but they are documented as usual as it is a
+major change. See [MIGRATING.md][] file for steps required.
+
+How to try
+==========
+
+There are no official releases for alpha software on Malikania, you will need to
+use the [Mercurial][hg] to download irccd 4. The *default* branch at this time
+of writing already contain irccd 4 code.
+
+Install prerequisites as detailed in the [INSTALL.md][] file and you can quickly
+install irccd 4 as following:
+
+	hg clone http://hg.malikania.fr/irccd
+	cd irccd
+	mkdir build
+	cd build
+	cmake .. -DCMAKE_BUILD_TYPE=Debug
+	make && sudo make install
+	(edit a irccd.conf)
+	irccd -c irccd.conf
+
+Please make sure to read the new `irccd.conf(5)` manual page, the syntax has
+changed.
+
+Please report any bugs or error to the [dev mailing list][ml].
+
+[INSTALL.md]: http://hg.malikania.fr/irccd/file/tip/INSTALL.md
+[MIGRATING.md]: http://hg.malikania.fr/irccd/file/tip/MIGRATING.md
+[hg]: http://mercurial-scm.org
+[ml]: http://malikania.fr/mailing-lists.html