______________________________________________________________________

This file is not up to date, some wishes still in developer's personal
mail.
______________________________________________________________________

GoldED+ plans. As always there's no any guarantee of feature
implementation order and that to do list will be implemented at all.
Any help will be appreciated.
______________________________________________________________________

To do:

* Treat empty description as no description in Areafile parser.
* Deleting Synchronet messages, forward reply linking.
* Add Synchronet message base support (aim for 1.1.5).
* AreaYouWroteTo should be able to store copy of mail after change.
* Optionally add complete set of fidonet kludges to AreaIsEmail.
* E-mail/news signature support (or it already present? :))
* Refresh message header after calling externutil.
* Try to save position in message after printing, changing xlat table,
  etc.
* Major xlat/recode engine update (in progress).
* CUI in input prompts.
* Activating built-in MIME-QP convertor by key (on whole message).
* Postpone.
* Highlight up to 3 groups of users by different color.
* Implicit address completion in addressbook.
* Addressbook sorting in various ways.
* Addressbook <-> macrofile synchronization
* Mouse support
* Better threading support.
* Read unread messages (either will be done via selection of unread
  messages or when storing of unread status will be implemented).
* Add separators to Arealistformat, i.e. Arealistformat "A|E|G".
* Entering to locked area should allow to select another area instead.
* CODEPAGE kludge support.
* Switching code page at message reading using information from CHRS kludge
  (some OS only).
* Message text preprocessing with externutil.
* Add *.* (DOS-based) or * (*nix) to attach path if not specified.
* Marking messages with reply in lister.
* Macro-tokens (@token like externutil parameters) in TaskTitle
* Select areas in crosspost menu.
* Replace prinf format string with special macrovariables in goldlang.cfg
  (prevent Golded+ crash with invalid config, improve functionality of
  goldlang.cfg parser).
* Big-endian platforms support.
* Insert from pipe in internal editor.
* Create directory three for output file if not exists.
______________________________________________________________________

To fix:

* UUdecoder not 100% reliable: any volunteers for uulib maintaining?
* Need some workarounds on -install feature under UNIX-like OS.
______________________________________________________________________

Known wishes that not currently planned (any volunteers?):

* Interactive Twit-list edition.
* Pass areaname, message number, etc. to external utility.
* Hide empty areas / areas without new messages from arealist.
* SMTP support.
* NNTP support.
* Forward multiple messages.
* Peeking up message from area while in edit mode.
* Screen grabber.
* Language support for menu (ReadMainMenu).
* Mark areas with unsent mail.
* Trashcan for mail.
* Selection of codepage for outgoing message.
* Ability to change directory in attach picker.
*** Any of your suggestion may be placed here ;-)
______________________________________________________________________

______________________________________________________________________

Found while reviewing the UTF-8 work for repeated code, 2026-08-25.
What is listed here is what is left; the faults found at the same time
have been dealt with.

Design, in rough order of what it would buy:

* The conversion is still half a parameter and half a global, but the
  half-measures around it are gone: XlatStr() has a form that takes
  the recoder, XlatSnapshot()/XlatRestore() round-trip both halves of
  the state as one value, the spell checker snapshots the recoder next
  to each of its tables instead of converting through whatever
  happened to be global - which is what kept it from reaching a
  dictionary in an 8-bit charset from a UTF-8 session - and the
  header-field poke in MakeLineIndex is scoped and undone. What
  remains of the idea: LoadCharset() still deposits its result in
  CharTable/CharRecoder and returns a bare level, and the twenty-odd
  XlatStr() callers still read the ambient state they just loaded.
  Handing the loaded conversion around as a value everywhere is
  mechanical from here, and only worth it together with a reason to
  touch all those places.

Wasted work:

* RecodeChar() still consumes one character per call, which is what
  the wrap loop's column counting needs. The cost that made it worth
  listing is gone: for a single-byte source charset - every message
  read from an 8-bit echo - the recoder now works all 256 conversions
  out once and looks them up, instead of a convert() with an iconv
  shift-state reset per character. What remains is the rare multibyte
  source (UTF-8 text imported into an 8-bit session), which still
  converts character by character; batching that means teaching the
  wrap loop to take a converted run and find its own break points, and
  the loop's special cases make that a careful job for little gain.

______________________________________________________________________

Emoji and everything else outside the BMP, 2026-08-26.

Everything found here has been dealt with except the last item, which
is not ours to fix. Kept because it explains a fault that will be
reported again.

* A character whose width the terminal and the host's wcwidth() do not
  agree on will smear on screen: it draws over its neighbour, or a
  second copy of it appears as the cursor is walked along the line.
  Curses places the character by wcwidth() and the terminal draws it by
  its own tables, and when those differ the two disagree about where
  everything after it belongs. Nothing in GoldED+ reaches that gap - we
  can only be consistent with curses, which we are. Seen with U+1FABE
  on NetBSD 11 under iTerm2: wcwidth() says two columns, the terminal
  draws one. Characters both sides know - and that is all of them bar
  the very newest - behave.

* The same disagreement in the other direction, for the same reason:
  curses adds up a sequence joined by zero-width joiners codepoint by
  codepoint and makes a joined family six columns, where the terminal
  draws one glyph in two. We follow the terminal, because that is what
  the reader sees. There is no answer that satisfies both.

______________________________________________________________________

Spell checking, 2026-08-26.

