The new scanner with an internal read-ahead buffer contains an
inefficiency in which the underlying buffer is shifted left every time a
token is consumed.

Fix this by delaying the shift until an actual read-ahead from the
source IO handle is made, and only if the shift is required.

Signed-off-by: Jose Lombera <jose@lombera.dev>
---
We can observe the performance inefficiency with following simple
program that counts the newlines in a file.

	use bufio;
	use fmt;
[message trimmed]

On 2023-02-21 19:59 UTC, Drew DeVault wrote:
> The performance of yes(1) is not of any conseqeunce. Simplicity is the
> word.

Yes, it makes sense.  Just wondering if someone could have some use-case
expecting a performant yes(1).  Not my case, though.

On 2023-02-21 14:32 UTC, jgart wrote:
> hi,
>
> v3 simplies some logic in the if statement
>
> ---
>  Makefile |  4 +++-
>  yes.ha   | 22 ++++++++++++++++++++++
>  2 files changed, 25 insertions(+), 1 deletion(-)
>  create mode 100644 yes.ha
>
> diff --git a/Makefile b/Makefile
> index c568580..298db4b 100644
> --- a/Makefile

On 2023-02-20 19:19 UTC, Robin Jarry wrote:
> Jose Lombera, Feb 20, 2023 at 19:17:
> > I'm fine with the change to GPL.
> >
> > Approved-by: Jose Lombera <jose@lombera.dev>
> >
> > On 2023-02-20 18:59 UTC, Robin Jarry wrote:
> > > Hi all,
> > >
> > > as you may know, aerc is currently distributed under the MIT license.
> > > This prevents from shipping aerc with notmuch support always enabled
> > > (notmuch being GPL).
> >
> > Does this mean notmuch will be enabled by default?  Or will we still

I'm fine with the change to GPL.

Approved-by: Jose Lombera <jose@lombera.dev>

On 2023-02-20 18:59 UTC, Robin Jarry wrote:
> Hi all,
>
> as you may know, aerc is currently distributed under the MIT license.
> This prevents from shipping aerc with notmuch support always enabled
> (notmuch being GPL).

Does this mean notmuch will be enabled by default?  Or will we still
have to pass `GOFLAGS=-tags=notmuch` to `make` and `make install` every
time.

On Wed Feb 15, 2023 at 3:45 PM CST, Lassi Pulkkinen wrote:

> > Now the `service` parameter is redundant.
>
> No it isn't. It's used to provide a default, whereas `addr` would
> typically be user-provided.
>
> > In any case, none of the expectations of a valid address string format
> > (whether it is hostname/IPv4/IPv6; has port/service) nor which
> > service/port has priority is documented.  All this should be documented
> > so that they aren't just implementation details.
>
> This is documented on the `dial` function; that should indeed be
> updated to reflect these changes. (Conspicuously, it leaves the

On Wed Feb 15, 2023 at 10:26 AM CST, Lassi Pulkkinen wrote:

> Allow IPv6 without port
> Allow service name in address string

Is this really required?  Now the `service` parameter is redundant.

In any case, none of the expectations of a valid address string format
(whether it is hostname/IPv4/IPv6; has port/service) nor which
service/port has priority is documented.  All this should be documented
so that they aren't just implementation details.

>
> Signed-off-by: Lassi Pulkkinen <lassi@pulk.fi>

On Sat Feb 11, 2023 at 4:44 AM CST, Drew DeVault wrote:

> This scanner maintains an internal read-ahead buffer for greater
> efficiency of scanning operations without requiring the user to
> configure their own buffered stream underneath. It also returns strings
> and slices borrowed from the internal buffer, eliminating memory
> allocations within scan loops.
>
> Implements: https://todo.sr.ht/~sircmpwn/hare/562
> Signed-off-by: Drew DeVault <sir@cmpwn.com>
> ---
> Leaning towards replacing all of the scan* variants with scan_* and
> renaming scan_* => scan (which is the breaking change I was talking
> about before).

On Fri Feb 10, 2023 at 6:04 AM CST, Drew DeVault wrote:
> This scanner maintains an internal read-ahead buffer for greater
> efficiency of scanning operations without requiring the user to
> configure their own buffered stream underneath. It also returns strings
> and slices borrowed from the internal buffer, eliminating memory
> allocations within scan loops.
>
> Signed-off-by: Drew DeVault <sir@cmpwn.com>
> ---
> RFC:
>
> What should we do with the old scanner functions? I'm in favor of a
> breaking change which replaces the old ones with the new ones (and drops
> the _ in the new names), then forces users to maintain a scanner

On Fri Feb 10, 2023 at 1:39 PM CST, Bor Grošelj Simić wrote:

> > I haven't investigated the reason for this, though.  Probably a cyclic
> > dependency or something??
>
> It's actually a missing dependency that happens to be "fixed" in a rather
> unlikely way when building in parallel. It is fixed by:
> https://lists.sr.ht/~sircmpwn/hare-dev/patches/38885

Thanks!