[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug#60936: 30.0.50; ERC >5.5: Add erc-fill style based on visual-lin

From: J.P.
Subject: Re: bug#60936: 30.0.50; ERC >5.5: Add erc-fill style based on visual-line-mode
Date: Fri, 06 Oct 2023 08:17:23 -0700
User-agent: Gnus/5.13 (Gnus v5.13)

v3. Move new meta-data related text properties to a single-character
interval at the head of every message. Add facility for managing such
props on behalf of modification hooks. Add utilities for retrieving data
from message-delimiting props and for traversing inserted messages.

In an attempt to tamp down on the growing mound of complications
involved in wrangling text properties across modules, I'm proposing a
general facility for managing certain props going forward. It works as

  1. confine meta-data related props to a one-char interval that, along
     with a preceding newline, delimit all message boundaries [1]

  2. apply nonessential message-spanning props, like
     `cursor-sensor-functions', lazily and only as needed by their
     controlling options [2]

  3. offer a means of passing state between hook stages, optionally to
     end up as properties in the meta-data interval

  4. keep this mechanism internal for the time being, but have it manage
     most props introduced in 5.6

In some ways, this amounts to a major reworking of how ERC handles
messages during and after insertion. Initially, I wanted to defer such
an endeavor to 5.7, but it's become clear to me that doing this now will
immensely fortify the implementation of various features shipping with
this release. If you're a module author or would-be contributor, it's in
your interest to keep an eye on how this unfolds. Happy to answer
questions or concerns, as always. Thanks.

[1] In an ideal world, a message's properties would live on its
    preceding newline. However, ERC's hooks have always visited messages
    along with their trailing newline. Obviously, having hooks see
    properties for the message to follow (or having the current
    message's props live on its trailing newline) would never work.

[2] Props whose intervals inform their role, such as buttons, faces, and
    display/formatting attributes, can't easily conform to this system.
    But, we can still benefit from formally declaring the hook stage
    (and maybe specific depth range) at which such props should be
    added. For example, message-spanning props ought to be applied no
    earlier than post-modification (e.g., `erc-send-post-hook' and

Attachment: 0000-v2-v3.diff
Description: Text Data

Attachment: 0001-5.6-Allow-spoofing-process-marker-in-erc-display-lin.patch
Description: Text Data

Attachment: 0002-5.6-Honor-nil-values-in-erc-restore-initialize-prior.patch
Description: Text Data

Attachment: 0003-5.6-Preserve-format-spec-args-in-erc-server-JOIN.patch
Description: Text Data

Attachment: 0004-5.6-Deprecate-option-erc-remove-parsed-property.patch
Description: Text Data

Attachment: 0005-5.6-Add-helper-for-removing-list-valued-text-props-i.patch
Description: Text Data

Attachment: 0006-5.6-Manage-meta-data-text-props-for-ERC-hook-members.patch
Description: Text Data

Attachment: 0007-5.6-Add-command-to-refill-buffer-with-erc-fill-wrap-.patch
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]