GNU bug report logs -
#60936
30.0.50; ERC >5.5: Add erc-fill style based on visual-line-mode
Previous Next
Reported by: "J.P." <jp <at> neverwas.me>
Date: Wed, 18 Jan 2023 14:55:02 UTC
Severity: normal
Tags: patch
Found in version 30.0.50
Fixed in version 30.1
Done: "J.P." <jp <at> neverwas.me>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
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
follows:
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
`erc-insert-post-hook').
[0000-v2-v3.diff (text/x-patch, attachment)]
[0001-5.6-Allow-spoofing-process-marker-in-erc-display-lin.patch (text/x-patch, attachment)]
[0002-5.6-Honor-nil-values-in-erc-restore-initialize-prior.patch (text/x-patch, attachment)]
[0003-5.6-Preserve-format-spec-args-in-erc-server-JOIN.patch (text/x-patch, attachment)]
[0004-5.6-Deprecate-option-erc-remove-parsed-property.patch (text/x-patch, attachment)]
[0005-5.6-Add-helper-for-removing-list-valued-text-props-i.patch (text/x-patch, attachment)]
[0006-5.6-Manage-meta-data-text-props-for-ERC-hook-members.patch (text/x-patch, attachment)]
[0007-5.6-Add-command-to-refill-buffer-with-erc-fill-wrap-.patch (text/x-patch, attachment)]
This bug report was last modified 1 year and 28 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.