* CMYSpellLang::Load() reports success whenever the Hunspell object was
  constructed, which `new' always manages, so a dictionary that failed
  to parse - a wrong path, a truncated file - leaves the checker
  believing it is loaded. Every word then comes back correct, and the
  feature quietly does nothing. It should ask the dictionary something
  it must know before saying it is loaded.

* (Fixed since: BuildRTable() snapshots the recoders beside the tables
  - mToDicRecoder/mToLocRecoder - and RecodeText() uses them, so a
  UTF-8 session converts to an 8-bit dictionary correctly. The Load()
  bullet above still stands.)

______________________________________________________________________

A VT backend for the Windows console, the way FAR Manager drives it.
Attempted 2026-08-27 and backed out; what was learned is here so the
next attempt starts where this one ended.

Windows is currently driven through the cell API, with two console-
specific detours measured in and neither avoidable: conhost draws a
surrogate pair laid across two cells and shuffles a row if a stream
write lands on it, while Windows Terminal cannot draw the pair from
cells at all (microsoft/terminal#10810) and needs the stream. The
program tells the two apart by WT_SESSION. It works, but it is two
code paths and an environment variable where FAR has one answer:
when the console grants ENABLE_VIRTUAL_TERMINAL_PROCESSING, drive it
with escape sequences; the cell path stays for Windows before 10.

A naive emitter - CUP, SGR, text, restore - is not enough, and
regressed visibly in conhost within minutes. The reasons, from FAR's
console.cpp (WriteOutputVT, ~line 1870):

* Escape sequences address the viewport; the cell and scroll APIs
  address the buffer. With scrollback the two differ, so CUP-addressed
  writes desynchronise from ScrollConsoleScreenBuffer. FAR pins the
  viewport before every write by moving the real cursor to the buffer
  bottom and back, and refuses CUP outright: "the viewport origin is
  too unstable to rely on it".
* The cursor is hidden for the write; each row ends with restore,
  move down, save again, and an explicit colour reset, because conhost
  stopped preserving colours across the restore (terminal#14612).
* Full rows are ended with \n as a hint that the content is
  structured, which also fixes a resize fault (terminal#15153).
* Cells are sanitised on the way out - lone surrogates and control
  codes must not reach the stream.
* GoldED+ scrolls sub-rectangles (ScrollConsoleScreenBuffer); VT
  cannot express that, so under VT those become repaints.
* vsave/vrestore and vsetattr also read and write cells and would
  need VT-coherent forms.

* Windows Terminal leaves stale pixels at the right edge of rows
  holding combining marks - the leftover scrollbar after the reader
  closes. In the cell model every codepoint is a cell, so a row of
  Thai or Devanagari holds more cells than it has columns; Windows
  Terminal shapes those cells into clusters when it draws, the row
  comes out visually shorter than the buffer row, and what the shaped
  row no longer covers is not repainted. conhost draws cell-for-cell
  and does not show it. Nothing at the cell level fixes this - it is
  the same cells-versus-clusters gap, and the VT backend above closes
  it by letting the terminal do the layout of a byte stream instead.

Do it in one deliberate pass, following FAR line by line, and test
every step in BOTH consoles: in the attempt, each of the two found a
different fault within minutes of each other.

______________________________________________________________________

The personal-mail scan now compares names in the charset the area
imports (WidePMUsername), which is right for the common case - a CP866
base under a UTF-8 session. Two edges are left deliberately: a base
whose messages carry different charsets per message is compared against
the area's single import charset, so a name in the odd message out can
still be missed - fixing that would mean reading every header's kludges
during the scan, which is what the scan's speed forbids; and the
AdeptXBBS driver builds a Personal_Mail *filename* from the username,
which on a CP866 filesystem wants the converted form too but is left
alone until someone actually runs AdeptXBBS.

The JAM lastread continuity: the user's lastread record is found by a
CRC over the name, now computed in the base's charset - the same value
every pre-UTF-8 reader wrote, so old lastreads match again. A lastread
written by the 20260825-20260827 snapshots was computed over the UTF-8
name and will appear as a fresh user once; the old record stays in the
file, harmless.

______________________________________________________________________

Left over from the audit's fourth batch, deliberately: the compiled
help (golded__.ghp) is rebuilt when the help file changes; whether a
change of XLATLOCALSET alone retriggers it is worth one check now that
the conversion lives in ReadHelpCfg() - if not, a stale compiled copy
keeps the old charset until the help file is touched. A macro in GOLDKEYS.CFG that
types non-ASCII text plays back byte by byte; the bytes arrive in
order and may well form the right characters, but nobody has verified
the whole path, and the byte-per-gkey storage halves the capacity.
The GetQuotestr/MAXQUOTELEN quote-prefix buffers are still forty bytes
against a forty-character intent, with a dozen consumers sized to
match - worth one deliberate pass of its own.

______________________________________________________________________

CJK in the window toolkit's own builders: disp_item() in the menus and
wputs() advance one cell per character, so a double-width character in
a menu item overlaps its neighbour on Windows (the reader's own text
went through gvid_cellcp and is right). Fixing it wants a
platform-neutral wide-aware cell appender exported from gvidbase - a
deliberate small project, not a one-liner, and Cyrillic is unaffected.
The OS/2 VIO path likewise still counts bytes as cells if an OS/2
build is ever run with a UTF-8 locale.

* Pictures: a Windows Terminal Sixel path through the Win32 backend
  (VT output); passing the graphics through tmux and screen; kitty's
  transmit-once-place-many so a scrolled picture is not sent again;
  a window opened over an inline picture on Sixel and iTerm2 leaves
  a hole in it until the body is painted again.
