- <p>For ncurses, the elapsed time to fix this bug was less than
- three years. Someone reported a problem with the terminal
- description a few weeks after releasing ncurses 6.1 (in <a href=
- "https://github.com/tmux/tmux/issues/1264">tmux #1264</a>), and
- the terminal description was updated that week (ncurses patch
- <a href="@HOMEPAGE@/NEWS.html#t20180224">20180224</a>):</p>
-
- <blockquote>
- <pre class="demo-name">
-20180224
- + modify _nc_resolve_uses2() to detect incompatible types when merging
- a "use=" clause of extended capabilities. The problem was seen in a
- defective terminfo integrated from simpleterm sources in 20171111,
- compounded by repair in 20180121.
- + correct Ss/Ms interchange in st-0.7 entry (tmux #1264) -TD
-</pre>
- </blockquote>
-
- <p>The larger part of that change added a check to prevent a
- simple merge of terminal descriptions where the same user-defined
- name was used with different types. But it raised some
- questions:</p>
-
- <ul>
- <li>
- <p>Was there a reliable way to manage terminal descriptions
- which used the same extended name in different ways?</p>
- </li>
-
- <li>
- <p>Should ncurses provide a registry of well-known extended
- names, with their types?</p>
- </li>
- </ul>
-
- <p>Since the correction to <a href=
- "@HOMEPAGE@/ncurses.html#download_database"><tt>terminfo.src</tt></a>
- could have been readily adopted by packagers, there was nothing
- more to be done from ncurses' standpoint on that part. But
- improving ncurses to prevent issues like that is the reason for
- making a release.</p>
-
- <p>Nothing more (constructive) was mentioned with regard to
- simpleterm. But a few problems were found in the handling of
- user-defined capabilities:</p>
-
- <ul>
- <li>
- <p>Forward-references to user-defined capabilities in a
- “<tt>use=</tt>” clause did not allocate new data
- for each use. In <em>tic</em>, successive compilation of
- terminal entries could add user-defined capabilities to the
- wrong terminal entry.</p>
-
- <p>This was not noticed before, since xterm's terminal
- descriptions were the main users of the feature, and almost
- all of the uses of the building-blocks which contained
- user-defined capabilities were backward-references.</p>
- </li>
-
- <li>
- <p>There is one (documented) case where ncurses 6.1 supports
- a user-defined capability that could be any type (i.e.,
- “RGB”). The check added in February 2018 to guard
- against mismatches did not handle all of the combinations
- needed.</p>
- </li>
- </ul>
-
- <p>Both of these issues dated from the original implementation of
- user-defined capabilities. Fixing them does not change the
- terminal database, but a older <em>tic</em> without the fixes
- will not be able to handle terminfo sources which rely upon those
- fixes. Starting in June 2019, the download link for the terminfo
- source file was capped at that date. The development sources have
- an up-to-date copy of the file, for people with a legitimate need
- for it.</p>
-
- <p>The “<tt>-c</tt>” (check) option of <em>tic</em>
- is not very useful if it cannot offer advice on parameters needed
- for user-defined capabilities. The various <em>Caps</em> files
- were reorganized to reduce redundancy, and in the common portion
- (<a href=
- "https://github.com/ThomasDickey/ncurses-snapshots/blob/master/include/Caps-ncurses">Caps-ncurses</a>),
- a registry of user-defined capabilities is provided for use by
- <em>tic</em>. While users can still define their own custom
- capabilities, <em>tic</em> will not offer any advice when their
- parameters do not match.</p>
-
- <p>In ncurses 6.2, <em>tic</em> makes a special check to allow
- any type for <em>RGB</em>, but its being able to do this relies
- upon fixes made in the ncurses library in mid-2019.</p>
-