Bug#1012325: dialog: Multi-Arch: foreign package should not contain static library

[Thomas Dickey]

On Thu, Jan 05, 2023 at 04:05:29PM +0100, Santiago Vila wrote:
> Thanks a lot for the patch.
> 
> Yes, it would make sense to move *.h and .a to a libdialog-dev package.
> 
> But I'm not sure about the best way to proceed after reading the reply from 
> Thomas:
> 
> > actually, a shared library is generally preferred for development packages.
> > This is what I build for my own use (scripts in the package/debian 
> > directory),
> > as "cdialog-dev":
> > 
> > /usr/bin/cdialog-config*
> > /usr/include/cdialog/dlg_colors.h
> > /usr/include/cdialog/dlg_config.h
> > /usr/include/cdialog/dlg_keys.h
> > /usr/include/cdialog.h
> > /usr/share/doc/cdialog-dev/changelog.Debian.gz
> > /usr/share/doc/cdialog-dev/changelog.gz
> > /usr/share/doc/cdialog-dev/copyright
> > /usr/share/man/man3/cdialog.3.gz
> > /lib/x86_64-linux-gnu/libcdialog.so@
> 
> In Debian the static library has always been named libdialog.a,
> but the library according to the author is called libcdialog.so.

A development package could have both static and dynamic libraries.
dialog can build either, but not both at the same time (just like ncurses).
 
> If I go ahead and create a shared library package (which I suspect is
> the only thing ftpmasters will accept if they see NEW binary packages),
> should I worry about binary compatibility with other distros?
> 
> Thanks.
> 

-- 
Thomas E. Dickey 
https://invisible-island.net


signature.asc
Description: PGP signature

Re: X11 font size

[Thomas Dickey via X11-users]

On Thu, Jan 05, 2023 at 09:41:35PM +0100, René J.V. Bertin via X11-users wrote:
> On Wednesday January 04 2023 21:42:17 Peter Dyballa wrote:
> >
> >> Am 4.1.2023 um 21:00 schrieb Clark Souers:
> >> 
> >> How do I increase X11 font size on a Mac Big Sur 11.7.2? I am using 
> >> Xquartz 2.7.11. should I update to 2.82?
> >
> >There is, as far as I know, no such means. Each X client can have its own 
> >font at its own size. 
> 
> That's not the entire truth.  It does apply to legacy applications that use
> only X11 primitives for font rendering, but AFAIK libXft (`man Xft`) does
> provide a global scale factor representing the DPI resolution of the screen
> (or rather, entire desktop):

DPI resolution isn't the same as font size. Xft uses fontconfig for
managing this, as noted in the manual page:

https://invisible-island.net/xterm/xft/xft.html

 FC_DPI
  Dots/inch  used  for  resolution (default: computed from
  the display height).

https://www.freedesktop.org/software/fontconfig/fontconfig-devel/x19.html

dpiFC_DPI Double  Target dots per inch
size   FC_SIZEDouble  Point size

Font size is usually measured in points (not pixels/dots), because that
directly relates to how large the characters appear on the screen, rather
than how crisp they are.

(xterm does both types of fonts)

The Xft values are all implemented as properties via fontconfig
(actually, X resources).

xterm (and some other applications) get those via a call to
XftDefaultSubstitute:

https://gitlab.freedesktop.org/xorg/lib/libxft/-/blob/master/src/xftdpy.c#L481
 
> ```
> > xrdb -query | fgrep Xft
> Xft.antialias:  1
> Xft.autohint:   0
> Xft.dpi:86
> Xft.hinting:1
> Xft.hintstyle:  hintfull
> Xft.lcdfilter:  lcddefault
> Xft.rgba:   rgb
> ```

None of those resources deal with font _size_, but only provide help for
applications to display using a given size.  So there's no guarantee that
any two X applications are using the same font size (except of course for
the case where they're using the same toolkit, e.g., Qt).

-- 
Thomas E. Dickey 
https://invisible-island.net


signature.asc
Description: PGP signature
 ___
Do not post admin requests to the list. They will be ignored.
X11-users mailing list  (X11-users@lists.apple.com)
Help/Unsubscribe/Update your Subscription: 
https://lists.apple.com/mailman/options/x11-users/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: However accented characters are still rather broken

[Thomas Dickey]

On Mon, Jan 02, 2023 at 03:27:20PM -0500, Thomas Dickey wrote:
> On Mon, Jan 02, 2023 at 11:23:54AM +, Chris Green wrote:
> > So, after partially understanding the syntax highlighting issue I now
> > see that entering accented characters is still broken.
> > 
> > As reported a while ago vile 9.8v gets confused when you try to enter
> > accented characters (I use a Multi_key, so to enter, for example an e
> > with an acute accent I hit Multi_key, e, ').
> > 
> > On vile 9.8u (and earlier, I've checked 9.8t too) entering accented
> > characters with the Multi_key works perfectly.  On 9.8v (as reported)
> > on entering an accented character an odd backslash sequence is echoed
> > and it's not the character entered.
> > 
> > On vile 9.8w (from the Ubuntu repository) entering an accented
> > character does nothing if you enter just one accented character but if
> > you enter a second accented character that *does* get added.  This
> > continues, entering a series of accented characters every other one
> > actually gets inserted.

fwiw, this was introduced at the time that I fixed this bug:
 
 20220805 (w)
+ revise change for lins_chars() to handle UTF-8 in scripts, as that
  interfered with normal insertions (report by Chris Green).

and the "odd backslash" was from an earlier change to the same code:

+ modify lins_chars() to handle a case where a script inserts a UTF-8
  character (report by Thomas Dupond).

I think I'll have time later this week to re-revisit this (and make both
scripts and interactive editing work at the same time).

-- 
Thomas E. Dickey 
https://invisible-island.net


signature.asc
Description: PGP signature

Re: Start again with syntax highlighting problem

[Thomas Dickey]

- Original Message -
| From: "Gary Jennejohn" 
| To: "Vile mailing list" 
| Sent: Monday, January 2, 2023 3:02:03 PM
| Subject: Re: Start again with syntax highlighting problem

| On Mon, 2 Jan 2023 14:17:43 -0500
| Thomas Dickey  wrote:
| 
|> On Mon, Jan 02, 2023 at 10:45:14AM +, Chris Green wrote:
|> > OK, restart, I think I now see a pattern in this.  I completely
|> > removed and re-installed vile from the Ubuntu repositories on esprimo
|> > and it is now working correctly there.  I had modified it there
|> > because of the issue a while ago with UTF8 characters.  So the table
|> > is now as follows:-
|> >
|> > backup  xubuntu 22.10   vile 9.8w   colour OK, but not right
|> > bison   Android 11  vile 9.8w   colour OK, but not right
|> > caracal Debian 10   vile 9.8no colour syntax
|> > cheddar Debian 10   vile 9.8t   colour OK
|> > esprimo xubuntu 22.04   vile 9.8v   colour OK
|> > isbdUbuntu 20.04vile 9.8t   colour OK
|> > odinDebian 9vile 9.8s   colour OK
|> > pimedia Debian 11   vile 9.8u   colour OK
|> > t470xubuntu 22.10   vile 9.8w   colour OK, but not right
|> > tsohost very oldvile 9.8no colour syntax
|> >
|> >
|> > This makes *much* more sense! :-)  The systems with versions older
|> > than vile9.8w do syntax highlighting OK.  The two systems where I
|> > built vile myself and installed as a user (no root access) don't do
|> > syntax highlighting but thati's almost certainly something I have
|> > missed out in the build and it's not so important there anyway.
|> >
|> > So, the question is why the syntax highlighting of vilemode for
|> > version 9.8w is messed up.  It's not badly wrong, it gets the colour
|>
|> I made an incorrect bug-fix in 9.8w for vilemode, which is fixed in 9.8x
|>
|> This was the change (reverting it will fix the bug):
|>
|> @@ -17,7 +17,7 @@
|>
|>  #define FLTSTACK_EXTRA int with_state; int with_active;
|>  #define FltStack_WITH_STATE   FLTSTACK_THIS.with_state
|> -#define FltStack_WITH_ACTIVE  FLTSTACK_THIS.with_state
|> +#define FltStack_WITH_ACTIVE  FLTSTACK_THIS.with_active
|>  #include 
|>
|>  #if defined(_estruct_h) && !SMALLER
|>
| 
| This is peculiar.  In my 9.8w code (FreeBSD) this error is not present.

The tarballs and patches should match the snapshots that I export to Git:

https://github.com/ThomasDickey/vile-snapshots/commit/49e69b2a9c24709e8dc6534842c531f036fc6ef5#diff-2f62c16021dc47a5af4606a274a77fe2684bb704641a215e2c7147e8e7d8c362

|> > of comments right throughout but gets confused about keyword colours
|> > and within some 'map' settings.  As far as I can see on other file
|> > types (shell scripts, python, C) version 9.8w gets the highlighting
|> > correct so it does look like just an error in the vilemode
|> > highlighting.
|> >
|> > Has the vile-filt-filt file changed between 9.8v and 9.8w?

-- 
Thomas E. Dickey 
https://invisible-island.net

Re: However accented characters are still rather broken

[Thomas Dickey]

On Mon, Jan 02, 2023 at 11:23:54AM +, Chris Green wrote:
> So, after partially understanding the syntax highlighting issue I now
> see that entering accented characters is still broken.
> 
> As reported a while ago vile 9.8v gets confused when you try to enter
> accented characters (I use a Multi_key, so to enter, for example an e
> with an acute accent I hit Multi_key, e, ').
> 
> On vile 9.8u (and earlier, I've checked 9.8t too) entering accented
> characters with the Multi_key works perfectly.  On 9.8v (as reported)
> on entering an accented character an odd backslash sequence is echoed
> and it's not the character entered.
> 
> On vile 9.8w (from the Ubuntu repository) entering an accented
> character does nothing if you enter just one accented character but if
> you enter a second accented character that *does* get added.  This
> continues, entering a series of accented characters every other one
> actually gets inserted.

I hadn't noticed this, but can reproduce it (with 9.8x, and in a quick
test with empty .vilerc, the same).  Attaching a debug trace with 6
keypresses, 3 characters inserted.

-- 
Thomas E. Dickey 
https://invisible-island.net
| old_locale 'en_US.UTF-8'
| called {{ vl_get_encoding(en_US.UTF-8)
| return }} UTF-8
| system getenv LC_ALL=en_US.UTF-8
| Checking for UTF-8 suffix of 'en_US.UTF-8'
| called {{ vl_narrowed(en_US.UTF-8)
| system getenv VILE_LOCALE_MAPPING=
| regparser {/\.\(UTF\|utf\)[-]\?8$//}
| ...regparser {\.\(UTF\|utf\)[-]\?8$}
| regparser {//}
| ...regparser {}
| regcomp("\\.\\(UTF\\|utf\\)[-]\\?8$", magic)
| after regmassage: '\\.(UTF|utf)[-]?8$'
| vl_narrowed match ".UTF-8", replace with ""
| return }} en_US
| called {{ vl_init_8bit(en_US.UTF-8, en_US)
| setup mixed-locale(en_US.UTF-8, en_US)
| called {{ vl_get_encoding(en_US.UTF-8)
| | return }} UTF-8
| called {{ vl_get_encoding(en_US)
| | return }} ISO-8859-1
| ...locale encodings(UTF-8, ISO-8859-1)
| try_encoding(from=ISO-8859-1, to=UTF-8) OK
| fixed-up 0 of 256 8bit/utf8 mappings
| assume 256 Latin1 codes
| return }} 
| setlocale(en_US) -> 'en_US'
| called {{ vl_get_encoding(en_US)
| return }} ISO-8859-1
| called {{ vl_ctype_init() lo=0, hi=0
| wide_locale:en_US.UTF-8
| narrow_locale:en_US
| current_locale:en_US
| Forcing printable for [128..min(-1,255)]
| return }} 
| called {{ global_val_init()
| regcomp("\\(\\[\\([!]\\?[[:print:]]\\+\\)\\]\\)\\|\\([[:ident:].-]\\+\\)", 
magic)
| after regmassage: '(\\[([!]?[[:print:]]+)\\])|([[:ident:].-]+)'
| regcomp("^\\s*\\(\\(\\s*[#*>]\\)\\|\\(///*\\)\\)\\+", magic)
| after regmassage: '^\\s*((\\s*[#*\\>])|(///*))+'
| regcomp("^\\s*/\\?\\(\\s*[#*>/]\\)\\+/\\?\\s*$", magic)
| after regmassage: '^\\s*/?(\\s*[#*\\>/])+/?\\s*$'
| regcomp("/\\*", magic)
| after regmassage: '/\\*'
| regcomp("^\\s*#\\s*elif\\>", magic)
| after regmassage: '^\\s*#\\s*elif>'
| regcomp("^\\s*#\\s*else\\>", magic)
| after regmassage: '^\\s*#\\s*else>'
| regcomp("\\*/", magic)
| after regmassage: '\\*/'
| regcomp("^\\s*#\\s*endif\\>", magic)
| after regmassage: '^\\s*#\\s*endif>'
| regcomp("^\\s*#\\s*if", magic)
| after regmassage: '^\\s*#\\s*if'
| regcomp("\\w\\+", magic)
| after regmassage: '\\w+'
| regcomp("\\(\\.orig\\|~\\)$", magic)
| after regmassage: '(\\.orig|~)$'
| 
regcomp("^\\.[ILPQ]P\\>\\|^\\.P\\>\\|^\\.LI\\>\\|^\\.[plinb]p\\>\\|^\\.\\?\\s*$",
 magic)
| after regmassage: '^\\.[ILPQ]P>|^\\.P>|^\\.LI>|^\\.[plinb]p>|^\\.?\\s*$'
| regcomp("[[:file:]]\\+", magic)
| after regmassage: '[[:file:]]+'
| 
set_buf_fname_expr(\(\(\[\([!]\?[[:print:]]\+\)\]\)\|\([[:ident:].-]\+\)\|[[:file:]]\+\))
| 
regcomp("\\(\\(\\[\\([!]\\?[[:print:]]\\+\\)\\]\\)\\|\\([[:ident:].-]\\+\\)\\|[[:file:]]\\+\\)",
 magic)
| after regmassage: '((\\[([!]?[[:print:]]+)\\])|([[:ident:].-]+)|[[:file:]]+)'
| regcomp("^[{^L]\\|^\\.[NS]H\\>\\|^\\.HU\\?\\>\\|^\\.[us]h\\>\\|^+c\\>", magic)
| after regmassage: '^[\\{^L]|^\\.[NS]H>|^\\.HU?>|^\\.[us]h>|^\\+c>'
| regcomp("[.!?][])"']* \\?$\\|[.!?][])"']*  
\\|^\\.[ILPQ]P\\>\\|^\\.P\\>\\|^\\.LI\\>\\|^\\.[plinb]p\\>\\|^\\.\\?\\s*$", 
magic)
| after regmassage: '[.!\\?][]\\)"']* ?$|[.!\\?][]\\)"']*  
|^\\.[ILPQ]P>|^\\.P>|^\\.LI>|^\\.[plinb]p>|^\\.?\\s*$'
| set_state_variable(empty-lines,1)
| ...set_state_variable ->1
| set_state_variable(filename-expr,[[:file:]])
| regcomp("[[:file:]]", magic)
| after regmassage: '[[:file:]]'
| ...set_state_variable ->1
| vile getenv VILE_HELP_FILE=
| set_state_variable(helpfile,vile.hlp)
| ...set_state_variable ->1
| 
set_state_variable(latin1-expr,^\(aa\|af\|br\|de\|en\|es\|fr\|fi\|ga\|gb\|gl\|gv\|id\|it\|kl\|ms\|nl\|nn\|om\|pt\|so\|sv\|tl\)_[A-Za-z]\+$)
| 
regcomp("^\\(aa\\|af\\|br\\|de\\|en\\|es\\|fr\\|fi\\|ga\\|gb\\|gl\\|gv\\|id\\|it\\|kl\\|ms\\|nl\\|nn\\|om\\|pt\\|so\\|sv\\|tl\\)_[A-Za-z]\\+$",
 magic)
| after regmassage: 
'^(aa|af|br|de|en|es|fr|fi|ga|gb|gl|gv|id|it|kl|ms|nl|nn|om|pt|so|sv|tl)_[A-Za-z]+$'
| called {{ vl_init_8bit(en_US.UTF-8, en_US)
| | setup mixed-locale(en_US.UTF-8, en_US)
| | called {{ vl_get_encoding(en_US.UTF-8)
| | | return 

Re: Start again with syntax highlighting problem

[Thomas Dickey]

On Mon, Jan 02, 2023 at 10:45:14AM +, Chris Green wrote:
> OK, restart, I think I now see a pattern in this.  I completely
> removed and re-installed vile from the Ubuntu repositories on esprimo
> and it is now working correctly there.  I had modified it there
> because of the issue a while ago with UTF8 characters.  So the table
> is now as follows:-
> 
> backup  xubuntu 22.10   vile 9.8w   colour OK, but not right
> bison   Android 11  vile 9.8w   colour OK, but not right
> caracal Debian 10   vile 9.8no colour syntax
> cheddar Debian 10   vile 9.8t   colour OK
> esprimo xubuntu 22.04   vile 9.8v   colour OK
> isbdUbuntu 20.04vile 9.8t   colour OK
> odinDebian 9vile 9.8s   colour OK
> pimedia Debian 11   vile 9.8u   colour OK
> t470xubuntu 22.10   vile 9.8w   colour OK, but not right
> tsohost very oldvile 9.8no colour syntax
> 
> 
> This makes *much* more sense! :-)  The systems with versions older
> than vile9.8w do syntax highlighting OK.  The two systems where I
> built vile myself and installed as a user (no root access) don't do
> syntax highlighting but thati's almost certainly something I have
> missed out in the build and it's not so important there anyway.
> 
> So, the question is why the syntax highlighting of vilemode for
> version 9.8w is messed up.  It's not badly wrong, it gets the colour

I made an incorrect bug-fix in 9.8w for vilemode, which is fixed in 9.8x

This was the change (reverting it will fix the bug):

@@ -17,7 +17,7 @@
 
 #define FLTSTACK_EXTRA int with_state; int with_active;
 #define FltStack_WITH_STATE   FLTSTACK_THIS.with_state
-#define FltStack_WITH_ACTIVE  FLTSTACK_THIS.with_state
+#define FltStack_WITH_ACTIVE  FLTSTACK_THIS.with_active
 #include 
 
 #if defined(_estruct_h) && !SMALLER

> of comments right throughout but gets confused about keyword colours
> and within some 'map' settings.  As far as I can see on other file
> types (shell scripts, python, C) version 9.8w gets the highlighting
> correct so it does look like just an error in the vilemode
> highlighting.
> 
> Has the vile-filt-filt file changed between 9.8v and 9.8w?
> 
> -- 
> Chris Green
> 

-- 
Thomas E. Dickey 
https://invisible-island.net


signature.asc
Description: PGP signature

Re: Syntax colour highlighting problem - not working on some of my systems

[Thomas Dickey]

On Sun, Jan 01, 2023 at 08:02:31PM +, Chris Green wrote:
> On Sun, Jan 01, 2023 at 06:13:07PM +, Chris Green wrote:
> > The eternal problem
> > 
> > On just *some* of my several Linux systems colour syntax higlighting
> > isn't working.  It always used to work but I really can't see what I
> > might have changed on *some* systems to break it.
> > 
> > The systems and versions and 'working or not' are:-
> > 
> > backup  xubuntu 22.10   vile 9.8w   colour OK
> > bison   Android 11  vile 9.8w   colour OK
> > caracal Debian 10   vile 9.8no colour syntax
> > cheddar Debian 10   vile 9.8t   colour OK
> > esprimo xubuntu 22.04   vile 9.8u   no colour syntax
> > isbdUbuntu 20.04vile 9.8t   colour OK
> > odinDebian 9vile 9.8s   colour OK
> > pimedia Debian 11   vile 9.8u   colour OK
> > t470xubuntu 22.10   vile 9.8w   colour OK
> > tsohost very oldvile 9.8no colour syntax
> > 
> > Since esprimo is my main desktop system it's a bit annoying that
> > syntax colouring isn't working there.
> > 
> > On all systems 'show-colors' in vile works fine, so they're all
> > *capable* of colour. The two systems showing just vile 9.8 are ones
> > where I have built vile myself, so they have pretty recent code.
> > 
> > All systems have the same .vilerc and it runs with no errors.  So they
> > all execute:-
> > 
> > source filters.rc
> > setv $autocolor-hook HighlightFilter
> > setv $read-hook HighlightFilter
> > set autocolor=500
> > set bcolor=default
> > 
> > I'm stumped!  Can anyone point me at some way to diagnose what's
> > wrong? Could it (possibly) be something to do with built-in or
> > external filters?  If so, how do I tell whether vile was built with
> > 'built-in' or not?
> > 
> Just to add to the fun if I run xvile remotely across an 'ssh -Y'
> connection to esprimo the syntax highlighting works OK.  (that's
> running xvile on esprimo from t470)
> 
> This suggests to me that it's something to do with how vile was built
> (it's the version from the repositories).

vile's running in a terminal.  I'd check if the terminal is configured for
color: disregarding hard-coded stuff, the value of $TERM is used to select
a terminal description.  If it's "vt100" on some machines, that would explain.

Running this from the command-line will show colors only if the terminal is 
configured:

#!/bin/sh
tput blink
tput bold
tput setab 1
tput setaf 4
printf "Hello-"
tput setaf 1
tput setab 4
echo "world"
tput sgr0
read aa

-- 
Thomas E. Dickey 
https://invisible-island.net


signature.asc
Description: PGP signature

ncurses 6.4

[Thomas Dickey]

Announcing ncurses 6.4

Overview

   The  ncurses  (new  curses)  library  is  a free software emulation of
   curses  in  System  V  Release  4.0 (SVr4), and more. It uses terminfo
   format,  supports  pads  and  color  and multiple highlights and forms
   characters and function-key mapping, and has all the other SVr4-curses
   enhancements  over  BSD curses. SVr4 curses became the basis of X/Open
   Curses.

   In  mid-June  1995,  the  maintainer of 4.4BSD curses declared that he
   considered  4.4BSD curses obsolete, and encouraged the keepers of unix
   releases such as BSD/OS, FreeBSD and NetBSD to switch over to ncurses.

   Since 1995, ncurses has been ported to many systems:
 * It is used in almost every system based on the Linux kernel (aside
   from some embedded applications).
 * It  is  used  as the system curses library on OpenBSD, FreeBSD and
   MacOS.
 * It  is used in environments such as Cygwin and MinGW. The first of
   these was EMX on OS/2 Warp.
 * It is used (though usually not as the system curses) on all of the
   vendor  unix  systems,  e.g.,  AIX,  HP-UX,  IRIX64, SCO, Solaris,
   Tru64.
 * It should work readily on any ANSI/POSIX-conforming unix.

   The distribution includes the library and support utilities, including
 * captoinfo, a termcap conversion tool
 * clear, utility for clearing the screen
 * infocmp, the terminfo decompiler
 * tabs, set tabs on a terminal
 * tic, the terminfo compiler
 * toe, list (table of) terminfo entries
 * tput,  utility  for  retrieving  terminal  capabilities  in  shell
   scripts
 * tset, to initialize the terminal

   Full manual pages are provided for the library and tools.

   The ncurses distribution is available at ncurses' homepage:

 https://invisible-island.net/archives/ncurses/ or
 https://invisible-mirror.net/archives/ncurses/ .

   It is also available at the GNU distribution site

 https://ftp.gnu.org/gnu/ncurses/ .

Release Notes

   These notes are for ncurses 6.4, released December 31, 2022.

   This  release  is  designed  to  be source-compatible with ncurses 5.0
   through  6.3; providing extensions to the application binary interface
   (ABI).  Although  the  source  can  still be configured to support the
   ncurses  5  ABI, the reason for the release is to reflect improvements
   to the ncurses 6 ABI and the supporting utility programs.

   There  are,  of  course,  numerous  other improvements, listed in this
   announcement.

   The   most  important  bug-fixes/improvements  dealt  with  robustness
   issues.  The  release notes also mention some other bug-fixes, but are
   focused  on  new  features and improvements to existing features since
   ncurses 6.3 release.

  Library improvements

New features

   There are no new features in this release.

Other improvements

   These are improvements to existing features:
 * modify  delscreen  to  more  effectively delete all windows on the
   given screen.
 * modify  wnoutrefresh  to  call  pnoutrefresh if its parameter is a
   pad,  rather than treating it as an error, and modify new_panel to
   permit its window-parameter to be a pad
 * modify  curses_trace()  to  show  the trace-mask as symbols, e.g.,
   TRACE_ORDINARY, DEBUG_LEVEL(3).
 * improve  checks  for valid mouse events when an intermediate mouse
   state is not part of the mousemask specified by the caller
 * allow extended-color number in opts parameter of wattr_on.
 * improve _tracecchar_t2 formatting of base+combining character.
 * trim  out some unwanted linker options from ncurses*config and .pc
   files seen in Fedora 36+.
 * improve shell-scripts with shellcheck
 * improve use of "trap" in shell scripts, using a script.
 * modify make-tar.sh scripts to make timestamps more predictable.

   These are corrections to existing features:
 * modify  misc/gen-pkgconfig.in  to  allow  for  the  case where the
   library  directory  does  not  yet  exist, since this is processed
   before doing an install
 * set trailing null on string passed from winsnstr to wins_nwstr.
 * modify  waddch_literal  to  allow  for double-width base character
   when merging a combining character

  Program improvements

   Several improvements were made to the utility programs:

   infocmp

  + rewrite  canonical_name  function of infocmp to ensure buffer
size
  + improve  readability  of  long parameterized expressions with
the  infocmp  "-f"  option  by  allowing  split before a "%p"
marker.
  + modify   verbose-option   of  infocmp,  tic,  toe  to  enable
debug-tracing if that is configured.

   tabs
  limit tab-stop values to max-columns

   tic
  add   consistency   check   in   tic  for  u6/u7/u8/u9  and  NQ
  

Bug#1027435: ncurses-base: Breaks pasting in vim within tmux

[Thomas Dickey]

On Sat, Dec 31, 2022 at 02:18:49PM +0100, Antoine Le Gonidec wrote:
> Package: ncurses-base
> Version: 6.3+20221224-2
> Severity: important

that's probably this - which will be in today's update/release:

--- ncurses-6.3-20221224+/misc/terminfo.src 2022-12-24 18:18:58.0 
+
+++ ncurses-6.4-20221231/misc/terminfo.src  2022-12-29 20:11:56.0 
+
@@ -6,8 +6,8 @@
 # Report bugs and new terminal descriptions to
 #  bug-ncur...@gnu.org
 #
-#  $Revision: 1.1039 $
-#  $Date: 2022/12/24 18:18:58 $
+#  $Revision: 1.1041 $
+#  $Date: 2022/12/29 20:11:56 $
 #
 # The original header is preserved below for reference.  It is noted that there
 # is a "newer" version which differs in some cosmetic details (but actually
@@ -5768,7 +5768,7 @@
 # detail.  The names for the extended capabilities here were introduced by vim
 # in January 2017.
 bracketed+paste|xterm bracketed paste,
-   BD=\E[?2004l, BE=\E[?2004h, PD=\E[201~, PE=\E[200~,
+   BD=\E[?2004l, BE=\E[?2004h, PE=\E[201~, PS=\E[200~,
 
  XTERM Mouse
 # The xterm mouse protocol is used by other terminal emulators.
@@ -8210,7 +8210,7 @@
use=screen4,
 
 no+brackets|cancel bracketed paste,
-   BD@, BE@, PD@, PE@,
+   BD@, BE@, PE@, PS@,
 
 # The bce and status-line entries are from screen 3.9.13 (and require some
 # changes to .screenrc).
@@ -25508,8 +25508,8 @@
 #
 # BE enables bracketed paste
 # BD disables bracketed paste
-# PE is sent before the pasted text
-# PD is sent after the pasted text
+# PS is sent before the pasted text
+# PE is sent after the pasted text
 #
 # Here are the other xterm-related extensions which are used in this file:
 #
@@ -27713,4 +27713,8 @@
 #  + add/use bracketed+paste to help identify terminals supporting this
 #xterm feature (prompted by discussion with Bram Moolenaar) -TD
 #
+# 2022-12-29
+#  + correct PS vs PE names in bracketed+paste (report by Bram Moolenaar)
+#-TD
+#
  SHANTIH!  SHANTIH!  SHANTIH!

-- 
Thomas E. Dickey 
https://invisible-island.net


signature.asc
Description: PGP signature

[Lynx-dev] ANN: lynx2.9.0dev.11

[Thomas Dickey]

The current version of lynx is 2.8.9

It's available at
https://lynx.invisible-island.net/
https://invisible-island.net/archives/lynx/
2.9.0 Development & patches:
https://lynx.invisible-island.net/current/index.html

Files:
  https://invisible-island.net/archives/lynx/patches/lynx2.9.0dev.11.patch.gz
  
https://invisible-island.net/archives/lynx/patches/lynx2.9.0dev.11.patch.gz.asc
  https://invisible-island.net/archives/lynx/tarballs/lynx2.9.0dev.11.tar.bz2
  
https://invisible-island.net/archives/lynx/tarballs/lynx2.9.0dev.11.tar.bz2.asc
  https://invisible-island.net/archives/lynx/tarballs/lynx2.9.0dev.11.tar.gz
  https://invisible-island.net/archives/lynx/tarballs/lynx2.9.0dev.11.tar.gz.asc
  https://invisible-island.net/archives/lynx/tarballs/lynx2.9.0dev.11.zip

2022-12-28 (2.9.0dev.11)
* update ncurses/lynx homepage URLs to deprecate ftp -TD
* modify configure script to reduce implicit-function warnings (report by
  Florian Weimer) -TD
* update configure script to work around regression in grep 3.8 -TD
* add some consistency-checks to dtd_util to make it easier to use -TD
* improve formatting of bookmark file, e.g., to fix warnings by tidy -TD
* correct workaround for asan2 report of overlapping strcpy (report by KH) -TD
* amend fix for Debian #738121; URL-encoded "?" in HTFile.c corresponds to an
  actual "?" in a file path (report by TG) -TD
* before calling delscreen, delete the private working windows in case delwin
  invalidates those (Debian #1015756) -TD
* add presentation type for xhtml, related state information to better handle
  things such as "" -Shlomi Fish, TD
* improve line-breaks and whitespace for Japanese characters -KH
  + permit line breaks after any Japanese character (enabled by
--enable-wcwidth-support configuration and only called on last byte of
multibyte UTF-8 sequence)
  + avoid adding spaces when joining lines after Japanese characters.
* add new "Minimal" user mode, to minimize on-screen help/status.
  Eliminates the URL on the bottom line, the forward/backward indicator in the
  upper left, and most status-line messages - Paul G Fox
* add PREVENT_KEYBOARD_WRAPAROUND symbol to userdefs.h 
  Undefing this will allow cursor to wrap from bottom to/from top, when there's
  more content than a single page.  (It can already wrap when the content
  already fits on a page.) - Paul G Fox
* modify NSL-fork to call freeaddrinfo only if getaddrinfo returns successfully
  (patch by Rajeev V Pillai)
* add ".br", ".lz", ".lzip", and ".xz" to binary-suffixes list -TD
* changes for using brotli stream decompression -TD
* changes for working with SOCKS5 on Windows 10 -GV, -TD
* fix a few coverity and clang warnings -TD
* add a null-pointer check in StrAllocVsprintf() to work with existing SOCKS5
  configuration (report/patch by Gisle Vanem).
* change capitalization of "Content-type" sent to the remote server to work
  around "HeavyThing" server which does not follow RFC 2616 in treating field
  name as case insensitive (report/patch by Sylvain Bertrand)
* improved several configure macros:
  AM_WITH_NLS, CF_ADD_INCDIR, CF_BUILD_CC, CF_CHECK_EXTERN_DATA,
  CF_DISABLE_ECHO, CF_FIX_WARNINGS, CF_MAKEFLAGS, CF_MATH_LIB,
  CF_NCURSES_CONFIG, CF_NCURSES_LIBS, CF_PKG_CONFIG, CF_PROG_LINT,
  CF_SIZECHANGE, CF_TRY_XOPEN_SOURCE, CF_WITH_PATH, CF_XOPEN_SOURCE
* update config.guess (2022-08-01), config.sub (2022-08-01)

-- 
Thomas E. Dickey 
https://invisible-island.net


signature.asc
Description: PGP signature

ANN: vile-9.8x

[Thomas Dickey]

Files:
  https://invisible-island.net/archives/vile/current/vile-9.8x.tgz
  https://invisible-island.net/archives/vile/current/vile-9.8x.tgz.asc
  https://invisible-island.net/archives/vile/patches/MD5sums
  https://invisible-island.net/archives/vile/patches/vile-9.8x.patch.gz
  https://invisible-island.net/archives/vile/patches/vile-9.8x.patch.gz.asc

 https://invisible-island.net/archives/vile/patches/vile-9.8x.patch.gz
 patch by Thomas E. Dickey 
 created  Tue Dec 27 00:30:42 UTC 2022
 --
 CHANGES|   48 
 MANIFEST   |   20 
 README |   18 
 README.PC  |8 
 aclocal.m4 |  116 
 api.c  |4 
 basic.c|6 
 bind.c |   18 
 cmdtbl |6 
 config.guess   |   50 
 config.sub |   22 
 configure  | 6063 +--
 configure.in   |   49 
 curses.c   |   26 
 doc/macros.doc |6 
 doc/macros.html|  109 
 doc/makefile   |3 
 doc/vile-hlp.html  |  113 
 doc/vile-man.html  |  121 
 doc/vile-toc.html  |5 
 edef.h |4 
 filters/vilefilt.l |6 
 input.c|9 
 install-sh |  687 +-
 macros/uxvile  |6 
 macros/vile-libdir-path|8 
 macros/vile-pager  |   43 
 main.c |   54 
 map.c  |   95 
 mktbls.c   |   34 
 modetbl|5 
 package/convile.nsi|6 
 package/debian/changelog   |6 
 package/debian/control |   29 
 package/debian/rules   |  261 
 package/debian/vile-common.examples|1 
 package/debian/vile-common.files   |5 
 package/debian/vile-filters.files  |8 
 package/debian/vile.postinst   |4 
 package/debian/vile.prerm  |4 
 package/debian/xvile.files |3 
 package/freebsd/vile/Makefile  |6 
 package/freebsd/vile/distinfo  |6 
 package/freebsd/vile/pkg-plist |6 
 package/freebsd/xvile/Makefile |7 
 package/freebsd/xvile/distinfo |6 
 package/freebsd/xvile/pkg-plist|6 
 package/minvile.nsi|6 
 package/pkgsrc/vile/Makefile   |9 
 package/pkgsrc/vile/PLIST  |8 
 package/pkgsrc/vile/distinfo   |   10 
 package/pkgsrc/xvile/Makefile  |9 
 package/pkgsrc/xvile/PLIST |8 
 package/vile.spec  |   11 
 package/winvile.iss|4 
 package/winvile.nsi|6 
 patchlev.h |4 
 proto.h|8 
 revlist|  155 
 statevar.c |   14 
 tcap.c |   16 
 trace.c|4 
 vile-9.8x/icons/pumpkin.ico|binary
 vile-9.8x/icons/sink.ico   |binary
 vile-9.8x/icons/vile-mini.ico  |binary
 vile-9.8x/icons/vile.ico   |binary
 vile-9.8x/package/debian/vile-common.README.Debian |   11 
 vile-9.8x/package/openbsd/Makefile |   26 
 vile-9.8x/package/openbsd/distinfo |2 
 vile-9.8x/package/openbsd/patches/patch-crypt  |   72 
 vile-9.8x/package/openbsd/pkg/DESCR|9 
 vile-9.8x/package/openbsd/pkg/PLIST|  138 
 vile.1 |   12 
 vile.hlp

Re: [Lynx-dev] Converting Unicode characters to ASCII: Control Pictures block

[Thomas Dickey]

- Original Message -
| From: "Tim Chase" 
| To: "lynx-dev" 
| Cc: "Thorsten Glaser" 
| Sent: Sunday, December 25, 2022 3:55:52 PM
| Subject: Re: [Lynx-dev] Converting Unicode characters to ASCII: Control 
Pictures block

| On 2022-12-25 13:57, Thorsten Glaser wrote:
|> Tim Chase dixit:
|>> but it looks like it causes weird behaviors.
|> 
|> Huh? Works well for me. It just outputs the character, which
|> is a printable character. Are you sure you have your terminal
|> and lynx in UTF-8 mode both?
| 
| My locale is pretty boring:
| 
|  $ locale
|  LANG=en_US.UTF-8
|  LC_CTYPE="en_US.UTF-8"
|  LC_COLLATE="en_US.UTF-8"
|  LC_TIME="en_US.UTF-8"
|  LC_NUMERIC="en_US.UTF-8"
|  LC_MONETARY="en_US.UTF-8"
|  LC_MESSAGES="en_US.UTF-8"
|  LC_ALL=
| 
| and as shown in the attached screenshot, using printf to write that
| [esc] character to the screen displays fine (it displays as expected).
| However, when I view it in lynx, it shows nothing (as captured in
| the second screenshot)
| 
| If I force the display charset using
| 
|  lynx --display_charset=utf-8 delme.html
| 
| it does render the character as you describe.  So I think you've
| tracked where the breakdown is happening.  Is there some environment
| variable I've missed to inform lynx that this particular terminal
| is UTF8 aware?  What does lynx use to determine terminal utf8'ness
| if it's not explicitly specified on with --display_charset?

https://lynx.invisible-island.net/lynx_help/body.html#LOCALE_CHARSET

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://ftp.invisible-island.net

[Touch-packages] [Bug 1999171] Re: tparm dynamic variables broken

[Thomas Dickey]

Dynamic variables are maintained as part of the currently opened terminal.
As noted, if you want to open a bug against ncurses (rather than Ubuntu 
packaging),
this won't get as much attention as the bug-ncurses mailing list, or the Debian 
package
(which Ubuntu provides without change).

** Changed in: ncurses (Ubuntu)
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ncurses in Ubuntu.
https://bugs.launchpad.net/bugs/1999171

Title:
  tparm dynamic variables broken

Status in ncurses package in Ubuntu:
  Invalid

Bug description:
  I use the Python curses library for convenience, but this seems to be
  an ncurses bug as Python simply wraps the ncurses library.

  As you can see from example below, the dynamic variable x gets stored as 4, 
but, when it's
  recalled, 0 is returned instead of 4. This was on 22.04 and 20.04 with 
libncurses6 6.3-2.

  I've confirm the behavior is correct on Fedora 36 with ncurses-
  libs-6.2-9.20210508. I apologize I haven't been able to narrow it down
  farther, but figured it would be good to get a bug logged in case
  someone has more insight.

  ```
  Python 3.10.6 (main, Nov  2 2022, 18:53:38) [GCC 11.3.0] on linux
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import curses
  >>> curses.setupterm()
  >>> curses.tparm(b'%p1%Px', 4)
  b''
  >>> curses.tparm(b'%gx%d')
  b'0'
  ```

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ncurses/+bug/1999171/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1999171] Re: tparm dynamic variables broken

[Thomas Dickey]

https://invisible-island.net/ncurses/man/terminfo.5.html#h3-Parameterized-Strings
https://invisible-island.net/personal/bug-reports.html#low_support

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ncurses in Ubuntu.
https://bugs.launchpad.net/bugs/1999171

Title:
  tparm dynamic variables broken

Status in ncurses package in Ubuntu:
  New

Bug description:
  I use the Python curses library for convenience, but this seems to be
  an ncurses bug as Python simply wraps the ncurses library.

  As you can see from example below, the dynamic variable x gets stored as 4, 
but, when it's
  recalled, 0 is returned instead of 4. This was on 22.04 and 20.04 with 
libncurses6 6.3-2.

  I've confirm the behavior is correct on Fedora 36 with ncurses-
  libs-6.2-9.20210508. I apologize I haven't been able to narrow it down
  farther, but figured it would be good to get a bug logged in case
  someone has more insight.

  ```
  Python 3.10.6 (main, Nov  2 2022, 18:53:38) [GCC 11.3.0] on linux
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import curses
  >>> curses.setupterm()
  >>> curses.tparm(b'%p1%Px', 4)
  b''
  >>> curses.tparm(b'%gx%d')
  b'0'
  ```

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ncurses/+bug/1999171/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Re: [Lynx-dev] Porting the configure script to C99

[Thomas Dickey]

On Fri, Dec 02, 2022 at 11:16:32PM +0100, Florian Weimer wrote:
> * Thomas Dickey:
> 
> >> diff --git a/configure b/configure
> >> index 97f6d1d5646d05c5..6db52b514b3b9a3c 100755
> >> --- a/configure
> >> +++ b/configure
> >> @@ -31122,6 +31122,7 @@ else
> >>  #line 31122 "configure"
> >>  #include "confdefs.h"
> >>  
> >> +#include 
> >>  #if HAVE_TERMIO_H
> >>  #include 
> >>  #endif
> >> @@ -31629,6 +31630,9 @@ else
> >>  #line 31629 "configure"
> >>  #include "confdefs.h"
> >>  /* Thanks to Mike Rendell for this test.  */
> >> +#if HAVE_UNISTD_H
> >> +# include 
> >> +#endif
> >
> > "middle chunk" is referring to this, I suppose.
> >
> > AC_INCLUDES_DEFAULT includes a lot of headers, not just this one.
> >
> > what problem does that #include solve?
> 
> Our configure says this at the top: “Generated by Autoconf
> 2.52.20210509.”  I don't think it uses AC_INCLUDES_DEFAULT yet, it
> seems:

I was actually talking about the "newer" version of autoconf.

But it's simple to add.
 
> | configure: failed program was:
> | #line 31629 "configure"
> | #include "confdefs.h"
> | /* Thanks to Mike Rendell for this test.  */
> | #include 
> | #define NGID 256
> | #undef MAX
> | #define MAX(x, y) ((x) > (y) ? (x) : (y))
> | 
> | int
> | main (void)
> | {
> |   gid_t gidset[NGID];
> |   int i, n;
> |   union { gid_t gval; long lval; }  val;
> | 
> |   val.lval = -1;
> |   for (i = 0; i < NGID; i++)
> | gidset[i] = val.gval;
> |   n = getgroups (sizeof (gidset) / MAX (sizeof (int), sizeof (gid_t)) - 1,
> |  gidset);
> |   /* Exit non-zero if getgroups seems to require an array of ints.  This
> |  happens when gid_t is short but getgroups modifies an array of ints.  
> */
> |   return ((n > 0 && gidset[n] != val.gval) ? 1 : 0);
> | }
> 
> Full build log is here:
> 
>   
> <https://gitlab.com/fweimer-rh/fedora-modernc-logs/-/blob/fbf287fbe1e977fad4ef23390174e6f6d584f5c7/logs/l/lynx.log>
> 
> >>  #include 
> >>  #define NGID 256
> >>  #undef MAX
> >> @@ -47492,6 +47496,7 @@ else
> >>  #line 47492 "configure"
> >>  #include "confdefs.h"
> >>  
> >> +#include 
> >
> > ...shouldn't be needed, since both curses.h and slang.h include stdio.h
> > (LYCurses.h includes one or the other, as well as HTUtils.h)
> 
> Okay, my mistake, but the first putchar change *is* needed:

sounds good.  Actually this report is like another which talks about tgoto
and arc4random (which I intended fixing).  I'll have some improvements
in this area for dev.11 (changing those requires testing in different
configurations -- unlike these).
 
> | configure: In function 'main':
> | configure:31133:1: error: implicit declaration of function 'putchar'
> | 31133 | {
> |   | ^  
> | configure:31143: $? = 1
> | configure: failed program was:
> | #line 31122 "configure"
> | #include "confdefs.h"
> | 
> | #if HAVE_TERMIO_H
> | #include 
> | #endif
> | #if HAVE_TERMIOS_H
> | #include 
> | #endif
> | int
> | main (void)
> | {
> | putchar (0x0a)
> |   ;
> |   return 0;
> | }
> 
> Thanks,
> Florian
> 

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Re: [Lynx-dev] Porting the configure script to C99

[Thomas Dickey]

On Fri, Dec 02, 2022 at 04:04:32PM +0100, Florian Weimer wrote:
> We're trying to build Fedora with a strict(er) C99 compiler:
> 
>   
>   
> 
> Testing I dentified a couple of issues in the lynx configure script
> (version 2.9.0dev.10 I believe):
> 
> diff --git a/aclocal.m4 b/aclocal.m4
> index 70cde243d2129cc0..bf2cbff661de2fe1 100644
> --- a/aclocal.m4
> +++ b/aclocal.m4
> @@ -6435,6 +6435,7 @@ AC_CACHE_CHECK(if we can include termio.h with 
> curses,cf_cv_termio_and_curses,[
>  CPPFLAGS="$CPPFLAGS -DHAVE_CONFIG_H -I. -I${srcdir:-.} 
> -I${srcdir:-.}/src -I${srcdir:-.}/WWW/Library/Implementation"
>  touch lynx_cfg.h
>  AC_TRY_COMPILE([
> +#include 

thanks.

>  #include <$1>
>  #include ],
>  [putchar(0x0a)],
> @@ -6455,6 +6456,7 @@ AC_DEFUN([CF_TERMIO_AND_TERMIOS],
>  AC_MSG_CHECKING([termio.h and termios.h])
>  AC_CACHE_VAL(cf_cv_termio_and_termios,[
>  AC_TRY_COMPILE([
> +#include 

ok.

>  #if HAVE_TERMIO_H
>  #include 
>  #endif
> diff --git a/configure b/configure
> index 97f6d1d5646d05c5..6db52b514b3b9a3c 100755
> --- a/configure
> +++ b/configure
> @@ -31122,6 +31122,7 @@ else
>  #line 31122 "configure"
>  #include "confdefs.h"
>  
> +#include 
>  #if HAVE_TERMIO_H
>  #include 
>  #endif
> @@ -31629,6 +31630,9 @@ else
>  #line 31629 "configure"
>  #include "confdefs.h"
>  /* Thanks to Mike Rendell for this test.  */
> +#if HAVE_UNISTD_H
> +# include 
> +#endif

"middle chunk" is referring to this, I suppose.

AC_INCLUDES_DEFAULT includes a lot of headers, not just this one.

what problem does that #include solve?

>  #include 
>  #define NGID 256
>  #undef MAX
> @@ -47492,6 +47496,7 @@ else
>  #line 47492 "configure"
>  #include "confdefs.h"
>  
> +#include 

...shouldn't be needed, since both curses.h and slang.h include stdio.h
(LYCurses.h includes one or the other, as well as HTUtils.h)

>  #include 
>  #include 
>  int
> 
> The middle hunk in the configure patch is fixed in later autoconf
> releases, it's not something that comes from aclocal.m4 or configure.in.
> 
> I'm sharing this here for the benefit of other distributions working on
> similar projects.
> 
> Thanks,
> Florian
> 
> 

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Re: CI commit checks (was: [ANNOUNCE] libXft 2.3.7)

[Thomas Dickey]

On Wed, Nov 30, 2022 at 04:57:04PM -0800, Alan Coopersmith wrote:
> On 11/16/22 01:08, Thomas Dickey wrote:
> > On Tue, Nov 15, 2022 at 03:27:38PM -0500, Thomas E. Dickey wrote:
> > > Thomas E. Dickey (4):
> > >libxft issue #15
> > >fix compiler warning
> > >libxft issue #16
> > 
> > I hadn't thought of this while committing the changes,
> > but had used short titles because a CI rule limited lines to 80 columns.
> > (I saw some note about that being undone for some projects(*), 
> > uncertain...).
> 
> We're working through dropping the requirement for signed-off-by lines, but
> I've not heard anything about dropping the 80 column rule.  But then, I'm not
> aware of any X.Org repos in which we block the commit for failing the check,

I found it necessary to rebase a few dozen commits in June when I updated
libXt, because gitlab refused to accept my merge of just a few new changes.

As I recall it, it didn't like the older commits anymore.

> we just make the CI status red.  We could reduce that from error to warning
> as well (which I think we've already done in the xserver repo, but not 
> others).
> 
> > For the record, the full titles here would be longer than 80:
> >  libxft issue #16
> >  https://gitlab.freedesktop.org/xorg/lib/libxft/-/issues/16
> >  Stack gets smashed in fonts with colors when calling XftGlyphRender
> >  BGRA changes made incorrect comparison for local vs allocated
> >  buffer in XftGlyphSpecRender
> 
> None of those lines look longer than 80 characters to me.

They aren't, because I split the lines, based on prior experience :-)
 
> > and
> > 
> >  libxft issue #15
> >  https://gitlab.freedesktop.org/xorg/lib/libxft/-/issues/15
> >  XftFontLoadGlyphs for mono font returns wrong info in extents from
> >  XftTextExtentsUtf8 for variable chars
> 
> That one you would need to cut down a bit, but could still put in more info
> than just an issue number,

agreed - but as I pointed out, I'd forgotten that the first line of the
commits would be the result in the mail-announcement.

(I have other changes in mind, but am working on several things...)

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Re: CI commit checks (was: [ANNOUNCE] libXft 2.3.7)

[Thomas Dickey]

On Wed, Nov 30, 2022 at 04:57:04PM -0800, Alan Coopersmith wrote:
> On 11/16/22 01:08, Thomas Dickey wrote:
> > On Tue, Nov 15, 2022 at 03:27:38PM -0500, Thomas E. Dickey wrote:
> > > Thomas E. Dickey (4):
> > >libxft issue #15
> > >fix compiler warning
> > >libxft issue #16
> > 
> > I hadn't thought of this while committing the changes,
> > but had used short titles because a CI rule limited lines to 80 columns.
> > (I saw some note about that being undone for some projects(*), 
> > uncertain...).
> 
> We're working through dropping the requirement for signed-off-by lines, but
> I've not heard anything about dropping the 80 column rule.  But then, I'm not
> aware of any X.Org repos in which we block the commit for failing the check,

I found it necessary to rebase a few dozen commits in June when I updated
libXt, because gitlab refused to accept my merge of just a few new changes.

As I recall it, it didn't like the older commits anymore.

> we just make the CI status red.  We could reduce that from error to warning
> as well (which I think we've already done in the xserver repo, but not 
> others).
> 
> > For the record, the full titles here would be longer than 80:
> >  libxft issue #16
> >  https://gitlab.freedesktop.org/xorg/lib/libxft/-/issues/16
> >  Stack gets smashed in fonts with colors when calling XftGlyphRender
> >  BGRA changes made incorrect comparison for local vs allocated
> >  buffer in XftGlyphSpecRender
> 
> None of those lines look longer than 80 characters to me.

They aren't, because I split the lines, based on prior experience :-)
 
> > and
> > 
> >  libxft issue #15
> >  https://gitlab.freedesktop.org/xorg/lib/libxft/-/issues/15
> >  XftFontLoadGlyphs for mono font returns wrong info in extents from
> >  XftTextExtentsUtf8 for variable chars
> 
> That one you would need to cut down a bit, but could still put in more info
> than just an issue number,

agreed - but as I pointed out, I'd forgotten that the first line of the
commits would be the result in the mail-announcement.

(I have other changes in mind, but am working on several things...)

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Re: Build errors at link time - what am I missing?

[Thomas Dickey]

- Original Message -
| From: "Chris Green" 
| To: "Vile mailing list" 
| Sent: Wednesday, November 30, 2022 6:42:39 PM
| Subject: Re: Build errors at link time - what am I missing?

| On Wed, Nov 30, 2022 at 06:32:59PM -0500, Thomas Dickey wrote:
|> On Wed, Nov 30, 2022 at 08:26:07PM +, Chris Green wrote:
|> > On Wed, Nov 30, 2022 at 08:20:53PM +, Chris Green wrote:
|> > > I'm trying to build vile-9.8 on a Debian system where I have a shared
|> > > hosting account with ssh access.
|> > > 
|> > > I'm doing "./configure --prefix=$HOME" and it runs OK but there are
|> > > couple of warnings.
|> > > 
|> > > Firstly it can't find a good lex so it says:-
|> > > configure: WARNING: disabling build for lex-filters
|> > > I don't think this is going to be an issue.
|> > > 
|> > > However, later on in configure I get:-
|> > > configure: WARNING: Cannot find -ltermlib, -lcurses, or -ltermcap
|> > > and then at link time there are loads of undefined references to
|> > > tputs, tgoto, and a lot of other tx symbols.
|> > > 
|> > > So presumably I need to build one of those libraries, or is there
|> > > something simpler I can do?
|> > > 
|> > The system does have libncurses, it's in /usr/lib/x86_64-linux-gnu. Is
|> > it possible that directory isn't on the cc/linker search path?  How do
|> > I add it?
|> 
|> You need the development package.  The runtime package has a similarly named
|> library file.
|> 
|> For example (Debian/oldstable)
|> 
|> libtinfo6 has
|> /usr/lib/x86_64-linux-gnu/libtic.so.6
|> 
|> libncurses-dev hs
|> /usr/lib/x86_64-linux-gnu/libtinfo.so
|> 
|> The plain ".so" is what development packages link with, e.g., -ltinfo
|> 
| There's some .so files buried deep down:-
| 
|chrisisbd@caracal:/usr/lib/x86_64-linux-gnu/zsh/5.7.1$ cd zsh
|chrisisbd@caracal:/usr/lib/x86_64-linux-gnu/zsh/5.7.1/zsh$ ls
|attr.so  complist.so   example.so   nearcolor.so  pcre.so system.so
|zleparameter.so
|cap.so   computil.so   files.so net   regex.so
termcap.so
|zprof.so
|clone.so curses.so langinfo.so  newuser.sorlimits.so  
terminfo.so
|zpty.so
|compctl.so   datetime.so   mapfile.so   param sched.sozftp.so
|zselect.so
|complete.so  deltochar.so  mathfunc.so  parameter.so  stat.so zle.so
|zutil.so
| 
| Will these allow me to build if I include that directory in the ld search 
path?
| If so, how do I include that directory?
| 
| If not then I guess I'll have to build ncurses as desribed in the E-Mail 
before.

Brendan's advice is the way to go.

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://ftp.invisible-island.net

Re: Build errors at link time - what am I missing?

[Thomas Dickey]

On Wed, Nov 30, 2022 at 08:26:07PM +, Chris Green wrote:
> On Wed, Nov 30, 2022 at 08:20:53PM +, Chris Green wrote:
> > I'm trying to build vile-9.8 on a Debian system where I have a shared
> > hosting account with ssh access.
> > 
> > I'm doing "./configure --prefix=$HOME" and it runs OK but there are
> > couple of warnings.
> > 
> > Firstly it can't find a good lex so it says:-
> > configure: WARNING: disabling build for lex-filters
> > I don't think this is going to be an issue.
> > 
> > However, later on in configure I get:-
> > configure: WARNING: Cannot find -ltermlib, -lcurses, or -ltermcap
> > and then at link time there are loads of undefined references to
> > tputs, tgoto, and a lot of other tx symbols.
> > 
> > So presumably I need to build one of those libraries, or is there
> > something simpler I can do?
> > 
> The system does have libncurses, it's in /usr/lib/x86_64-linux-gnu. Is
> it possible that directory isn't on the cc/linker search path?  How do
> I add it?

You need the development package.  The runtime package has a similarly named
library file.

For example (Debian/oldstable)

libtinfo6 has
/usr/lib/x86_64-linux-gnu/libtic.so.6

libncurses-dev hs
/usr/lib/x86_64-linux-gnu/libtinfo.so

The plain ".so" is what development packages link with, e.g., -ltinfo

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

ANN: xterm-377

[Thomas Dickey]

Files:
  https://invisible-island.net/archives/xterm/current/xterm-377.tgz
  https://invisible-island.net/archives/xterm/current/xterm-377.tgz.asc
  https://invisible-island.net/archives/xterm/patches/xterm-377.patch.gz
  https://invisible-island.net/archives/xterm/patches/xterm-377.patch.gz.asc
  https://invisible-island.net/archives/xterm/xterm-377.tgz
  https://invisible-island.net/archives/xterm/xterm-377.tgz.asc

Patch #377 - 2022/11/25

 * add  control  sequences  for  reporting  the  current  state of the
   modified   keys   options   (XTQMODKEYS)   and   allowed/disallowed
   operations   (XTQALLOWED),   (prompted   by  discussion  with  Bram
   Moolenaar).
 * amend  modifyOtherKeys  case  2 to distinguish the escape character
   with  modifiers,  e.g., shift-escape, from a plain escape character
   (suggested by Bram Moolenaar).
 * improve  parsing and error-recovery in the case where a list of X11
   bitmap fonts is given in the -fn and related options.
 * change  default  for  xftTrackMemUsage to false, because libXft has
   does not handle certain fonts.


-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

ANN: xterm-377

[Thomas Dickey]

Files:
  https://invisible-island.net/archives/xterm/current/xterm-377.tgz
  https://invisible-island.net/archives/xterm/current/xterm-377.tgz.asc
  https://invisible-island.net/archives/xterm/patches/xterm-377.patch.gz
  https://invisible-island.net/archives/xterm/patches/xterm-377.patch.gz.asc
  https://invisible-island.net/archives/xterm/xterm-377.tgz
  https://invisible-island.net/archives/xterm/xterm-377.tgz.asc

Patch #377 - 2022/11/25

 * add  control  sequences  for  reporting  the  current  state of the
   modified   keys   options   (XTQMODKEYS)   and   allowed/disallowed
   operations   (XTQALLOWED),   (prompted   by  discussion  with  Bram
   Moolenaar).
 * amend  modifyOtherKeys  case  2 to distinguish the escape character
   with  modifiers,  e.g., shift-escape, from a plain escape character
   (suggested by Bram Moolenaar).
 * improve  parsing and error-recovery in the case where a list of X11
   bitmap fonts is given in the -fn and related options.
 * change  default  for  xftTrackMemUsage to false, because libXft has
   does not handle certain fonts.


-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

ANN: xterm-376

[Thomas Dickey]

Files:
  https://invisible-island.net/archives/xterm/current/xterm-376.tgz
  https://invisible-island.net/archives/xterm/current/xterm-376.tgz.asc
  https://invisible-island.net/archives/xterm/patches/xterm-376.patch.gz
  https://invisible-island.net/archives/xterm/patches/xterm-376.patch.gz.asc
  https://invisible-island.net/archives/xterm/xterm-376.tgz
  https://invisible-island.net/archives/xterm/xterm-376.tgz.asc

Patch #376 - 2022/11/16

 * modify configure script to always check for gcc attributes,
 * update install-sh.
 * fix parsing of result -u in vttests/halves.pl.
 * add a note in ctlseqs.ms about compatibility of TBC.
 * fix a copy/paste error in manual (patch by Grady Martin).
 * add  null-pointer checks in x_strcasecmp and x_strncasecmp, to help
   with error-recovery for a missing font (Debian #1022942).


-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

ANN: xterm-376

[Thomas Dickey]

Files:
  https://invisible-island.net/archives/xterm/current/xterm-376.tgz
  https://invisible-island.net/archives/xterm/current/xterm-376.tgz.asc
  https://invisible-island.net/archives/xterm/patches/xterm-376.patch.gz
  https://invisible-island.net/archives/xterm/patches/xterm-376.patch.gz.asc
  https://invisible-island.net/archives/xterm/xterm-376.tgz
  https://invisible-island.net/archives/xterm/xterm-376.tgz.asc

Patch #376 - 2022/11/16

 * modify configure script to always check for gcc attributes,
 * update install-sh.
 * fix parsing of result -u in vttests/halves.pl.
 * add a note in ctlseqs.ms about compatibility of TBC.
 * fix a copy/paste error in manual (patch by Grady Martin).
 * add  null-pointer checks in x_strcasecmp and x_strncasecmp, to help
   with error-recovery for a missing font (Debian #1022942).


-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#1022942: xterm: cannot load font "-*-terminus-*-*-*-32-*-*-*-*-*-*-*"

[Thomas Dickey]

On Wed, Nov 16, 2022 at 04:02:18AM -0500, Thomas Dickey wrote:
> On Wed, Nov 16, 2022 at 09:50:36AM +0100, Andreas Tille wrote:
> > Control: severity -1 minor
...
> > After restarting X xterm is starting properly now.  It somehow seems
> > that the mkfontdir call changed the game.  Unfortunately we do not
> > really know what might have caused the issue.  As I said I would also
> > have loved if xterm would not have crashed.
> 
> agreed (I did try reproducing the crash for the case where the font
> was missing, but so far unsuccessful).

never mind - I see the problem now (was thinking that it occurred when
the font _was_ installed).  Will upload #376 in the early morning.

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#1022942: xterm: cannot load font "-*-terminus-*-*-*-32-*-*-*-*-*-*-*"

[Thomas Dickey]

On Wed, Nov 16, 2022 at 04:02:18AM -0500, Thomas Dickey wrote:
> On Wed, Nov 16, 2022 at 09:50:36AM +0100, Andreas Tille wrote:
> > Control: severity -1 minor
...
> > After restarting X xterm is starting properly now.  It somehow seems
> > that the mkfontdir call changed the game.  Unfortunately we do not
> > really know what might have caused the issue.  As I said I would also
> > have loved if xterm would not have crashed.
> 
> agreed (I did try reproducing the crash for the case where the font
> was missing, but so far unsuccessful).

never mind - I see the problem now (was thinking that it occurred when
the font _was_ installed).  Will upload #376 in the early morning.

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Re: [ANNOUNCE] libXft 2.3.7

[Thomas Dickey]

On Tue, Nov 15, 2022 at 03:27:38PM -0500, Thomas E. Dickey wrote:
> Thomas E. Dickey (4):
>   libxft issue #15
>   fix compiler warning
>   libxft issue #16

I hadn't thought of this while committing the changes,
but had used short titles because a CI rule limited lines to 80 columns.
(I saw some note about that being undone for some projects(*), uncertain...).

For the record, the full titles here would be longer than 80:

libxft issue #16

https://gitlab.freedesktop.org/xorg/lib/libxft/-/issues/16

Stack gets smashed in fonts with colors when calling XftGlyphRender

BGRA changes made incorrect comparison for local vs allocated
buffer in XftGlyphSpecRender

and

libxft issue #15

https://gitlab.freedesktop.org/xorg/lib/libxft/-/issues/15

XftFontLoadGlyphs for mono font returns wrong info in extents from
XftTextExtentsUtf8 for variable chars

Patch by Scott Mcdermott, based on

https://github.com/googlefonts/Inconsolata/issues/42

(*) when I encounted this limit, it was necessary to rebase a lot of
history to successfully merge a pull-request.

>   libXft 2.3.7
> 
> ericLemanissier (1):
>   stdint.h header is needed for SIZE_MAX

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#1022942: xterm: cannot load font "-*-terminus-*-*-*-32-*-*-*-*-*-*-*"

[Thomas Dickey]

On Wed, Nov 16, 2022 at 09:50:36AM +0100, Andreas Tille wrote:
> Control: severity -1 minor
> 
> Hi Thomas,
> 
> at first thanks a lot for your patience.
> 
> Am Tue, Nov 15, 2022 at 08:10:18PM -0500 schrieb Thomas Dickey:
> > On Tue, Nov 15, 2022 at 09:15:43AM +0100, Andreas Tille wrote:
> > > Hi again,
> > > 
> > > I need to admit that the issue "vanished" on my workhorse laptop which is
> > > nice on one hand but having an explanation would be even nicer. ;-)
> > > I've now tried the other laptop with the same problem:
> > > 
> > > $ dpkg --get-selections | grep terminus
> > > fonts-terminusinstall
> > > $ xlsfonts | grep terminus
> > 
> > That might be one of these possibilities:
> > 
> > a) the X configuration (seen with "xset -q") has something amiss with
> >the fontpath (see attached example from my Debian/testing).
> 
> There was no attachment but here is mine:

sorry - will do that, for the record
 
> $ xset -q
> Keyboard Control:
>   auto repeat:  onkey click percent:  0LED mask:  
>   XKB indicators:
> 00: Caps Lock:   off01: Num Lock:off02: Scroll Lock: off
> 03: Compose: off04: Kana:off05: Sleep:   off
> 06: Suspend: off07: Mute:off08: Misc:off
> 09: Mail:off10: Charging:off11: Shift Lock:  off
> 12: Group 2: off13: Mouse Keys:  off
>   auto repeat delay:  400repeat rate:  20
>   auto repeating keys:  00ffdbbf
> fedfffefffed
> 9fff
> fff7
>   bell percent:  50bell pitch:  400bell duration:  100
> Pointer Control:
>   acceleration:  2/1threshold:  4
> Screen Saver:
>   prefer blanking:  yesallow exposures:  yes
>   timeout:  180cycle:  600
> Colors:
>   default colormap:  0x20BlackPixel:  0x0WhitePixel:  0xff
> Font Path:
>   
> /usr/share/fonts/X11/misc,/usr/share/fonts/X11/100dpi/:unscaled,/usr/share/fonts/X11/75dpi/:unscaled,/usr/share/fonts/X11/Type1,/usr/share/fonts/X11/100dpi,/usr/share/fonts/X11/75dpi,built-ins
> DPMS (Energy Star):
>   Standby: 0Suspend: 300Off: 600
>   DPMS is Enabled
>   Monitor is On
> 
>  
> > b) updates to the bitmap font-directories have to be finished using
> >mkfontdir (part of xfonts-utils).  I've seen occasional comments
> >where package updates didn't work as intended.
> > 
> > Either way, "dpkg -L xfonts-terminus" tells me that the relevant files
> > are in
> > 
> > /usr/share/fonts/X11/misc
> > 
> > If xset reports that's in the font path, I'd try (based on the manpage)
> > 
> > sudo mkfontdir /usr/share/fonts/X11/misc
> 
> Done.
>  
> > or (by habit, since long ago it ignored the parameter...)
> > 
> > cd /usr/share/fonts/X11/misc
> > sudo mkfontdir
> > 
> > and restart X.
> 
> After restarting X xterm is starting properly now.  It somehow seems
> that the mkfontdir call changed the game.  Unfortunately we do not
> really know what might have caused the issue.  As I said I would also
> have loved if xterm would not have crashed.

agreed (I did try reproducing the crash for the case where the font
was missing, but so far unsuccessful).
 
> In any case I consider the severity of the bug as lower now and have
> set it to minor.  I'll leave it to your decision whether you consider
> it closed or some helpful resource to find a way to avoid the issue.
> 
> Kind regards and thanks again for your help
>Andreas.
> 
> -- 
> http://fam-tille.de
> 

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net
Keyboard Control:
  auto repeat:  onkey click percent:  0LED mask:  0002
  XKB indicators:
00: Caps Lock:   off01: Num Lock:on 02: Scroll Lock: off
03: Compose: off04: Kana:off05: Sleep:   off
06: Suspend: off07: Mute:off08: Misc:off
09: Mail:off10: Charging:off11: Shift Lock:  off
12: Group 2: off13: Mouse Keys:  off
  auto repeat delay:  500repeat rate:  20
  auto repeating keys:  00ffdbbf
fadfffefffed
9fff
fff7
  bell percent:  50bell pitch:  400bell duration:  100
Pointer Control:
  acceleration:  2/1threshold:  4
Screen Saver:
  prefer blanking:  yesallow exposures:  yes
  timeout:  600cycle:  600
Colors:
  default colormap:  0x20BlackPixel:  0x0WhitePixel:  0xff
Font Path:
  
/usr/share/fonts/X11/misc,/usr/share/fonts/X11/100dpi/:unscaled,/usr/share/fonts/X11/75dpi/:unscaled,/usr/share/fonts/X11/Type1,/usr/share/fonts/X11/100dpi,/usr/share/fonts/X11/75dpi,built-ins
DPMS (Energy Star):
  Standby: 600Suspend: 0Off: 900
  DPMS is Enabled
  Monitor is On


signature.asc
Description: PGP signature

Bug#1022942: xterm: cannot load font "-*-terminus-*-*-*-32-*-*-*-*-*-*-*"

[Thomas Dickey]

On Wed, Nov 16, 2022 at 09:50:36AM +0100, Andreas Tille wrote:
> Control: severity -1 minor
> 
> Hi Thomas,
> 
> at first thanks a lot for your patience.
> 
> Am Tue, Nov 15, 2022 at 08:10:18PM -0500 schrieb Thomas Dickey:
> > On Tue, Nov 15, 2022 at 09:15:43AM +0100, Andreas Tille wrote:
> > > Hi again,
> > > 
> > > I need to admit that the issue "vanished" on my workhorse laptop which is
> > > nice on one hand but having an explanation would be even nicer. ;-)
> > > I've now tried the other laptop with the same problem:
> > > 
> > > $ dpkg --get-selections | grep terminus
> > > fonts-terminusinstall
> > > $ xlsfonts | grep terminus
> > 
> > That might be one of these possibilities:
> > 
> > a) the X configuration (seen with "xset -q") has something amiss with
> >the fontpath (see attached example from my Debian/testing).
> 
> There was no attachment but here is mine:

sorry - will do that, for the record
 
> $ xset -q
> Keyboard Control:
>   auto repeat:  onkey click percent:  0LED mask:  
>   XKB indicators:
> 00: Caps Lock:   off01: Num Lock:off02: Scroll Lock: off
> 03: Compose: off04: Kana:off05: Sleep:   off
> 06: Suspend: off07: Mute:off08: Misc:off
> 09: Mail:off10: Charging:off11: Shift Lock:  off
> 12: Group 2: off13: Mouse Keys:  off
>   auto repeat delay:  400repeat rate:  20
>   auto repeating keys:  00ffdbbf
> fedfffefffed
> 9fff
> fff7
>   bell percent:  50bell pitch:  400bell duration:  100
> Pointer Control:
>   acceleration:  2/1threshold:  4
> Screen Saver:
>   prefer blanking:  yesallow exposures:  yes
>   timeout:  180cycle:  600
> Colors:
>   default colormap:  0x20BlackPixel:  0x0WhitePixel:  0xff
> Font Path:
>   
> /usr/share/fonts/X11/misc,/usr/share/fonts/X11/100dpi/:unscaled,/usr/share/fonts/X11/75dpi/:unscaled,/usr/share/fonts/X11/Type1,/usr/share/fonts/X11/100dpi,/usr/share/fonts/X11/75dpi,built-ins
> DPMS (Energy Star):
>   Standby: 0Suspend: 300Off: 600
>   DPMS is Enabled
>   Monitor is On
> 
>  
> > b) updates to the bitmap font-directories have to be finished using
> >mkfontdir (part of xfonts-utils).  I've seen occasional comments
> >where package updates didn't work as intended.
> > 
> > Either way, "dpkg -L xfonts-terminus" tells me that the relevant files
> > are in
> > 
> > /usr/share/fonts/X11/misc
> > 
> > If xset reports that's in the font path, I'd try (based on the manpage)
> > 
> > sudo mkfontdir /usr/share/fonts/X11/misc
> 
> Done.
>  
> > or (by habit, since long ago it ignored the parameter...)
> > 
> > cd /usr/share/fonts/X11/misc
> > sudo mkfontdir
> > 
> > and restart X.
> 
> After restarting X xterm is starting properly now.  It somehow seems
> that the mkfontdir call changed the game.  Unfortunately we do not
> really know what might have caused the issue.  As I said I would also
> have loved if xterm would not have crashed.

agreed (I did try reproducing the crash for the case where the font
was missing, but so far unsuccessful).
 
> In any case I consider the severity of the bug as lower now and have
> set it to minor.  I'll leave it to your decision whether you consider
> it closed or some helpful resource to find a way to avoid the issue.
> 
> Kind regards and thanks again for your help
>Andreas.
> 
> -- 
> http://fam-tille.de
> 

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net
Keyboard Control:
  auto repeat:  onkey click percent:  0LED mask:  0002
  XKB indicators:
00: Caps Lock:   off01: Num Lock:on 02: Scroll Lock: off
03: Compose: off04: Kana:off05: Sleep:   off
06: Suspend: off07: Mute:off08: Misc:off
09: Mail:off10: Charging:off11: Shift Lock:  off
12: Group 2: off13: Mouse Keys:  off
  auto repeat delay:  500repeat rate:  20
  auto repeating keys:  00ffdbbf
fadfffefffed
9fff
fff7
  bell percent:  50bell pitch:  400bell duration:  100
Pointer Control:
  acceleration:  2/1threshold:  4
Screen Saver:
  prefer blanking:  yesallow exposures:  yes
  timeout:  600cycle:  600
Colors:
  default colormap:  0x20BlackPixel:  0x0WhitePixel:  0xff
Font Path:
  
/usr/share/fonts/X11/misc,/usr/share/fonts/X11/100dpi/:unscaled,/usr/share/fonts/X11/75dpi/:unscaled,/usr/share/fonts/X11/Type1,/usr/share/fonts/X11/100dpi,/usr/share/fonts/X11/75dpi,built-ins
DPMS (Energy Star):
  Standby: 600Suspend: 0Off: 900
  DPMS is Enabled
  Monitor is On


signature.asc
Description: PGP signature

Bug#1022942: xterm: cannot load font "-*-terminus-*-*-*-32-*-*-*-*-*-*-*"

[Thomas Dickey]

On Tue, Nov 15, 2022 at 09:15:43AM +0100, Andreas Tille wrote:
> Hi again,
> 
> I need to admit that the issue "vanished" on my workhorse laptop which is
> nice on one hand but having an explanation would be even nicer. ;-)
> I've now tried the other laptop with the same problem:
> 
> $ dpkg --get-selections | grep terminus
> fonts-terminusinstall
> $ xlsfonts | grep terminus

That might be one of these possibilities:

a) the X configuration (seen with "xset -q") has something amiss with
   the fontpath (see attached example from my Debian/testing).

b) updates to the bitmap font-directories have to be finished using
   mkfontdir (part of xfonts-utils).  I've seen occasional comments
   where package updates didn't work as intended.

Either way, "dpkg -L xfonts-terminus" tells me that the relevant files
are in

/usr/share/fonts/X11/misc

If xset reports that's in the font path, I'd try (based on the manpage)

sudo mkfontdir /usr/share/fonts/X11/misc

or (by habit, since long ago it ignored the parameter...)

cd /usr/share/fonts/X11/misc
sudo mkfontdir

and restart X.

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#1022942: xterm: cannot load font "-*-terminus-*-*-*-32-*-*-*-*-*-*-*"

[Thomas Dickey]

On Tue, Nov 15, 2022 at 09:15:43AM +0100, Andreas Tille wrote:
> Hi again,
> 
> I need to admit that the issue "vanished" on my workhorse laptop which is
> nice on one hand but having an explanation would be even nicer. ;-)
> I've now tried the other laptop with the same problem:
> 
> $ dpkg --get-selections | grep terminus
> fonts-terminusinstall
> $ xlsfonts | grep terminus

That might be one of these possibilities:

a) the X configuration (seen with "xset -q") has something amiss with
   the fontpath (see attached example from my Debian/testing).

b) updates to the bitmap font-directories have to be finished using
   mkfontdir (part of xfonts-utils).  I've seen occasional comments
   where package updates didn't work as intended.

Either way, "dpkg -L xfonts-terminus" tells me that the relevant files
are in

/usr/share/fonts/X11/misc

If xset reports that's in the font path, I'd try (based on the manpage)

sudo mkfontdir /usr/share/fonts/X11/misc

or (by habit, since long ago it ignored the parameter...)

cd /usr/share/fonts/X11/misc
sudo mkfontdir

and restart X.

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#1022942: xterm: cannot load font "-*-terminus-*-*-*-32-*-*-*-*-*-*-*"

[Thomas Dickey]

On Mon, Nov 14, 2022 at 06:21:50PM +0100, Andreas Tille wrote:
> Am Mon, Nov 14, 2022 at 04:27:30AM -0500 schrieb Thomas Dickey:
> > > Since xterm is crashing before this does not report anything
> > > interesting.
> > 
> > hmm - it's not showing much.
> > 
> > What does xfd do with that pattern?  (using single quotes):
> > 
> > xfd -fn '-*-terminus-*-*-*-32-*-*-*-*-*-*-*'
> > 
> > If you don't have that installed, it's part of x11-utils: /usr/bin/xfd
> > 
> > (reinstalling the font might be helpful)
> 
> OK
> 
> ~$ sudo apt install fonts-terminus
> Paketlisten werden gelesen… Fertig
> Abhängigkeitsbaum wird aufgebaut… Fertig
> Statusinformationen werden eingelesen… Fertig
> Die folgenden NEUEN Pakete werden installiert:
>   fonts-terminus
> 0 aktualisiert, 1 neu installiert, 0 zu entfernen und 2 nicht aktualisiert.
> Es müssen 81,0 kB an Archiven heruntergeladen werden.
> Nach dieser Operation werden 464 kB Plattenplatz zusätzlich benutzt.
> Holen:1 http://deb.debian.org/debian testing/main amd64 fonts-terminus amd64 
> 1.2.0+ds-7 [81,0 kB]
> Es wurden 81,0 kB in 0 s geholt (596 kB/s).
> Vormals nicht ausgewähltes Paket fonts-terminus wird gewählt.
> (Lese Datenbank ... 417804 Dateien und Verzeichnisse sind derzeit 
> installiert.)
> Vorbereitung zum Entpacken von .../fonts-terminus_1.2.0+ds-7_amd64.deb ...
> Entpacken von fonts-terminus (1.2.0+ds-7) ...
> fonts-terminus (1.2.0+ds-7) wird eingerichtet ...
> Trigger für fontconfig (2.13.1-4.5) werden verarbeitet ...
> ~$ xfd -fn '-*-terminus-*-*-*-32-*-*-*-*-*-*-*'
> Warning: Cannot convert string "-*-terminus-*-*-*-32-*-*-*-*-*-*-*" to type 
> FontStruct
> xfd:  no font to display

That's (sort of) promising - it tells me that it's not a bug in _xterm_.

xterm and xfd use the same font-related libraries.

It could still be a configuration problem -- I seem to recall seeing
cases where mkfontdir wasn't run on font updates.  xlsfonts should
show the terminus fonts in its (usually long) output.

For instance, on my Debian/oldstable, I get 494 lines from

xlsfonts | grep terminus

(including an alias "terminus-32").  xlsfonts doesn't use any of those
font-related libraries, talks directly to the X server.

The Xlib calls that xterm uses for bitmap fonts (e.g., Terminus) should use the
same information.

If you were using a TrueType font, xterm and xfd would use the Xft and
fontconfig libraries (the "font-related" libraries that I mentioned).  xterm
and xfd if using "-fa" (rather than "-fn") will ask fontconfig for the font,
and it does know enough to do that, e.g.,

xfd -fa terminus-32
xterm -fa terminus-32

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#1022942: xterm: cannot load font "-*-terminus-*-*-*-32-*-*-*-*-*-*-*"

[Thomas Dickey]

On Mon, Nov 14, 2022 at 06:21:50PM +0100, Andreas Tille wrote:
> Am Mon, Nov 14, 2022 at 04:27:30AM -0500 schrieb Thomas Dickey:
> > > Since xterm is crashing before this does not report anything
> > > interesting.
> > 
> > hmm - it's not showing much.
> > 
> > What does xfd do with that pattern?  (using single quotes):
> > 
> > xfd -fn '-*-terminus-*-*-*-32-*-*-*-*-*-*-*'
> > 
> > If you don't have that installed, it's part of x11-utils: /usr/bin/xfd
> > 
> > (reinstalling the font might be helpful)
> 
> OK
> 
> ~$ sudo apt install fonts-terminus
> Paketlisten werden gelesen… Fertig
> Abhängigkeitsbaum wird aufgebaut… Fertig
> Statusinformationen werden eingelesen… Fertig
> Die folgenden NEUEN Pakete werden installiert:
>   fonts-terminus
> 0 aktualisiert, 1 neu installiert, 0 zu entfernen und 2 nicht aktualisiert.
> Es müssen 81,0 kB an Archiven heruntergeladen werden.
> Nach dieser Operation werden 464 kB Plattenplatz zusätzlich benutzt.
> Holen:1 http://deb.debian.org/debian testing/main amd64 fonts-terminus amd64 
> 1.2.0+ds-7 [81,0 kB]
> Es wurden 81,0 kB in 0 s geholt (596 kB/s).
> Vormals nicht ausgewähltes Paket fonts-terminus wird gewählt.
> (Lese Datenbank ... 417804 Dateien und Verzeichnisse sind derzeit 
> installiert.)
> Vorbereitung zum Entpacken von .../fonts-terminus_1.2.0+ds-7_amd64.deb ...
> Entpacken von fonts-terminus (1.2.0+ds-7) ...
> fonts-terminus (1.2.0+ds-7) wird eingerichtet ...
> Trigger für fontconfig (2.13.1-4.5) werden verarbeitet ...
> ~$ xfd -fn '-*-terminus-*-*-*-32-*-*-*-*-*-*-*'
> Warning: Cannot convert string "-*-terminus-*-*-*-32-*-*-*-*-*-*-*" to type 
> FontStruct
> xfd:  no font to display

That's (sort of) promising - it tells me that it's not a bug in _xterm_.

xterm and xfd use the same font-related libraries.

It could still be a configuration problem -- I seem to recall seeing
cases where mkfontdir wasn't run on font updates.  xlsfonts should
show the terminus fonts in its (usually long) output.

For instance, on my Debian/oldstable, I get 494 lines from

xlsfonts | grep terminus

(including an alias "terminus-32").  xlsfonts doesn't use any of those
font-related libraries, talks directly to the X server.

The Xlib calls that xterm uses for bitmap fonts (e.g., Terminus) should use the
same information.

If you were using a TrueType font, xterm and xfd would use the Xft and
fontconfig libraries (the "font-related" libraries that I mentioned).  xterm
and xfd if using "-fa" (rather than "-fn") will ask fontconfig for the font,
and it does know enough to do that, e.g.,

xfd -fa terminus-32
xterm -fa terminus-32

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#1022942: xterm: cannot load font "-*-terminus-*-*-*-32-*-*-*-*-*-*-*"

[Thomas Dickey]

On Mon, Nov 14, 2022 at 09:02:22AM +0100, Andreas Tille wrote:
> Am Sun, Nov 13, 2022 at 08:33:09PM -0500 schrieb Thomas Dickey:
> > > LANGUAGE=
> > > LC_CTYPE="de_DE.UTF-8"
> > > LC_NUMERIC="de_DE.UTF-8"
> > > LC_TIME="de_DE.UTF-8"
> > > LC_COLLATE="de_DE.UTF-8"
> > > LC_MONETARY="de_DE.UTF-8"
> > > LC_MESSAGES="de_DE.UTF-8"
> > > LC_PAPER="de_DE.UTF-8"
> > > LC_NAME="de_DE.UTF-8"
> > > LC_ADDRESS="de_DE.UTF-8"
> > > LC_TELEPHONE="de_DE.UTF-8"
> > > LC_MEASUREMENT="de_DE.UTF-8"
> > > LC_IDENTIFICATION="de_DE.UTF-8"
> > > LC_ALL=
> > 
> > I tried that - no change
> 
> I admit I do not think the locale setting is responsible for the issue.
>   
> > > I've made the Geometry that size to fit exactly a quarter of my screen
> > > fitting 4 xterms at one time.  Xfce4 places these intelligently in a
> > > 2x2 matrix.
> > 
> > Something like this will work, but fixing the problem with the menus:
> > 
> > XTerm*VT100.geometry: 111x36
> > 
> > It's in the FAQ:
> > 
> > https://invisible-island.net/xterm/xterm.faq.html#tiny_menus
> 
> Thanks for the hint but I think this was not my main problem. ;-)
>  
> > > I'm using Debian packages exclusively - I have no time to spent
> > > extra fancy things.  BTW. I'm observing the very same bug on my
> > > second laptop I'm using for traveling (but my desktop with the
> > > same setup works without any problem)
> > >  
> > > Could you send me the full command line
> > >"xrdb -load ??"
> > 
> > I pasted the text from earlier mail as "bad.ad" (attached),
> > and loaded it with
> > 
> > xrdb -load bad.ad
> 
> I tried this but it did not changed the problem.
>  
> > > I could check here.  What strace call should I send to track
> > > down the issue.  Please note that while I'm an experienced
> > 
> > I'd just
> > 
> > strace -o trace.log -s 1024 xterm
> > 
> > to capture a long trace (~200kb),
> > and look to see if there's something interesting where xterm dies.
> 
> I've attached my gziped trace.log.
>  
> > I also ran xterm using -report-fonts, which shows the fonts opened.
> 
> Since xterm is crashing before this does not report anything
> interesting.

hmm - it's not showing much.

What does xfd do with that pattern?  (using single quotes):

xfd -fn '-*-terminus-*-*-*-32-*-*-*-*-*-*-*'

If you don't have that installed, it's part of x11-utils: /usr/bin/xfd

(reinstalling the font might be helpful)

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#1022942: xterm: cannot load font "-*-terminus-*-*-*-32-*-*-*-*-*-*-*"

[Thomas Dickey]

On Mon, Nov 14, 2022 at 09:02:22AM +0100, Andreas Tille wrote:
> Am Sun, Nov 13, 2022 at 08:33:09PM -0500 schrieb Thomas Dickey:
> > > LANGUAGE=
> > > LC_CTYPE="de_DE.UTF-8"
> > > LC_NUMERIC="de_DE.UTF-8"
> > > LC_TIME="de_DE.UTF-8"
> > > LC_COLLATE="de_DE.UTF-8"
> > > LC_MONETARY="de_DE.UTF-8"
> > > LC_MESSAGES="de_DE.UTF-8"
> > > LC_PAPER="de_DE.UTF-8"
> > > LC_NAME="de_DE.UTF-8"
> > > LC_ADDRESS="de_DE.UTF-8"
> > > LC_TELEPHONE="de_DE.UTF-8"
> > > LC_MEASUREMENT="de_DE.UTF-8"
> > > LC_IDENTIFICATION="de_DE.UTF-8"
> > > LC_ALL=
> > 
> > I tried that - no change
> 
> I admit I do not think the locale setting is responsible for the issue.
>   
> > > I've made the Geometry that size to fit exactly a quarter of my screen
> > > fitting 4 xterms at one time.  Xfce4 places these intelligently in a
> > > 2x2 matrix.
> > 
> > Something like this will work, but fixing the problem with the menus:
> > 
> > XTerm*VT100.geometry: 111x36
> > 
> > It's in the FAQ:
> > 
> > https://invisible-island.net/xterm/xterm.faq.html#tiny_menus
> 
> Thanks for the hint but I think this was not my main problem. ;-)
>  
> > > I'm using Debian packages exclusively - I have no time to spent
> > > extra fancy things.  BTW. I'm observing the very same bug on my
> > > second laptop I'm using for traveling (but my desktop with the
> > > same setup works without any problem)
> > >  
> > > Could you send me the full command line
> > >"xrdb -load ??"
> > 
> > I pasted the text from earlier mail as "bad.ad" (attached),
> > and loaded it with
> > 
> > xrdb -load bad.ad
> 
> I tried this but it did not changed the problem.
>  
> > > I could check here.  What strace call should I send to track
> > > down the issue.  Please note that while I'm an experienced
> > 
> > I'd just
> > 
> > strace -o trace.log -s 1024 xterm
> > 
> > to capture a long trace (~200kb),
> > and look to see if there's something interesting where xterm dies.
> 
> I've attached my gziped trace.log.
>  
> > I also ran xterm using -report-fonts, which shows the fonts opened.
> 
> Since xterm is crashing before this does not report anything
> interesting.

hmm - it's not showing much.

What does xfd do with that pattern?  (using single quotes):

xfd -fn '-*-terminus-*-*-*-32-*-*-*-*-*-*-*'

If you don't have that installed, it's part of x11-utils: /usr/bin/xfd

(reinstalling the font might be helpful)

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#1022942: xterm: cannot load font "-*-terminus-*-*-*-32-*-*-*-*-*-*-*"

[Thomas Dickey]

On Sat, Nov 12, 2022 at 03:17:01PM +0100, Andreas Tille wrote:
> Am Sun, Nov 06, 2022 at 07:55:33PM -0500 schrieb Thomas Dickey:
> > On Tue, Nov 01, 2022 at 09:23:55AM +0100, Andreas Tille wrote:
> > > Am Sun, Oct 30, 2022 at 04:53:24PM -0400 schrieb Thomas Dickey:
> > > > > > $ grep font /etc/X11/Xresources/xterm  | grep -v ^!
> > > > > > *VT100.utf8Fonts.font: fixed
> > 
> > what locale settings are you using?
> > 
> > (that might be relevant - or the choice of desktop/window-manager)
> 
> $ locale
> LANG=de_DE.UTF-8
> LANGUAGE=
> LC_CTYPE="de_DE.UTF-8"
> LC_NUMERIC="de_DE.UTF-8"
> LC_TIME="de_DE.UTF-8"
> LC_COLLATE="de_DE.UTF-8"
> LC_MONETARY="de_DE.UTF-8"
> LC_MESSAGES="de_DE.UTF-8"
> LC_PAPER="de_DE.UTF-8"
> LC_NAME="de_DE.UTF-8"
> LC_ADDRESS="de_DE.UTF-8"
> LC_TELEPHONE="de_DE.UTF-8"
> LC_MEASUREMENT="de_DE.UTF-8"
> LC_IDENTIFICATION="de_DE.UTF-8"
> LC_ALL=

I tried that - no change
 
> Desktop environment is xfce4.
>  
> > > Sorry its "comment".
> > > 
> > > > > (the grep seems to indicate that the latter is meant)
> > > > > 
> > > > > > crash with segmentation fault when not finding some specified font.
> > 
> > I suppose the problem is something along the lines of the X server
> > returning some error in using the fonts.  If it were TrueType fonts,
> > I'd use strace to verify that they're opened -- but for bitmap
> > fonts, that's done on the server side.
> 
> I admit I'm fine with any nicely readable font.  I once considered the
> terminus fonts to fit this requirement and never found any reason
> to change this.
>  
> > > The crash happens for
> > > 
> > > $ xrdb -query
> > > *VT100.utf8Fonts.font:  fixed
> > > XTermVT100.faceSize:22
> > > XTerm*geometry: 111x36
> > 
> > hmm - I'm still not seeing _this_ problem.
> > (by the way, the geometry resource is over-broad, making the font-menu
> > less than useful).
> 
> I've made the Geometry that size to fit exactly a quarter of my screen
> fitting 4 xterms at one time.  Xfce4 places these intelligently in a
> 2x2 matrix.

Something like this will work, but fixing the problem with the menus:

XTerm*VT100.geometry: 111x36

It's in the FAQ:

https://invisible-island.net/xterm/xterm.faq.html#tiny_menus

> > I used xcfe4 for testing, on a virtual machine.
> > 
> > My most recent snapshot (from 2022/11/01) didn't work - some problem
> > with X and the window manaager), so I upgraded from 2022/10/29,
> > to get a workable machine.
> > 
> > Given that (I also have the terminus font installed),
> > I used "xrdb -load" with these resources, and ran xterm
> > from the Debian package.  It looks okay to me - no crash.
> 
> I'm using Debian packages exclusively - I have no time to spent
> extra fancy things.  BTW. I'm observing the very same bug on my
> second laptop I'm using for traveling (but my desktop with the
> same setup works without any problem)
>  
> Could you send me the full command line
>"xrdb -load ??"

I pasted the text from earlier mail as "bad.ad" (attached),
and loaded it with

xrdb -load bad.ad

> I could check here.  What strace call should I send to track
> down the issue.  Please note that while I'm an experienced

I'd just

strace -o trace.log -s 1024 xterm

to capture a long trace (~200kb),
and look to see if there's something interesting where xterm dies.

I also ran xterm using -report-fonts, which shows the fonts opened.

> Debian user and long year developer I would not consider myself
> an X expert.
> 
> Kind regards
> 
>Andreas.
> 
> -- 
> http://fam-tille.de

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net
Loaded VTFonts(font6)
fNorm: -*-terminus-*-*-*-32-*-*-*-*-*-*-*
all chars: no
default char:  63
direction: 0
ascent:26
descent:   6
first char:0
last char: 255
maximum-chars: 256
missing-chars: 37
present-chars: 219
min_byte1: 0
max_byte1: 0
properties:22
min_bounds:
lbearing: 0
rbearing: 0
width:16
ascent:   -1
descent:  -22
max_bounds:
  

Bug#1022942: xterm: cannot load font "-*-terminus-*-*-*-32-*-*-*-*-*-*-*"

[Thomas Dickey]

On Sat, Nov 12, 2022 at 03:17:01PM +0100, Andreas Tille wrote:
> Am Sun, Nov 06, 2022 at 07:55:33PM -0500 schrieb Thomas Dickey:
> > On Tue, Nov 01, 2022 at 09:23:55AM +0100, Andreas Tille wrote:
> > > Am Sun, Oct 30, 2022 at 04:53:24PM -0400 schrieb Thomas Dickey:
> > > > > > $ grep font /etc/X11/Xresources/xterm  | grep -v ^!
> > > > > > *VT100.utf8Fonts.font: fixed
> > 
> > what locale settings are you using?
> > 
> > (that might be relevant - or the choice of desktop/window-manager)
> 
> $ locale
> LANG=de_DE.UTF-8
> LANGUAGE=
> LC_CTYPE="de_DE.UTF-8"
> LC_NUMERIC="de_DE.UTF-8"
> LC_TIME="de_DE.UTF-8"
> LC_COLLATE="de_DE.UTF-8"
> LC_MONETARY="de_DE.UTF-8"
> LC_MESSAGES="de_DE.UTF-8"
> LC_PAPER="de_DE.UTF-8"
> LC_NAME="de_DE.UTF-8"
> LC_ADDRESS="de_DE.UTF-8"
> LC_TELEPHONE="de_DE.UTF-8"
> LC_MEASUREMENT="de_DE.UTF-8"
> LC_IDENTIFICATION="de_DE.UTF-8"
> LC_ALL=

I tried that - no change
 
> Desktop environment is xfce4.
>  
> > > Sorry its "comment".
> > > 
> > > > > (the grep seems to indicate that the latter is meant)
> > > > > 
> > > > > > crash with segmentation fault when not finding some specified font.
> > 
> > I suppose the problem is something along the lines of the X server
> > returning some error in using the fonts.  If it were TrueType fonts,
> > I'd use strace to verify that they're opened -- but for bitmap
> > fonts, that's done on the server side.
> 
> I admit I'm fine with any nicely readable font.  I once considered the
> terminus fonts to fit this requirement and never found any reason
> to change this.
>  
> > > The crash happens for
> > > 
> > > $ xrdb -query
> > > *VT100.utf8Fonts.font:  fixed
> > > XTermVT100.faceSize:22
> > > XTerm*geometry: 111x36
> > 
> > hmm - I'm still not seeing _this_ problem.
> > (by the way, the geometry resource is over-broad, making the font-menu
> > less than useful).
> 
> I've made the Geometry that size to fit exactly a quarter of my screen
> fitting 4 xterms at one time.  Xfce4 places these intelligently in a
> 2x2 matrix.

Something like this will work, but fixing the problem with the menus:

XTerm*VT100.geometry: 111x36

It's in the FAQ:

https://invisible-island.net/xterm/xterm.faq.html#tiny_menus

> > I used xcfe4 for testing, on a virtual machine.
> > 
> > My most recent snapshot (from 2022/11/01) didn't work - some problem
> > with X and the window manaager), so I upgraded from 2022/10/29,
> > to get a workable machine.
> > 
> > Given that (I also have the terminus font installed),
> > I used "xrdb -load" with these resources, and ran xterm
> > from the Debian package.  It looks okay to me - no crash.
> 
> I'm using Debian packages exclusively - I have no time to spent
> extra fancy things.  BTW. I'm observing the very same bug on my
> second laptop I'm using for traveling (but my desktop with the
> same setup works without any problem)
>  
> Could you send me the full command line
>"xrdb -load ??"

I pasted the text from earlier mail as "bad.ad" (attached),
and loaded it with

xrdb -load bad.ad

> I could check here.  What strace call should I send to track
> down the issue.  Please note that while I'm an experienced

I'd just

strace -o trace.log -s 1024 xterm

to capture a long trace (~200kb),
and look to see if there's something interesting where xterm dies.

I also ran xterm using -report-fonts, which shows the fonts opened.

> Debian user and long year developer I would not consider myself
> an X expert.
> 
> Kind regards
> 
>Andreas.
> 
> -- 
> http://fam-tille.de

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net
Loaded VTFonts(font6)
fNorm: -*-terminus-*-*-*-32-*-*-*-*-*-*-*
all chars: no
default char:  63
direction: 0
ascent:26
descent:   6
first char:0
last char: 255
maximum-chars: 256
missing-chars: 37
present-chars: 219
min_byte1: 0
max_byte1: 0
properties:22
min_bounds:
lbearing: 0
rbearing: 0
width:16
ascent:   -1
descent:  -22
max_bounds:
  

Re: Always get two windows when using -c

[Thomas Dickey]

On Sun, Nov 13, 2022 at 09:55:18PM +, Chris Green wrote:
> On Sun, Nov 13, 2022 at 03:40:43PM -0500, Thomas Dickey wrote:
> > On Sun, Nov 13, 2022 at 08:11:17PM +, Chris Green wrote:
> > > On Sun, Nov 13, 2022 at 10:55:07AM -0500, Thomas Dickey wrote:
> > > > On Sun, Nov 13, 2022 at 01:57:30PM +, Chris Green wrote:
> > > > > This relates to my recent posting about trying to use the '-c' command
> > > > > line option.  However it's now a more general problem/question.
> > > > > 
> > > > > Whenever I add a '-c command' (or a '+ command', or a '-g NNN') to the
> > > > > command line vile opens two windows, the file I want is in the first
> > > > > window and the following is in the second (lower) window:-
> > > > > 
> > > > > [Reading /home/chris/.vilerc]
> > > > 
> > > > perhaps your .vilerc doesn't set nopopup-msgs (or sets popup-msgs)
> > > > 
> > > My .vilerc is:-
> > > 
> > > 
> > ...
> > > source digraphs.rc
> > > 
> > > But it's happenning before reading .vilerc isn't it?
> > 
> > no - it's happening because of the warning message:
> > 
> >  * If no warning messages were encountered during startup, and the 
> > popup-msgs
> >  * mode wasn't enabled, discard the informational messages that are there
> >  * already.
> > 
> > you could do this
> > 
> > vile -c goto-end-of-file
> > 
> Ah!  Thank you, that does what I need.
> 
> However I'm still a little confused, when you say "it's happening
> because of the warning message", am I getting a warning message?  If
> so, what is it? ... and can I stop it?

The error message was this -

"/home/chris/wiki/data/pages/boating/diary/2011/05/20.txt"] 
[Not that many lines in buffer: 20] 
> 
> Are you saying that "source digraphs.rc" is causing it?

no :-
 
> ... I've had a boozy supper just now on my birthday today so apologies
> for confused/confusing replies. :-)
> 
> -- 
> Chris Green
> 

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Re: Always get two windows when using -c

[Thomas Dickey]

On Sun, Nov 13, 2022 at 08:11:17PM +, Chris Green wrote:
> On Sun, Nov 13, 2022 at 10:55:07AM -0500, Thomas Dickey wrote:
> > On Sun, Nov 13, 2022 at 01:57:30PM +, Chris Green wrote:
> > > This relates to my recent posting about trying to use the '-c' command
> > > line option.  However it's now a more general problem/question.
> > > 
> > > Whenever I add a '-c command' (or a '+ command', or a '-g NNN') to the
> > > command line vile opens two windows, the file I want is in the first
> > > window and the following is in the second (lower) window:-
> > > 
> > > [Reading /home/chris/.vilerc]
> > 
> > perhaps your .vilerc doesn't set nopopup-msgs (or sets popup-msgs)
> > 
> My .vilerc is:-
> 
> 
...
> source digraphs.rc
> 
> But it's happenning before reading .vilerc isn't it?

no - it's happening because of the warning message:

 * If no warning messages were encountered during startup, and the popup-msgs
 * mode wasn't enabled, discard the informational messages that are there
 * already.

you could do this

vile -c goto-end-of-file

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Re: Always get two windows when using -c

[Thomas Dickey]

On Sun, Nov 13, 2022 at 01:57:30PM +, Chris Green wrote:
> This relates to my recent posting about trying to use the '-c' command
> line option.  However it's now a more general problem/question.
> 
> Whenever I add a '-c command' (or a '+ command', or a '-g NNN') to the
> command line vile opens two windows, the file I want is in the first
> window and the following is in the second (lower) window:-
> 
> [Reading /home/chris/.vilerc]

perhaps your .vilerc doesn't set nopopup-msgs (or sets popup-msgs)

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#1022942: xterm: cannot load font "-*-terminus-*-*-*-32-*-*-*-*-*-*-*"

[Thomas Dickey]

On Tue, Nov 01, 2022 at 09:23:55AM +0100, Andreas Tille wrote:
> Am Sun, Oct 30, 2022 at 04:53:24PM -0400 schrieb Thomas Dickey:
> > > > $ grep font /etc/X11/Xresources/xterm  | grep -v ^!
> > > > *VT100.utf8Fonts.font: fixed

what locale settings are you using?

(that might be relevant - or the choice of desktop/window-manager)

> > > > XTerm.VT100.font1: -*-terminus-*-*-*-16-*-*-*-*-*-*-*
> > > > XTerm.VT100.font2: -*-terminus-*-*-*-18-*-*-*-*-*-*-*   
> > > >
> > > > XTerm.VT100.font3: -*-terminus-*-*-*-20-*-*-*-*-*-*-*   
> > > >
> > > > XTerm.VT100.font4: -*-terminus-*-*-*-24-*-*-*-*-*-*-*
> > > > XTerm.VT100.font5: -*-terminus-*-*-*-28-*-*-*-*-*-*-*   
> > > >
> > > > XTerm.VT100.font6: -*-terminus-*-*-*-32-*-*-*-*-*-*-*
> > 
> > for the record, xfonts-terminus includes all of these sizes.
> > 
> > > > here.  If I uncomment these settings xterm starts.  However, I think 
> > > > xterm should not
> > > 
> > > Is that "uncomment", or "comment"?
> 
> Sorry its "comment".
> 
> > > (the grep seems to indicate that the latter is meant)
> > > 
> > > > crash with segmentation fault when not finding some specified font.

I suppose the problem is something along the lines of the X server
returning some error in using the fonts.  If it were TrueType fonts,
I'd use strace to verify that they're opened -- but for bitmap
fonts, that's done on the server side.

> > > 
> > > agreed -
> > 
> > I've not been able to reproduce the problem, which I suspect is in
> > the error-recovery section of xterm's xtermLoadFont function.
> > 
> > Perhaps seeing the whole set of resources would help
> > (the output of "xrdb -query", too).
> 
> I have:
> 
> $ xrdb -query
> *VT100.utf8Fonts.font:  fixed
> XTermVT100.faceSize:22
> XTerm*geometry: 111x36
> xterm*vt100.initialFont:6
> YTerm*geometry: 90x50
> xterm*visualBell:   true
> Rxvt.keysym.Delete: \b
> Rxvt.termName:  xterm
> XTerm*decTerminalID:200
> XTerm*color0:   black
> XTerm*color1:   red
> XTerm*color2:   green
> XTerm*color3:   yellow
> XTerm*color4:   blue
> XTerm*color5:   magenta
> XTerm*color6:   cyan
> XTerm*color7:   white
> XTerm*color8:   black
> XTerm*color9:   red
> XTerm*color10:  green
> XTerm*color11:  yellow
> XTerm*color12:  blue
> XTerm*color13:  magenta
> XTerm*color14:  cyan
> XTerm*color15:  white
> XTerm*termName: xterm
> XTerm*title:XTerm
> XTerm*colorMode:on
> XTerm*background:   blue
> XTerm*foreground:   white
> XTerm*loginShell:   true
> XTerm*dynamicColors:on
> 
> 
> The crash happens for
> 
> $ xrdb -query
> *VT100.utf8Fonts.font:  fixed
> XTermVT100.faceSize:22
> XTerm*geometry: 111x36

hmm - I'm still not seeing _this_ problem.
(by the way, the geometry resource is over-broad, making the font-menu
less than useful).

I used xcfe4 for testing, on a virtual machine.

My most recent snapshot (from 2022/11/01) didn't work - some problem
with X and the window manaager), so I upgraded from 2022/10/29,
to get a workable machine.

Given that (I also have the terminus font installed),
I used "xrdb -load" with these resources, and ran xterm
from the Debian package.  It looks okay to me - no crash.

> XTerm.VT100.font1:  -*-terminus-*-*-*-16-*-*-*-*-*-*-*
> XTerm.VT100.font2:  -*-terminus-*-*-*-18-*-*-*-*-*-*-*
> XTerm.VT100.font3:  -*-terminus-*-*-*-20-*-*-*-*-*-*-*
> XTerm.VT100.font4:  -*-terminus-*-*-*-24-*-*-*-*-*-*-*
> XTerm.VT100.font5:  -*-terminus-*-*-*-28-*-*-*-*-*-*-*
> XTerm.VT100.font6:  -*-terminus-*-*-*-32-*-*-*-*-*-*-*
> xterm*vt100.initialFont:6
> YTerm*geometry: 90x50
> xterm*visualBell:   true
> Rxvt.keysym.Delete: \b
> Rxvt.termName:  xterm
> XTerm*decTerminalID:200
> XTerm*color0:   black
> XTerm*color1:   red
> XTerm*color2:   green
> XTerm*color3:   yellow
> XTerm*color4:   blue
> XTerm*color5:   magenta
> XTerm*color6:   cyan
> XTerm*color7:   white
> XTerm*color8:   black
> XTerm*color9:   red
> XTerm*color10:  green
> XTerm*color11:  yellow
> XTerm*color12:  blue
> XTerm*color13:  magenta
> XTerm*color14:  cyan
> XTerm*color15:  white
> XTerm*termName: xterm
> XTerm*title:XTerm
> XTerm*colorMode:on
> XTerm*background:   blue
> XTerm*foreground:   white
> XTerm*loginShell:   true
> XTerm*dynamicColors:on
> 
> 
> I confirm I have installed xfonts-terminus

Bug#1022942: xterm: cannot load font "-*-terminus-*-*-*-32-*-*-*-*-*-*-*"

[Thomas Dickey]

On Tue, Nov 01, 2022 at 09:23:55AM +0100, Andreas Tille wrote:
> Am Sun, Oct 30, 2022 at 04:53:24PM -0400 schrieb Thomas Dickey:
> > > > $ grep font /etc/X11/Xresources/xterm  | grep -v ^!
> > > > *VT100.utf8Fonts.font: fixed

what locale settings are you using?

(that might be relevant - or the choice of desktop/window-manager)

> > > > XTerm.VT100.font1: -*-terminus-*-*-*-16-*-*-*-*-*-*-*
> > > > XTerm.VT100.font2: -*-terminus-*-*-*-18-*-*-*-*-*-*-*   
> > > >
> > > > XTerm.VT100.font3: -*-terminus-*-*-*-20-*-*-*-*-*-*-*   
> > > >
> > > > XTerm.VT100.font4: -*-terminus-*-*-*-24-*-*-*-*-*-*-*
> > > > XTerm.VT100.font5: -*-terminus-*-*-*-28-*-*-*-*-*-*-*   
> > > >
> > > > XTerm.VT100.font6: -*-terminus-*-*-*-32-*-*-*-*-*-*-*
> > 
> > for the record, xfonts-terminus includes all of these sizes.
> > 
> > > > here.  If I uncomment these settings xterm starts.  However, I think 
> > > > xterm should not
> > > 
> > > Is that "uncomment", or "comment"?
> 
> Sorry its "comment".
> 
> > > (the grep seems to indicate that the latter is meant)
> > > 
> > > > crash with segmentation fault when not finding some specified font.

I suppose the problem is something along the lines of the X server
returning some error in using the fonts.  If it were TrueType fonts,
I'd use strace to verify that they're opened -- but for bitmap
fonts, that's done on the server side.

> > > 
> > > agreed -
> > 
> > I've not been able to reproduce the problem, which I suspect is in
> > the error-recovery section of xterm's xtermLoadFont function.
> > 
> > Perhaps seeing the whole set of resources would help
> > (the output of "xrdb -query", too).
> 
> I have:
> 
> $ xrdb -query
> *VT100.utf8Fonts.font:  fixed
> XTermVT100.faceSize:22
> XTerm*geometry: 111x36
> xterm*vt100.initialFont:6
> YTerm*geometry: 90x50
> xterm*visualBell:   true
> Rxvt.keysym.Delete: \b
> Rxvt.termName:  xterm
> XTerm*decTerminalID:200
> XTerm*color0:   black
> XTerm*color1:   red
> XTerm*color2:   green
> XTerm*color3:   yellow
> XTerm*color4:   blue
> XTerm*color5:   magenta
> XTerm*color6:   cyan
> XTerm*color7:   white
> XTerm*color8:   black
> XTerm*color9:   red
> XTerm*color10:  green
> XTerm*color11:  yellow
> XTerm*color12:  blue
> XTerm*color13:  magenta
> XTerm*color14:  cyan
> XTerm*color15:  white
> XTerm*termName: xterm
> XTerm*title:XTerm
> XTerm*colorMode:on
> XTerm*background:   blue
> XTerm*foreground:   white
> XTerm*loginShell:   true
> XTerm*dynamicColors:on
> 
> 
> The crash happens for
> 
> $ xrdb -query
> *VT100.utf8Fonts.font:  fixed
> XTermVT100.faceSize:22
> XTerm*geometry: 111x36

hmm - I'm still not seeing _this_ problem.
(by the way, the geometry resource is over-broad, making the font-menu
less than useful).

I used xcfe4 for testing, on a virtual machine.

My most recent snapshot (from 2022/11/01) didn't work - some problem
with X and the window manaager), so I upgraded from 2022/10/29,
to get a workable machine.

Given that (I also have the terminus font installed),
I used "xrdb -load" with these resources, and ran xterm
from the Debian package.  It looks okay to me - no crash.

> XTerm.VT100.font1:  -*-terminus-*-*-*-16-*-*-*-*-*-*-*
> XTerm.VT100.font2:  -*-terminus-*-*-*-18-*-*-*-*-*-*-*
> XTerm.VT100.font3:  -*-terminus-*-*-*-20-*-*-*-*-*-*-*
> XTerm.VT100.font4:  -*-terminus-*-*-*-24-*-*-*-*-*-*-*
> XTerm.VT100.font5:  -*-terminus-*-*-*-28-*-*-*-*-*-*-*
> XTerm.VT100.font6:  -*-terminus-*-*-*-32-*-*-*-*-*-*-*
> xterm*vt100.initialFont:6
> YTerm*geometry: 90x50
> xterm*visualBell:   true
> Rxvt.keysym.Delete: \b
> Rxvt.termName:  xterm
> XTerm*decTerminalID:200
> XTerm*color0:   black
> XTerm*color1:   red
> XTerm*color2:   green
> XTerm*color3:   yellow
> XTerm*color4:   blue
> XTerm*color5:   magenta
> XTerm*color6:   cyan
> XTerm*color7:   white
> XTerm*color8:   black
> XTerm*color9:   red
> XTerm*color10:  green
> XTerm*color11:  yellow
> XTerm*color12:  blue
> XTerm*color13:  magenta
> XTerm*color14:  cyan
> XTerm*color15:  white
> XTerm*termName: xterm
> XTerm*title:XTerm
> XTerm*colorMode:on
> XTerm*background:   blue
> XTerm*foreground:   white
> XTerm*loginShell:   true
> XTerm*dynamicColors:on
> 
> 
> I confirm I have installed xfonts-terminus

Re: [Lynx-dev] colo(u)red figcaptions

[Thomas Dickey]

On Tue, Nov 01, 2022 at 05:22:40AM -0600, rb...@alumni.caltech.edu wrote:
>   'I'd check the diff by using dtd_util to regenerate the header
> files.'
>   dtd_util?

WWW/Library/Implementation/dtd_util.c

(read the makefile, to see how it is used).

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Re: [Lynx-dev] How stable is 2.9.0?

[Thomas Dickey]

On Tue, Nov 01, 2022 at 07:21:17PM -0400, Travis Siegel wrote:
> For what it's worth, I've been using 2.9.0 since version dev 5, and I've not
> encountered any major bugs with it.  I'm fairly confident it will be plenty
> stable enough for your use.
> 
> It's possible you'll find something else thatwon't do the trick for you, but
> it's plenty stable enough for everyday use.
> 
> 
> On 11/1/2022 11:00 AM, Mouse wrote:
> > The lynx I've been using - 2.8, from 1999 - started exhibiting a
> > disturbing failure mode, today: I got "lynx in free(): warning: chunk
> > is already free.", indicating a memory-management bug, and, in at least
> > one session, got a coredump (ditto, but even more so).
> > 
> > I could just treat this as a debugging exercise.  But I wanted to at
> > least look at version-jumping instead.  It appears to me that the
> > latest release is 2.8.9, with 2.9.0 being still in development
> > versions.  But a lot of development versions, especially for
> > open-source software, are plenty usable enough.  And I notice that
> > 2.9.0dev looks relatively stable; the last-change time I see is
> > 2021-08-07.  So, my question is, is 2.9.0 in good enough shape that I

2.9.0dev.10 is the latest development release:

https://lynx.invisible-island.net/current/CHANGES.html#v2.9.0dev.10

There's a dozen commits past that

https://github.com/ThomasDickey/lynx-snapshots

but I'm busy with a different upgrade.

The main difference between those is the number of platforms on which I've
built/tested (snapshots, 2-3, development 5-10, release 25-30).

ymmv

> > should (FWVO "should") use it, or would 2.8.9 be better?  (Of course,
> > it's possible that either one has some property that will render it
> > unsuitable for my purposes, but I figured I should at least look into
> > it.)
> > 
> > /~\ The ASCII Mouse
> > \ / Ribbon Campaign
> >   X  Against HTML   mo...@rodents-montreal.org
> > / \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
> > 
> 

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Re: [Lynx-dev] colo(u)red figcaptions

[Thomas Dickey]

On Tue, Oct 25, 2022 at 10:37:28PM -0600, rb...@alumni.caltech.edu wrote:
>   I needed -p0.  Here's the patch - do you want me to do
> something else?

actually, as an attachment would make it easier to extract.

given that, I'd check the diff by using dtd_util to regenerate the
header files.
 
> Index: WWW/Library/Implementation/hdr_HTMLDTD.h
> *** lynx2.9.0dev.10/WWW/Library/Implementation/hdr_HTMLDTD.h  2021-07-15 
> 18:40:16.0 -0600
> --- 
> lynx2.9.0dev.10_patchedforfigcaption/WWW/Library/Implementation/hdr_HTMLDTD.h 
> 2022-10-24 12:30:41.189510975 -0600
...

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#1022942: xterm: cannot load font "-*-terminus-*-*-*-32-*-*-*-*-*-*-*"

[Thomas Dickey]

On Fri, Oct 28, 2022 at 03:49:52AM -0400, Thomas Dickey wrote:
> On Fri, Oct 28, 2022 at 08:51:50AM +0200, Andreas Tille wrote:
> > Package: xterm
> > Version: 375-1
> > Severity: important
> > 
> > Hi,
> > 
> > after upgrading from xterm 374-1 to 375-1 I get:
> > 
> > $ xterm
> > xterm: cannot load font "-*-terminus-*-*-*-32-*-*-*-*-*-*-*"
> > Segmentation fault
> > 
> > I guess this local setting is relevant:
> > 
> > $ grep font /etc/X11/Xresources/xterm  | grep -v ^!
> > *VT100.utf8Fonts.font: fixed
> > XTerm.VT100.font1: -*-terminus-*-*-*-16-*-*-*-*-*-*-*
> > XTerm.VT100.font2: -*-terminus-*-*-*-18-*-*-*-*-*-*-*   
> >
> > XTerm.VT100.font3: -*-terminus-*-*-*-20-*-*-*-*-*-*-*   
> >
> > XTerm.VT100.font4: -*-terminus-*-*-*-24-*-*-*-*-*-*-*
> > XTerm.VT100.font5: -*-terminus-*-*-*-28-*-*-*-*-*-*-*   
> >
> > XTerm.VT100.font6: -*-terminus-*-*-*-32-*-*-*-*-*-*-*

for the record, xfonts-terminus includes all of these sizes.

> > here.  If I uncomment these settings xterm starts.  However, I think xterm 
> > should not
> 
> Is that "uncomment", or "comment"?
> 
> (the grep seems to indicate that the latter is meant)
> 
> > crash with segmentation fault when not finding some specified font.
> 
> agreed -

I've not been able to reproduce the problem, which I suspect is in
the error-recovery section of xterm's xtermLoadFont function.

Perhaps seeing the whole set of resources would help
(the output of "xrdb -query", too).

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#1022942: xterm: cannot load font "-*-terminus-*-*-*-32-*-*-*-*-*-*-*"

[Thomas Dickey]

On Fri, Oct 28, 2022 at 03:49:52AM -0400, Thomas Dickey wrote:
> On Fri, Oct 28, 2022 at 08:51:50AM +0200, Andreas Tille wrote:
> > Package: xterm
> > Version: 375-1
> > Severity: important
> > 
> > Hi,
> > 
> > after upgrading from xterm 374-1 to 375-1 I get:
> > 
> > $ xterm
> > xterm: cannot load font "-*-terminus-*-*-*-32-*-*-*-*-*-*-*"
> > Segmentation fault
> > 
> > I guess this local setting is relevant:
> > 
> > $ grep font /etc/X11/Xresources/xterm  | grep -v ^!
> > *VT100.utf8Fonts.font: fixed
> > XTerm.VT100.font1: -*-terminus-*-*-*-16-*-*-*-*-*-*-*
> > XTerm.VT100.font2: -*-terminus-*-*-*-18-*-*-*-*-*-*-*   
> >
> > XTerm.VT100.font3: -*-terminus-*-*-*-20-*-*-*-*-*-*-*   
> >
> > XTerm.VT100.font4: -*-terminus-*-*-*-24-*-*-*-*-*-*-*
> > XTerm.VT100.font5: -*-terminus-*-*-*-28-*-*-*-*-*-*-*   
> >
> > XTerm.VT100.font6: -*-terminus-*-*-*-32-*-*-*-*-*-*-*

for the record, xfonts-terminus includes all of these sizes.

> > here.  If I uncomment these settings xterm starts.  However, I think xterm 
> > should not
> 
> Is that "uncomment", or "comment"?
> 
> (the grep seems to indicate that the latter is meant)
> 
> > crash with segmentation fault when not finding some specified font.
> 
> agreed -

I've not been able to reproduce the problem, which I suspect is in
the error-recovery section of xterm's xtermLoadFont function.

Perhaps seeing the whole set of resources would help
(the output of "xrdb -query", too).

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

ANN: luit-20221028

[Thomas Dickey]

Files:
  https://invisible-island.net/archives/luit/current/luit-2.0.20221028.tgz
  https://invisible-island.net/archives/luit/current/luit-2.0.20221028.tgz.asc
  https://invisible-island.net/archives/luit/luit-20221028.tgz
  https://invisible-island.net/archives/luit/luit-20221028.tgz.asc

https://invisible-island.net/luit/
https://invisible-island.net/luit/luit.log.html

   2022/10/28 -
 * fix a few compiler-warnings
 * updated plink.sh, from xterm.
 * updated configure script, to work around regression in grep 3.8
 * updated configure macros for compiler-warning fixes.
 * update config.guess, config.sub, install-sh


-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#1022942: xterm: cannot load font "-*-terminus-*-*-*-32-*-*-*-*-*-*-*"

[Thomas Dickey]

On Fri, Oct 28, 2022 at 08:51:50AM +0200, Andreas Tille wrote:
> Package: xterm
> Version: 375-1
> Severity: important
> 
> Hi,
> 
> after upgrading from xterm 374-1 to 375-1 I get:
> 
> $ xterm
> xterm: cannot load font "-*-terminus-*-*-*-32-*-*-*-*-*-*-*"
> Segmentation fault
> 
> I guess this local setting is relevant:
> 
> $ grep font /etc/X11/Xresources/xterm  | grep -v ^!
> *VT100.utf8Fonts.font: fixed
> XTerm.VT100.font1: -*-terminus-*-*-*-16-*-*-*-*-*-*-*
> XTerm.VT100.font2: -*-terminus-*-*-*-18-*-*-*-*-*-*-* 
>  
> XTerm.VT100.font3: -*-terminus-*-*-*-20-*-*-*-*-*-*-* 
>  
> XTerm.VT100.font4: -*-terminus-*-*-*-24-*-*-*-*-*-*-*
> XTerm.VT100.font5: -*-terminus-*-*-*-28-*-*-*-*-*-*-* 
>  
> XTerm.VT100.font6: -*-terminus-*-*-*-32-*-*-*-*-*-*-*
> 
> here.  If I uncomment these settings xterm starts.  However, I think xterm 
> should not

Is that "uncomment", or "comment"?

(the grep seems to indicate that the latter is meant)

> crash with segmentation fault when not finding some specified font.

agreed -
 
> Kind regards
> Andreas.
> 
> 
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing'), (50, 'buildd-unstable'), 
> (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 6.0.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not 
> set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages xterm depends on:
> ii  libc6   2.35-4
> ii  libfontconfig1  2.13.1-4.5
> ii  libfreetype62.12.1+dfsg-3
> ii  libice6 2:1.0.10-1
> ii  libtinfo6   6.3+20220423-2
> ii  libutempter01.2.1-2
> ii  libx11-62:1.8.1-2
> ii  libxaw7 2:1.0.14-1
> ii  libxext62:1.3.4-1+b1
> ii  libxft2 2.3.6-1
> ii  libxinerama12:1.1.4-3
> ii  libxmu6 2:1.1.3-3
> ii  libxpm4 1:3.5.12-1
> ii  libxt6  1:1.2.1-1
> ii  xbitmaps1.1.1-2.2
> 
> Versions of packages xterm recommends:
> ii  x11-utils  7.7+5
> 
> Versions of packages xterm suggests:
> pn  xfonts-cyrillic  
> 
> -- no debconf information
> 

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#1022942: xterm: cannot load font "-*-terminus-*-*-*-32-*-*-*-*-*-*-*"

[Thomas Dickey]

On Fri, Oct 28, 2022 at 08:51:50AM +0200, Andreas Tille wrote:
> Package: xterm
> Version: 375-1
> Severity: important
> 
> Hi,
> 
> after upgrading from xterm 374-1 to 375-1 I get:
> 
> $ xterm
> xterm: cannot load font "-*-terminus-*-*-*-32-*-*-*-*-*-*-*"
> Segmentation fault
> 
> I guess this local setting is relevant:
> 
> $ grep font /etc/X11/Xresources/xterm  | grep -v ^!
> *VT100.utf8Fonts.font: fixed
> XTerm.VT100.font1: -*-terminus-*-*-*-16-*-*-*-*-*-*-*
> XTerm.VT100.font2: -*-terminus-*-*-*-18-*-*-*-*-*-*-* 
>  
> XTerm.VT100.font3: -*-terminus-*-*-*-20-*-*-*-*-*-*-* 
>  
> XTerm.VT100.font4: -*-terminus-*-*-*-24-*-*-*-*-*-*-*
> XTerm.VT100.font5: -*-terminus-*-*-*-28-*-*-*-*-*-*-* 
>  
> XTerm.VT100.font6: -*-terminus-*-*-*-32-*-*-*-*-*-*-*
> 
> here.  If I uncomment these settings xterm starts.  However, I think xterm 
> should not

Is that "uncomment", or "comment"?

(the grep seems to indicate that the latter is meant)

> crash with segmentation fault when not finding some specified font.

agreed -
 
> Kind regards
> Andreas.
> 
> 
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing'), (50, 'buildd-unstable'), 
> (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 6.0.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not 
> set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages xterm depends on:
> ii  libc6   2.35-4
> ii  libfontconfig1  2.13.1-4.5
> ii  libfreetype62.12.1+dfsg-3
> ii  libice6 2:1.0.10-1
> ii  libtinfo6   6.3+20220423-2
> ii  libutempter01.2.1-2
> ii  libx11-62:1.8.1-2
> ii  libxaw7 2:1.0.14-1
> ii  libxext62:1.3.4-1+b1
> ii  libxft2 2.3.6-1
> ii  libxinerama12:1.1.4-3
> ii  libxmu6 2:1.1.3-3
> ii  libxpm4 1:3.5.12-1
> ii  libxt6  1:1.2.1-1
> ii  xbitmaps1.1.1-2.2
> 
> Versions of packages xterm recommends:
> ii  x11-utils  7.7+5
> 
> Versions of packages xterm suggests:
> pn  xfonts-cyrillic  
> 
> -- no debconf information
> 

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Re: [Lynx-dev] colo(u)red figcaptions

[Thomas Dickey]

On Mon, Oct 24, 2022 at 10:11:35PM -0600, rbell--- via Lynx-dev wrote:
>   I found my mistake.  How do I create a patch?  I tried:
> 
>   diff -ruN lynx2.9.0dev.10 lynx2.9.0dev.10_patchedforfigcaption  > patch
> 
> but it looks different from official patches - and it doesn't work.

I use a script (an old version of makepatch, pre-GPL, with my fixes),

https://invisible-island.net/scripts/readme.html#item:makepatch

to get the "Index" lines, in a script which does this

makepatch -diff "diff -u" $1 $2  >$tmp

but diff -Naur will provide equivalent diff's

Perhaps (on applying the patch), you didn't provide the -p1 option.

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Re: vile source links

[Thomas Dickey]

On Sat, Oct 22, 2022 at 01:42:21PM +, Wayne Cuddy via discussions 
concerning the vile text editor wrote:
> On Fri, Oct 21, 2022 at 07:42:01PM -0400, Thomas Dickey wrote:
> > On Fri, Oct 21, 2022 at 06:20:40PM +, Wayne Cuddy via discussions 
> > concerning the vile text editor wrote:
> > > On the vile download page:
> > > 
> > > https://www.invisible-island.net/vile/vile.html#download
> > > 
> > > The links for the source downloads:
> > > 
> > > https://www.invisible-island.net/archives/vile/vile.tar.gz
> > > 
> > > https://www.invisible-island.net/datafiles/release/vile.tar.gz
> > > 
> > > These both seem to point to the older 9.8 release instead of 9.8w. Is
> > > this intentional?
> > 
> > sort of (the versioning with letter suffixes seems to be acceptable to
> > everyone -- though I recall quite a while ago a packager refusing to
> > do anything with vile unless it ended ".0" -- and I've seen no real
> > need recently for a "stable release").
> > 
> > "current" is where you should look:
> > 
> > https://invisible-island.net/datafiles/current/vile.tar.gz
> > https://invisible-island.net/archives/vile/current/vile.tar.gz
> > https://invisible-island.net/archives/vile/current/
> >
> 
> I totally ignored those links for some reason. Perhaps because they are
> suffixed with (for installers).
> 
> I'll make a note of that.

sounds good (I'm working on several things currently, but one of the
threads leads back to vile - will have to think how to better lay out
the page).

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Re: [Lynx-dev] colo(u)red figcaptions

[Thomas Dickey]

On Fri, Oct 21, 2022 at 08:00:14AM -0600, rbell--- via Lynx-dev wrote:
>   A patch!  Just the thing.  I searched for CAPTION in the
> source, found it in:
> 
>   WWW/Library/Implementation/src1_HTMLDTD.txt
>   WWW/Library/Implementation/hdr_HTMLDTD.h
>   WWW/Library/Implementation/src0_HTMLDTD.txt
>   WWW/Library/Implementation/src0_HTMLDTD.h
>   WWW/Library/Implementation/src1_HTMLDTD.h
>   src/HTML.h
>   src/HTML.c
>   src/LYCharUtils.c
> 
> 
> copied its model for FIGCAPTION, built without complaint, but no
> difference.  I must have missed something.

the above hints that you went in the right direction,
but without a diff/patch that others can inspect,
no one can tell if you reached your destination.

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

ANN: xterm-375

[Thomas Dickey]

Files:
  https://invisible-island.net/archives/xterm/current/xterm-375.tgz
  https://invisible-island.net/archives/xterm/current/xterm-375.tgz.asc
  https://invisible-island.net/archives/xterm/patches/xterm-375.patch.gz
  https://invisible-island.net/archives/xterm/patches/xterm-375.patch.gz.asc
  https://invisible-island.net/archives/xterm/xterm-375.tgz
  https://invisible-island.net/archives/xterm/xterm-375.tgz.asc

Patch #375 - 2022/10/23

 * improve  error-recovery  when  setting  a bitmap font for the VT100
   window,  e.g.,  in  case  OSC 50  failed, restoring the most recent
   valid  font  so  that  a  subsequent  OSC 50 reports this correctly
   (report by David Leadbeater).
 * exclude  MC_XDG_OPEN  from environment variables trimmed on startup
   (report by Gabor Hauzer).
 * check for null pointer in isSelect() (report by Column Paget).


-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

ANN: xterm-375

[Thomas Dickey]

Files:
  https://invisible-island.net/archives/xterm/current/xterm-375.tgz
  https://invisible-island.net/archives/xterm/current/xterm-375.tgz.asc
  https://invisible-island.net/archives/xterm/patches/xterm-375.patch.gz
  https://invisible-island.net/archives/xterm/patches/xterm-375.patch.gz.asc
  https://invisible-island.net/archives/xterm/xterm-375.tgz
  https://invisible-island.net/archives/xterm/xterm-375.tgz.asc

Patch #375 - 2022/10/23

 * improve  error-recovery  when  setting  a bitmap font for the VT100
   window,  e.g.,  in  case  OSC 50  failed, restoring the most recent
   valid  font  so  that  a  subsequent  OSC 50 reports this correctly
   (report by David Leadbeater).
 * exclude  MC_XDG_OPEN  from environment variables trimmed on startup
   (report by Gabor Hauzer).
 * check for null pointer in isSelect() (report by Column Paget).


-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Re: vile source links

[Thomas Dickey]

On Fri, Oct 21, 2022 at 06:20:40PM +, Wayne Cuddy via discussions 
concerning the vile text editor wrote:
> On the vile download page:
> 
> https://www.invisible-island.net/vile/vile.html#download
> 
> The links for the source downloads:
> 
> https://www.invisible-island.net/archives/vile/vile.tar.gz
> 
> https://www.invisible-island.net/datafiles/release/vile.tar.gz
> 
> These both seem to point to the older 9.8 release instead of 9.8w. Is
> this intentional?

sort of (the versioning with letter suffixes seems to be acceptable to
everyone -- though I recall quite a while ago a packager refusing to
do anything with vile unless it ended ".0" -- and I've seen no real
need recently for a "stable release").

"current" is where you should look:

https://invisible-island.net/datafiles/current/vile.tar.gz
https://invisible-island.net/archives/vile/current/vile.tar.gz
https://invisible-island.net/archives/vile/current/

> Should I be using another link to access to latest source?
> 

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Re: [Lynx-dev] assign or view colors on INS: or DEL: on wikipedia diff page

[Thomas Dickey]

On Sat, Oct 15, 2022 at 08:21:13AM +, jindam, vani via Lynx-dev wrote:
> hello lynx devs,
> 
> i want to assign or view background or 
> foreground colors for INS: or DEL: on 
> wikipedia diff page.
> 
> https://en.wikipedia.org/w/index.php?title=Sarai_metro_station=prev=1116048286
>  contains tag or text in normal & mobile view mode: INS: or DEL: 
> i found both tags are in div tag on 
> "view-source:https://en.m.wikipedia.org/w/index.php?title=Special:MobileDiff/1116048286=1;
>  and
> but only del tag in td on 
> "view-source:https://en.wikipedia.org/w/index.php?title=Sarai_metro_station=prev=1116048286;
> 
> my settings:
> (1) lynx.cfg :: 
> (a) h2 COLOR_STYLE :: COLOR_STYLE: lynx.lss
> (b) .h2 PRETTYSRC
> # Enable pretty source view
>  PRETTYSRC:FALSE & PRETTYSRC:TRUE
> (c) enabled all: PRETTYSRC_SPEC
> (2) 'o' key on lynx
> show color —on, color style —lynx.lss, default colors —on.
> (3) lynx.lss :: span.htmlsrc_tag:normal:  white/red/magenta

This seems to work:

ins:reverse:green
del:reverse:red
 
> none of the above settings did not change 
> white default color on INS: or DEL:
> 
> perhaps, i misunderstood or expecting incorrectly. please let me know.
> 
> regards,
> jindam, vani
> 
> toots: @jindam_v...@c.im
> others: en.wikipedia.org/wiki/User:Jindam_vani
> 
> lynx-dev@nongnu.org
> 

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

ANN: xterm-374

[Thomas Dickey]

Files:
  https://invisible-island.net/archives/xterm/current/xterm-374.tgz
  https://invisible-island.net/archives/xterm/current/xterm-374.tgz.asc
  https://invisible-island.net/archives/xterm/patches/xterm-374.patch.gz
  https://invisible-island.net/archives/xterm/patches/xterm-374.patch.gz.asc
  https://invisible-island.net/archives/xterm/xterm-374.tgz
  https://invisible-island.net/archives/xterm/xterm-374.tgz.asc

Patch #374 - 2022/10/10

 * eliminate use of grep aliases from vttests scripts.
 * amend  discussion  of  DECSDM  versus Sixel Scrolling in ctlseqs.ms
   (reports by Hayaki Saito, Ben Wong).
 * change   default   for  sixelScrolling  resource  to  better  match
   VT330/VT340 DECSDM setting (patch by Ben Wong).
 * fix some gcc and coverity warnings.
 * improve memory usage for OSC 52 (report by David Leadbeater).
 * fixregressioninxterm-373change   adding   resources
   xftTrackMemUsage  to  xftMaxGlyphMemory,  which did not first cache
   the server's resource-settings (report/testcase by Gabor Hauzer, as
   well as Debian #1021243).
 * fix  regression  in  xterm-373  change for status-line vs alternate
   screen (report by Rajeev V. Pillai).
 * configure script improvements:
  + modify  CF_XOPEN_SOURCE  to handle more special cases of Linux
(reports by Adam Sampson, Sven Joachim).
  + modify  checks  for egrep/fgrep aliases to work around warning
messages from GNU grep 3.8


-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

ANN: xterm-374

[Thomas Dickey]

Files:
  https://invisible-island.net/archives/xterm/current/xterm-374.tgz
  https://invisible-island.net/archives/xterm/current/xterm-374.tgz.asc
  https://invisible-island.net/archives/xterm/patches/xterm-374.patch.gz
  https://invisible-island.net/archives/xterm/patches/xterm-374.patch.gz.asc
  https://invisible-island.net/archives/xterm/xterm-374.tgz
  https://invisible-island.net/archives/xterm/xterm-374.tgz.asc

Patch #374 - 2022/10/10

 * eliminate use of grep aliases from vttests scripts.
 * amend  discussion  of  DECSDM  versus Sixel Scrolling in ctlseqs.ms
   (reports by Hayaki Saito, Ben Wong).
 * change   default   for  sixelScrolling  resource  to  better  match
   VT330/VT340 DECSDM setting (patch by Ben Wong).
 * fix some gcc and coverity warnings.
 * improve memory usage for OSC 52 (report by David Leadbeater).
 * fixregressioninxterm-373change   adding   resources
   xftTrackMemUsage  to  xftMaxGlyphMemory,  which did not first cache
   the server's resource-settings (report/testcase by Gabor Hauzer, as
   well as Debian #1021243).
 * fix  regression  in  xterm-373  change for status-line vs alternate
   screen (report by Rajeev V. Pillai).
 * configure script improvements:
  + modify  CF_XOPEN_SOURCE  to handle more special cases of Linux
(reports by Adam Sampson, Sven Joachim).
  + modify  checks  for egrep/fgrep aliases to work around warning
messages from GNU grep 3.8


-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#1021243: xterm: different font size after upgrading from 372-1 to 373-1

[Thomas Dickey]

- Original Message -
| From: "Thomas Dickey" 
| To: 1021...@bugs.debian.org
| Cc: 1021243-submit...@bugs.debian.org
| Sent: Tuesday, October 4, 2022 8:22:23 PM
| Subject: Bug#1021243: xterm: different font size after upgrading from 372-1 
to 373-1

| On Tue, Oct 04, 2022 at 11:36:50AM +0200, Emanuele Rocca wrote:
|> Package: xterm
|> Version: 373-1
|> Severity: important
|> 
|> Hi,
|> 
|> the upgrade from xterm 372-1 to 373-1 changes font size on my system.
|> 
|> See what the fonts used to look like with 372-1 vs 373-1 in the attached
|> screenshots.
| 
| thanks (I had a similar report yesterday, and am investigating)

https://github.com/ThomasDickey/xterm-snapshots/commit/932678ac4823db3f94fc831b4c0db89307b04a5c

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://ftp.invisible-island.net

Bug#1021243: xterm: different font size after upgrading from 372-1 to 373-1

[Thomas Dickey]

- Original Message -
| From: "Thomas Dickey" 
| To: 1021...@bugs.debian.org
| Cc: 1021243-submit...@bugs.debian.org
| Sent: Tuesday, October 4, 2022 8:22:23 PM
| Subject: Bug#1021243: xterm: different font size after upgrading from 372-1 
to 373-1

| On Tue, Oct 04, 2022 at 11:36:50AM +0200, Emanuele Rocca wrote:
|> Package: xterm
|> Version: 373-1
|> Severity: important
|> 
|> Hi,
|> 
|> the upgrade from xterm 372-1 to 373-1 changes font size on my system.
|> 
|> See what the fonts used to look like with 372-1 vs 373-1 in the attached
|> screenshots.
| 
| thanks (I had a similar report yesterday, and am investigating)

https://github.com/ThomasDickey/xterm-snapshots/commit/932678ac4823db3f94fc831b4c0db89307b04a5c

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://ftp.invisible-island.net

Bug#1021243: xterm: different font size after upgrading from 372-1 to 373-1

[Thomas Dickey]

On Tue, Oct 04, 2022 at 11:36:50AM +0200, Emanuele Rocca wrote:
> Package: xterm
> Version: 373-1
> Severity: important
> 
> Hi,
> 
> the upgrade from xterm 372-1 to 373-1 changes font size on my system.
> 
> See what the fonts used to look like with 372-1 vs 373-1 in the attached
> screenshots.

thanks (I had a similar report yesterday, and am investigating)

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#1021243: xterm: different font size after upgrading from 372-1 to 373-1

[Thomas Dickey]

On Tue, Oct 04, 2022 at 11:36:50AM +0200, Emanuele Rocca wrote:
> Package: xterm
> Version: 373-1
> Severity: important
> 
> Hi,
> 
> the upgrade from xterm 372-1 to 373-1 changes font size on my system.
> 
> See what the fonts used to look like with 372-1 vs 373-1 in the attached
> screenshots.

thanks (I had a similar report yesterday, and am investigating)

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Re: Yet another leak in Xlib

[Thomas Dickey]

On Mon, Oct 03, 2022 at 06:47:32PM +0800, Po Lu wrote:
> Po Lu  writes:
> 
> > ==67186== 408 bytes in 1 blocks are definitely lost in loss record 272 of 
> > 344
> > ==67186==at 0x484A464: calloc (vg_replace_malloc.c:1328)
> > ==67186==by 0x490935F: _XimOpenIM (in /usr/lib64/libX11.so.6.4.0)
> > ==67186==by 0x490F386: _XimRegisterIMInstantiateCallback (in 
> > /usr/lib64/libX11.so.6.4.0)
> > ==67186==by 0x48FBDBD: XRegisterIMInstantiateCallback (in 
> > /usr/lib64/libX11.so.6.4.0)
> > ==67186==by 0x4456B5: tiInitTextInput (text_input.c:837)
> > ==67186==by 0x4079C5: dlMain (loader.c:205)
> > ==67186==by 0x4079F2: main (loader.c:214)
> 
> diff --git a/modules/im/ximcp/imInsClbk.c b/modules/im/ximcp/imInsClbk.c
> index 95b379cb..c10e347f 100644
> --- a/modules/im/ximcp/imInsClbk.c
> +++ b/modules/im/ximcp/imInsClbk.c
> @@ -212,6 +212,9 @@ _XimRegisterIMInstantiateCallback(
>  if( xim ) {
>   lock = True;
>   xim->methods->close( (XIM)xim );
> + /* XIMs must be freed manually after being opened; close just
> +does the protocol to deinitialize the IM.  */
> + XFree( xim );

looks okay reading the library code (src/xlibi18n/XDefaultIMIF.c, _CloseIM).

xterm doesn't free that 'xim' value (and the XCloseIM manual page doesn't
say who's responsible for that -- though it's possible that some other
application developer read the library source code and is freeing it).

>   lock = False;
>   icb->call = True;
>   callback( display, client_data, NULL );
> 
> Does this seem right?

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Re: A somewhat off-topic question about ncurses and wrapping long lines

[Thomas Dickey]

On Sun, Oct 02, 2022 at 09:22:03AM +0100, Chris Green wrote:
> On Sat, Oct 01, 2022 at 06:35:26PM -0400, Thomas Dickey wrote:
> > On Sat, Oct 01, 2022 at 10:01:00AM +0100, Chris Green wrote:
> > > Well it's not entirely off topic, it's about something that works as
> > > I'd expect it to in vile (and less) but doesn't work right in mutt (my
> > > E-Mail program of choice).
> > > 
> > > The issue is about how long chunks of text, with no spaces in them,
> > > are wrapped when they are too long to fit in the terminal width.  The
> > > typical case (and the one that is a particular problem in mutt) is
> > > that of long URLs.  This *isn't* about how these programs manage
> > > wrapping normal text made up of 'words' with spaces in between.
> > > 
> > > In less or vile when there is a long piece of text and you have told
> > > less/vile to wrap long lines then the long URL (or whatever) is
> > > displayed wrapped at the right margin but it is still a single string
> > > and you can select it in the terminal by right clicking on it.
> > > 
> > > In mutt (in mutt's internal pager specifically) however, although the
> > > URL is displayed the same (i.e. wrapped at the right margin) it's
> > > actually broken into one or more lines and you *can't* select it by
> > > right clicking on it, you just get the single line that you click on.
> > > 
> > > This has been discussed at length at various times on the mutt mailing
> > > list and hasn't been solved.
> > 
> > I'm subscribed to mutt-dev (don't recall it there).
> > Perhaps mutt-user...
> 
> Yes, it's mutt-users.
> 
> > 
> > (none of the mutt development gets very deep into this stuff)
> >  
> > > Is there some specific way of using/calling ncurses which does what we
> > > want?  ... and/or does ncurses default to breaking the string at the
> > > page margin and need some option to prevent it doing this?
> > 
> > It's a special case of xterm (imitated by more than one terminal emulator,
> > though probably not _all_).  xterm notices when a line is written and
> > wraps.  Screen updates that simply write to the end of a line (including
> > a previously "wrapped" line) make it forget about follow part of a line.
> > 
> I sort of understand. So you're saying that it's the xterm (or
> similar) that is inserting the LF after mutt has output a long string
> using ncurses.

When xterm is asked (by another client that wants to paste the selection)
for the selection, it copies from its window the characters for the
selected range of columns/lines.  As it does that, it checks at the end
of each line whether that was wrapped -- and adds a newline in that case.

Double-clicking on a line does the same thing -- extending the selection
to the entire (wrapped) line.

The "wrapped" term in a half-dozen places in xterm's manpage is talking
about this...
 
> > less and vile have an advantage over ncurses in deciding if a line is
> > wrapped -- ncurses can't tell if an application writes text (using one
> > of the wrapping calls such as waddch) intending to construct a long line.
> > 
> So vile and less manage the wrapping themselves whereas xterm does it
> for mutt - is that the difference?

no - vile and less just happen to work when they write a wrapped line.

If they were smarter and only wrote the parts of lines that changed,
then they wouldn't trigger the special handling in the terminal
emulator that tells _it_ that this is one long line.
 
> I thought vile used ncurses.

vile (in a terminal) could be termcap, terminfo or curses :-)

fwiw, it's terminfo in Debian, which makes vile doing the screen updates.

(ncurses provides terminfo, but that's a low-level feature which is
different from the higher-level stuff that mutt is using)
 
> > Actually, long lines in mutt for me have a "+" marking the beginning
> > of the following lines (which iirc is configurable).
> >  
> I have "set nomarkers" in my muttrc which turns the + off.  At least
> one can then manually select the long URL and paste it into a browser
> address bar (as long as the browser, correctly, inores the embedded
> LF). However right-clicking the URL would be much handier.

agreed, but without some planning in the code, curses will just update
the places on a screen which have changed, and one you add in scrolling,
it's hard to say whether the library should have tweaked its updates to
ensure that wrapped lines are pasted together again :-)
 
> > > I'm floundering a bit at understanding this as I'm not really sure
> > > it's an ncurses issue but it does seem to be pretty 

Re: A somewhat off-topic question about ncurses and wrapping long lines

[Thomas Dickey]

On Sat, Oct 01, 2022 at 10:01:00AM +0100, Chris Green wrote:
> Well it's not entirely off topic, it's about something that works as
> I'd expect it to in vile (and less) but doesn't work right in mutt (my
> E-Mail program of choice).
> 
> The issue is about how long chunks of text, with no spaces in them,
> are wrapped when they are too long to fit in the terminal width.  The
> typical case (and the one that is a particular problem in mutt) is
> that of long URLs.  This *isn't* about how these programs manage
> wrapping normal text made up of 'words' with spaces in between.
> 
> In less or vile when there is a long piece of text and you have told
> less/vile to wrap long lines then the long URL (or whatever) is
> displayed wrapped at the right margin but it is still a single string
> and you can select it in the terminal by right clicking on it.
> 
> In mutt (in mutt's internal pager specifically) however, although the
> URL is displayed the same (i.e. wrapped at the right margin) it's
> actually broken into one or more lines and you *can't* select it by
> right clicking on it, you just get the single line that you click on.
> 
> This has been discussed at length at various times on the mutt mailing
> list and hasn't been solved.

I'm subscribed to mutt-dev (don't recall it there).
Perhaps mutt-user...

(none of the mutt development gets very deep into this stuff)
 
> Is there some specific way of using/calling ncurses which does what we
> want?  ... and/or does ncurses default to breaking the string at the
> page margin and need some option to prevent it doing this?

It's a special case of xterm (imitated by more than one terminal emulator,
though probably not _all_).  xterm notices when a line is written and
wraps.  Screen updates that simply write to the end of a line (including
a previously "wrapped" line) make it forget about follow part of a line.

less and vile have an advantage over ncurses in deciding if a line is
wrapped -- ncurses can't tell if an application writes text (using one
of the wrapping calls such as waddch) intending to construct a long line.

Actually, long lines in mutt for me have a "+" marking the beginning
of the following lines (which iirc is configurable).
 
> I'm floundering a bit at understanding this as I'm not really sure
> it's an ncurses issue but it does seem to be pretty much the same
> regardless of other things.  I use /usr/bin/xfce4-terminal but the
> same happens to lots of other people and I have tried other terminal
> emulators and seen no change.
> 
> Can anyone throw any light on this?
> 
> -- 
> Chris Green
> 

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Re: [Lynx-dev] Alert!: Illegal redirection URL received from server! WHEN USING HTTP_PROXY & HTTPS_PROXY

[Thomas Dickey]

On Wed, Sep 21, 2022 at 12:44:24PM -0400, Philippe Jean wrote:
> Thir url 
> (https://www.google.com/sorry/index?continue=https://www.google.com/search%3Fq%3Dlynx%2520browser%2520configuration%2520file%2520socks5%2520proxy%26num%3D30=EhAgAQZ8JmAEJQAmAANnGMT7rJkGIhAFDhEOM7juXZaTTugEuQScMgFy)
> works when I'm not using http_proxy and https_proxy env settings in
> lynx.cfg.
> 
> I'm using OperaProxy that is using TOR.

the trace log would show how lynx is parsing the intermediate result,
immediately before the message.

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

ANN: xterm-373

[Thomas Dickey]

Files:
  https://invisible-island.net/archives/xterm/current/xterm-373.tgz
  https://invisible-island.net/archives/xterm/current/xterm-373.tgz.asc
  https://invisible-island.net/archives/xterm/patches/xterm-373.patch.gz
  https://invisible-island.net/archives/xterm/patches/xterm-373.patch.gz.asc
  https://invisible-island.net/archives/xterm/xterm-373.tgz
  https://invisible-island.net/archives/xterm/xterm-373.tgz.asc

Patch #373 - 2022/09/25

 * improve rendering of TrueType fonts:
  + add  resource xftTrackMemUsage to enable/disable a new feature
of Xft which improves performance.
  + add   resources   xftMaxGlyphMemory  and  xftMaxUnrefFonts  to
customize memory-usage of Xft and fontconfig.
  + provide for display of colored fonts in libXft 2.3.5
  + allow for an extra TrueType font to be specified using the -fa
option,  as  an  override to the fontconfig scheme of fallback
fonts (request by Nickolas Raymond Kaczynski).
  + improve caching of TrueType missing-glyph tests.
  + allow no more than 255 fonts to be scanned for a fontset.
  + eliminate a table-lookup in findXftGlyph
 * improvements status-line feature:
  + save/restore  wraparound  flag  when  updating the status-line
(report by Rajeev V. Pillai).
  + avoid  clearing  the status-line when switching between normal
and alternate screens (report by Valtteri Vuorikoski).
  + remove  adjustment  from  update_winsize leftover from initial
work (report by Valtteri Vuorikoski).
 * modify wcwidth tables to separate Unicode Cf category as formatting
   control-characters,  to  better match the guideline for unsupported
   characters (report by Tim Chase).
 * add configure option --disable-exec-selection.
 * use mkstemp where mkdtemp is unavailable, when initializing colored
   cursor.
 * adapt fixes from OpenBSD xenocara:
  + improve ifdef's for a few optional features.
  + correct #ifdef to #if in a few uses of OPT_PRINT_ON_EXIT.
 * set   StartupWMClass   in   “.desktop”  files,  e.g.,  to  help
   cinnamon-session  notice  that xterm sets WM_CLASS and use its icon
   (patch by Richard de Boer).
 * disable pixel computation when rgb width is greater than 8, to work
   with depth 30 (patch by Denis Kaganovich).
 * improve  color-computation  for  SGR  2  faint/dim  (patch by Boian
   Bonev).  Add  resource  faintIsRelative  to specify if the modified
   computation  should  be  used (prompted by discussion with Matthieu
   Herrb).
 * correct  comparison-length  for environment variable cleanup (patch
   by Brendan O' Dea).
 * correct  dsl  capability  for  dec+sl  block in terminfo (report by
   Rajeev V. Pillai).
 * improve output formatting by vttests/utf8.pl
 * repair  test/demo  scripts  still using "vxt-" prefix, some cleanup
   with shellcheck.
 * enable page-number for DECXCPR response in VT330.
 * amend  change for combining characters in patch #371 to limit it to
   the currently-defined codes (report by Thomas Wolff).
 * add  directory-template  parameter  to  mktemp  in shell-scripts to
   improve portability to older systems (patch by Ryan Schmidt).
 * mention webpage XTerm – bracketed-paste in ctlseqs.ms
 * update   manual-page   descriptions   for   allowPasteControls  and
   disallowedPasteControls (patch #363).
 * further  extended list of environment variables to purge on startup
   (suggested by Thomas Wolff).
 * update config.guess, config.sub


-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

ANN: xterm-373

[Thomas Dickey]

Files:
  https://invisible-island.net/archives/xterm/current/xterm-373.tgz
  https://invisible-island.net/archives/xterm/current/xterm-373.tgz.asc
  https://invisible-island.net/archives/xterm/patches/xterm-373.patch.gz
  https://invisible-island.net/archives/xterm/patches/xterm-373.patch.gz.asc
  https://invisible-island.net/archives/xterm/xterm-373.tgz
  https://invisible-island.net/archives/xterm/xterm-373.tgz.asc

Patch #373 - 2022/09/25

 * improve rendering of TrueType fonts:
  + add  resource xftTrackMemUsage to enable/disable a new feature
of Xft which improves performance.
  + add   resources   xftMaxGlyphMemory  and  xftMaxUnrefFonts  to
customize memory-usage of Xft and fontconfig.
  + provide for display of colored fonts in libXft 2.3.5
  + allow for an extra TrueType font to be specified using the -fa
option,  as  an  override to the fontconfig scheme of fallback
fonts (request by Nickolas Raymond Kaczynski).
  + improve caching of TrueType missing-glyph tests.
  + allow no more than 255 fonts to be scanned for a fontset.
  + eliminate a table-lookup in findXftGlyph
 * improvements status-line feature:
  + save/restore  wraparound  flag  when  updating the status-line
(report by Rajeev V. Pillai).
  + avoid  clearing  the status-line when switching between normal
and alternate screens (report by Valtteri Vuorikoski).
  + remove  adjustment  from  update_winsize leftover from initial
work (report by Valtteri Vuorikoski).
 * modify wcwidth tables to separate Unicode Cf category as formatting
   control-characters,  to  better match the guideline for unsupported
   characters (report by Tim Chase).
 * add configure option --disable-exec-selection.
 * use mkstemp where mkdtemp is unavailable, when initializing colored
   cursor.
 * adapt fixes from OpenBSD xenocara:
  + improve ifdef's for a few optional features.
  + correct #ifdef to #if in a few uses of OPT_PRINT_ON_EXIT.
 * set   StartupWMClass   in   “.desktop”  files,  e.g.,  to  help
   cinnamon-session  notice  that xterm sets WM_CLASS and use its icon
   (patch by Richard de Boer).
 * disable pixel computation when rgb width is greater than 8, to work
   with depth 30 (patch by Denis Kaganovich).
 * improve  color-computation  for  SGR  2  faint/dim  (patch by Boian
   Bonev).  Add  resource  faintIsRelative  to specify if the modified
   computation  should  be  used (prompted by discussion with Matthieu
   Herrb).
 * correct  comparison-length  for environment variable cleanup (patch
   by Brendan O' Dea).
 * correct  dsl  capability  for  dec+sl  block in terminfo (report by
   Rajeev V. Pillai).
 * improve output formatting by vttests/utf8.pl
 * repair  test/demo  scripts  still using "vxt-" prefix, some cleanup
   with shellcheck.
 * enable page-number for DECXCPR response in VT330.
 * amend  change for combining characters in patch #371 to limit it to
   the currently-defined codes (report by Thomas Wolff).
 * add  directory-template  parameter  to  mktemp  in shell-scripts to
   improve portability to older systems (patch by Ryan Schmidt).
 * mention webpage XTerm – bracketed-paste in ctlseqs.ms
 * update   manual-page   descriptions   for   allowPasteControls  and
   disallowedPasteControls (patch #363).
 * further  extended list of environment variables to purge on startup
   (suggested by Thomas Wolff).
 * update config.guess, config.sub


-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Re: [Lynx-dev] help

[Thomas Dickey]

On Sat, Sep 24, 2022 at 11:24:10AM -0400, ww ww wrote:
> Using Lynx for DOS...
> 
> it says: "Looking up lynx.browser.org"
> 
> then, "Alert!  unable to connect to remote host."
> 
> then, "lynx: Can't access startfile http://lynx.browser.org/;

lynx.browser.org appears to be still there (out of date...)
 
regarding - "Lynx for DOS" - I suppose you'd have to ask its packager/whatever

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Re: [Lynx-dev] TLS 1.2

[Thomas Dickey]

On Wed, Sep 21, 2022 at 05:28:55AM +, Wilson Chan via Lynx-dev wrote:
> Hi there,
> 
> Hope you are doing fine.
> We are currently using Lynx 2.8.7rel.1 (05 Jul 2009).

The current stable release is 2.8.8 (July 2018), and
the development version is 2.9.0dev.10 (October 2021).

> When Lynx visits our website, it gives us error "Alert!: Unable to make 
> secure connection to remote host."
> We use Digicert and have only TLS 1.2 enabled.
> Is TLS 1.2 not supported by version 2.8.7rel.1?
> Which version of Lynx should we use to be able to verify TLS 1.2?

I'd start with the stable release (some external configuration details
may require the development version).
 
> Appreciate your attention.
> 
> Best Regards,
> Wilson

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

update libXft to 2.3.6

[Thomas Dickey]

The release monitoring project for libXft 
(https://release-monitoring.org/project/1777/)
doesn't appear to have noticed the release of 2.3.6 a week ago.
Any clues on how to fix this?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[ANNOUNCE] libXft 2.3.6

[Thomas Dickey]

Adam Sampson (1):
  Fix length check in XftTextExtents*.

Alan Coopersmith (3):
  Build xz tarballs instead of bzip2
  Fix spelling/wording issues
  gitlab CI: add a basic build test

Maxime Coste (3):
  Introduce a _XftCompositeString helper function
  Introduce a _XftCompositeText helper function
  Add support for BGRA glyphs display and scaling

Thomas E. Dickey (54):
  quiet unused-parameter warnings with _X_UNUSED
  cleanup warnings about discarding const
  fix missing-initializer warning
  promote font->num_glyphs to FT_UInt or Glyph to fix warnings
  quiet warnings with casts
  change the internal memory-allocator to use size_t
  quiet compiler warning with cast
  quiet compiler warning with cast
  formatting fix, for clarity (no object change)
  fix warnings by gcc 11; check if length <= zero
  reuse macros from Xcursor.man to fix ragged layout of typedefs and 
prototypes
  corrected prototypes in manpage, matching Xft.h
  install man-aliases for all of the exported symbols
  cleanup manpage comments
  amend rule for creating manpage aliases
  initial draft of initialization-functions documentation
  consistently bold "Xft"
  change data-types to subsections to help with readability
  add overview for text-extents section
  document XftFontOpenXlfd and XftXlfdParse
  move prototype for XftNameUnparse to Xft.h
  remove remaining internal prototypes for obsolete xftcompat.c
  add section on manipulating font patterns
  add section on manipulating font data
  document the clipping-functions
  reduce clutter for external data-types by documenting them one time
  document XftGlyphFontSpecRender() and related functions.
  add a table of the "families" of functions
  add a section on the XFT_DEBUG environment variable
  add section of functions managing XftColor
  add debugging trace for XftDefaultSet()
  reduce clutter with macros for allocating arrays
  add "trackmemusage" property to use in improved _XftFontUncacheGlyph
  add option for tracking glyph memory-usage on a linked list
  validate linked-list updates with _XftValidateGlyphUsage
  refactor _XftFontUncacheGlyph, separate the two types of loop for 
readability
  add asserts (to help with debugging), update copyright notices
  fix delinkage of last glyph in font, improve debug-trace
  cppcheck/gcc-stricter warnings about printf-formats and operator 
precedence
  when tracking glyph memory usage, unload the oldest glyph rather than 
randomly
  improve glyph management by relinking to unload least-recently used glyphs
  document new features for glyph memory-tracking
  errata (cppcheck, clang --analyze, manpage credit)
  build-fix for c89
  cleanup new compiler warnings
  merge changes by Christian Werner
  build-fix
  fix new gcc warnings
  add a null-pointer check
  update copyright notice
  libXft 2.3.5
  revised fix for gcc 12 compiler warnings in xftextent.c
  fix gcc12 warning about malloc size
  libXft 2.3.6

git tag: libXft-2.3.6

https://xorg.freedesktop.org/archive/individual/lib/libXft-2.3.6.tar.gz
SHA256: b7e59f69e0bbabe9438088775f7e5a7c16a572e58b11f9722519385d38192df5  
libXft-2.3.6.tar.gz
SHA512: 
291bec2cc297a6e39baff5c2dec37017f37f97b438468a6d6b66f496a9987936da6ee2e3ace77e4527d8c5fd09e1dd731b2f042fa74880f667b8a03a913512d2
  libXft-2.3.6.tar.gz
PGP:  
https://xorg.freedesktop.org/archive/individual/lib/libXft-2.3.6.tar.gz.sig

https://xorg.freedesktop.org/archive/individual/lib/libXft-2.3.6.tar.xz
SHA256: 60a6e7319fc938bbb8d098c9bcc86031cc2327b5d086d3335fc5c76323c03022  
libXft-2.3.6.tar.xz
SHA512: 
732f8c635fcac6010012ba8c10c23d2dd6ec79b0f096d6bcc9b7e36d2ca0817387faa7ee5bb6f43cff02adc68e4234c1b8f95021ebc548f61c492e0b76836d90
  libXft-2.3.6.tar.xz
PGP:  
https://xorg.freedesktop.org/archive/individual/lib/libXft-2.3.6.tar.xz.sig

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

[ANNOUNCE] libXft 2.3.6

[Thomas Dickey]

Adam Sampson (1):
  Fix length check in XftTextExtents*.

Alan Coopersmith (3):
  Build xz tarballs instead of bzip2
  Fix spelling/wording issues
  gitlab CI: add a basic build test

Maxime Coste (3):
  Introduce a _XftCompositeString helper function
  Introduce a _XftCompositeText helper function
  Add support for BGRA glyphs display and scaling

Thomas E. Dickey (54):
  quiet unused-parameter warnings with _X_UNUSED
  cleanup warnings about discarding const
  fix missing-initializer warning
  promote font->num_glyphs to FT_UInt or Glyph to fix warnings
  quiet warnings with casts
  change the internal memory-allocator to use size_t
  quiet compiler warning with cast
  quiet compiler warning with cast
  formatting fix, for clarity (no object change)
  fix warnings by gcc 11; check if length <= zero
  reuse macros from Xcursor.man to fix ragged layout of typedefs and 
prototypes
  corrected prototypes in manpage, matching Xft.h
  install man-aliases for all of the exported symbols
  cleanup manpage comments
  amend rule for creating manpage aliases
  initial draft of initialization-functions documentation
  consistently bold "Xft"
  change data-types to subsections to help with readability
  add overview for text-extents section
  document XftFontOpenXlfd and XftXlfdParse
  move prototype for XftNameUnparse to Xft.h
  remove remaining internal prototypes for obsolete xftcompat.c
  add section on manipulating font patterns
  add section on manipulating font data
  document the clipping-functions
  reduce clutter for external data-types by documenting them one time
  document XftGlyphFontSpecRender() and related functions.
  add a table of the "families" of functions
  add a section on the XFT_DEBUG environment variable
  add section of functions managing XftColor
  add debugging trace for XftDefaultSet()
  reduce clutter with macros for allocating arrays
  add "trackmemusage" property to use in improved _XftFontUncacheGlyph
  add option for tracking glyph memory-usage on a linked list
  validate linked-list updates with _XftValidateGlyphUsage
  refactor _XftFontUncacheGlyph, separate the two types of loop for 
readability
  add asserts (to help with debugging), update copyright notices
  fix delinkage of last glyph in font, improve debug-trace
  cppcheck/gcc-stricter warnings about printf-formats and operator 
precedence
  when tracking glyph memory usage, unload the oldest glyph rather than 
randomly
  improve glyph management by relinking to unload least-recently used glyphs
  document new features for glyph memory-tracking
  errata (cppcheck, clang --analyze, manpage credit)
  build-fix for c89
  cleanup new compiler warnings
  merge changes by Christian Werner
  build-fix
  fix new gcc warnings
  add a null-pointer check
  update copyright notice
  libXft 2.3.5
  revised fix for gcc 12 compiler warnings in xftextent.c
  fix gcc12 warning about malloc size
  libXft 2.3.6

git tag: libXft-2.3.6

https://xorg.freedesktop.org/archive/individual/lib/libXft-2.3.6.tar.gz
SHA256: b7e59f69e0bbabe9438088775f7e5a7c16a572e58b11f9722519385d38192df5  
libXft-2.3.6.tar.gz
SHA512: 
291bec2cc297a6e39baff5c2dec37017f37f97b438468a6d6b66f496a9987936da6ee2e3ace77e4527d8c5fd09e1dd731b2f042fa74880f667b8a03a913512d2
  libXft-2.3.6.tar.gz
PGP:  
https://xorg.freedesktop.org/archive/individual/lib/libXft-2.3.6.tar.gz.sig

https://xorg.freedesktop.org/archive/individual/lib/libXft-2.3.6.tar.xz
SHA256: 60a6e7319fc938bbb8d098c9bcc86031cc2327b5d086d3335fc5c76323c03022  
libXft-2.3.6.tar.xz
SHA512: 
732f8c635fcac6010012ba8c10c23d2dd6ec79b0f096d6bcc9b7e36d2ca0817387faa7ee5bb6f43cff02adc68e4234c1b8f95021ebc548f61c492e0b76836d90
  libXft-2.3.6.tar.xz
PGP:  
https://xorg.freedesktop.org/archive/individual/lib/libXft-2.3.6.tar.xz.sig

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

[ANNOUNCE] libXft 2.3.5

[Thomas Dickey]

Alan Coopersmith (3):
  Build xz tarballs instead of bzip2
  Fix spelling/wording issues
  gitlab CI: add a basic build test

Maxime Coste (3):
  Introduce a _XftCompositeString helper function
  Introduce a _XftCompositeText helper function
  Add support for BGRA glyphs display and scaling

Thomas E. Dickey (51):
  quiet unused-parameter warnings with _X_UNUSED
  cleanup warnings about discarding const
  fix missing-initializer warning
  promote font->num_glyphs to FT_UInt or Glyph to fix warnings
  quiet warnings with casts
  change the internal memory-allocator to use size_t
  quiet compiler warning with cast
  quiet compiler warning with cast
  formatting fix, for clarity (no object change)
  fix warnings by gcc 11; check if length <= zero
  reuse macros from Xcursor.man to fix ragged layout of typedefs and 
prototypes
  corrected prototypes in manpage, matching Xft.h
  install man-aliases for all of the exported symbols
  cleanup manpage comments
  amend rule for creating manpage aliases
  initial draft of initialization-functions documentation
  consistently bold "Xft"
  change data-types to subsections to help with readability
  add overview for text-extents section
  document XftFontOpenXlfd and XftXlfdParse
  move prototype for XftNameUnparse to Xft.h
  remove remaining internal prototypes for obsolete xftcompat.c
  add section on manipulating font patterns
  add section on manipulating font data
  document the clipping-functions
  reduce clutter for external data-types by documenting them one time
  document XftGlyphFontSpecRender() and related functions.
  add a table of the "families" of functions
  add a section on the XFT_DEBUG environment variable
  add section of functions managing XftColor
  add debugging trace for XftDefaultSet()
  reduce clutter with macros for allocating arrays
  add "trackmemusage" property to use in improved _XftFontUncacheGlyph
  add option for tracking glyph memory-usage on a linked list
  validate linked-list updates with _XftValidateGlyphUsage
  refactor _XftFontUncacheGlyph, separate the two types of loop for 
readability
  add asserts (to help with debugging), update copyright notices
  fix delinkage of last glyph in font, improve debug-trace
  cppcheck/gcc-stricter warnings about printf-formats and operator 
precedence
  when tracking glyph memory usage, unload the oldest glyph rather than 
randomly
  improve glyph management by relinking to unload least-recently used glyphs
  document new features for glyph memory-tracking
  errata (cppcheck, clang --analyze, manpage credit)
  build-fix for c89
  cleanup new compiler warnings
  merge changes by Christian Werner
  build-fix
  fix new gcc warnings
  add a null-pointer check
  update copyright notice
  libXft 2.3.5

git tag: libXft-2.3.5

https://xorg.freedesktop.org/archive/individual/lib/libXft-2.3.5.tar.gz
SHA256: f7324aa0664115223672bae55086f3a9ae8f6ad4cdca87a8dd620295ee459e1a  
libXft-2.3.5.tar.gz
SHA512: 
133165115bf8220cd76c72a6c8b2785e08626243a2eab015a3f76bdad302c41dafd2996299b8a5d13754aef214c4527e0f72f6975a00227269885fe53248031b
  libXft-2.3.5.tar.gz
PGP:  
https://xorg.freedesktop.org/archive/individual/lib/libXft-2.3.5.tar.gz.sig

https://xorg.freedesktop.org/archive/individual/lib/libXft-2.3.5.tar.xz
SHA256: 684fd6ec83db80b391b8111f604d9225772b26bb78bba261d77a5eaddab6a1ee  
libXft-2.3.5.tar.xz
SHA512: 
e1e037dbc4f8bbf8204bdf99a199c82b5f1182875d28bd9f0a4ec2aec95b05de21e97029ec036b9a3f70f1d6e8a42f0052f4ab30809aee7411fa2e438899db9e
  libXft-2.3.5.tar.xz
PGP:  
https://xorg.freedesktop.org/archive/individual/lib/libXft-2.3.5.tar.xz.sig

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

[ANNOUNCE] libXft 2.3.5

[Thomas Dickey]

Alan Coopersmith (3):
  Build xz tarballs instead of bzip2
  Fix spelling/wording issues
  gitlab CI: add a basic build test

Maxime Coste (3):
  Introduce a _XftCompositeString helper function
  Introduce a _XftCompositeText helper function
  Add support for BGRA glyphs display and scaling

Thomas E. Dickey (51):
  quiet unused-parameter warnings with _X_UNUSED
  cleanup warnings about discarding const
  fix missing-initializer warning
  promote font->num_glyphs to FT_UInt or Glyph to fix warnings
  quiet warnings with casts
  change the internal memory-allocator to use size_t
  quiet compiler warning with cast
  quiet compiler warning with cast
  formatting fix, for clarity (no object change)
  fix warnings by gcc 11; check if length <= zero
  reuse macros from Xcursor.man to fix ragged layout of typedefs and 
prototypes
  corrected prototypes in manpage, matching Xft.h
  install man-aliases for all of the exported symbols
  cleanup manpage comments
  amend rule for creating manpage aliases
  initial draft of initialization-functions documentation
  consistently bold "Xft"
  change data-types to subsections to help with readability
  add overview for text-extents section
  document XftFontOpenXlfd and XftXlfdParse
  move prototype for XftNameUnparse to Xft.h
  remove remaining internal prototypes for obsolete xftcompat.c
  add section on manipulating font patterns
  add section on manipulating font data
  document the clipping-functions
  reduce clutter for external data-types by documenting them one time
  document XftGlyphFontSpecRender() and related functions.
  add a table of the "families" of functions
  add a section on the XFT_DEBUG environment variable
  add section of functions managing XftColor
  add debugging trace for XftDefaultSet()
  reduce clutter with macros for allocating arrays
  add "trackmemusage" property to use in improved _XftFontUncacheGlyph
  add option for tracking glyph memory-usage on a linked list
  validate linked-list updates with _XftValidateGlyphUsage
  refactor _XftFontUncacheGlyph, separate the two types of loop for 
readability
  add asserts (to help with debugging), update copyright notices
  fix delinkage of last glyph in font, improve debug-trace
  cppcheck/gcc-stricter warnings about printf-formats and operator 
precedence
  when tracking glyph memory usage, unload the oldest glyph rather than 
randomly
  improve glyph management by relinking to unload least-recently used glyphs
  document new features for glyph memory-tracking
  errata (cppcheck, clang --analyze, manpage credit)
  build-fix for c89
  cleanup new compiler warnings
  merge changes by Christian Werner
  build-fix
  fix new gcc warnings
  add a null-pointer check
  update copyright notice
  libXft 2.3.5

git tag: libXft-2.3.5

https://xorg.freedesktop.org/archive/individual/lib/libXft-2.3.5.tar.gz
SHA256: f7324aa0664115223672bae55086f3a9ae8f6ad4cdca87a8dd620295ee459e1a  
libXft-2.3.5.tar.gz
SHA512: 
133165115bf8220cd76c72a6c8b2785e08626243a2eab015a3f76bdad302c41dafd2996299b8a5d13754aef214c4527e0f72f6975a00227269885fe53248031b
  libXft-2.3.5.tar.gz
PGP:  
https://xorg.freedesktop.org/archive/individual/lib/libXft-2.3.5.tar.gz.sig

https://xorg.freedesktop.org/archive/individual/lib/libXft-2.3.5.tar.xz
SHA256: 684fd6ec83db80b391b8111f604d9225772b26bb78bba261d77a5eaddab6a1ee  
libXft-2.3.5.tar.xz
SHA512: 
e1e037dbc4f8bbf8204bdf99a199c82b5f1182875d28bd9f0a4ec2aec95b05de21e97029ec036b9a3f70f1d6e8a42f0052f4ab30809aee7411fa2e438899db9e
  libXft-2.3.5.tar.xz
PGP:  
https://xorg.freedesktop.org/archive/individual/lib/libXft-2.3.5.tar.xz.sig

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Re: how to update rpms/vile?

[Thomas Dickey]

thanks - I'll use this information
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

how to update rpms/vile?

[Thomas Dickey]

I'm the upstream developer/maintainer for vile (vi like emacs) and a few other 
programs packaged in Fedora.
The vile rpm is a couple of years out of date, now, and I don't see recent 
activity by the package maintainer.

What can I do to get it moving again?

(Earlier this year, I restored a couple that had been orphaned, but that isn't 
the current state for vile). 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [Update] editors/vile: 9.8y -> 9.8w

[Thomas Dickey]

Attached is an update for editors/vile.  From 9.8u to 9.8w.

Changes are summarized here:

https://invisible-island.net/vile/CHANGES.html#v9_8w

This update also amends the existing port to work better on OpenBSD:

a) use built-in syntax filters, workaround for OpenBSD permissions

b) use curses rather than terminfo, also needed with OpenBSD

c) workaround for configure check for crypt

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net
diff --git a/editors/vile/Makefile b/editors/vile/Makefile
index 140abb74199..987fecf5566 100644
--- a/editors/vile/Makefile
+++ b/editors/vile/Makefile
@@ -1,5 +1,5 @@
 COMMENT=		VI Editor Like Emacs
-DISTNAME=		vile-9.8u
+DISTNAME=		vile-9.8w
 CATEGORIES=		editors
 HOMEPAGE=		https://invisible-island.net/vile/
 
@@ -8,13 +8,14 @@ PERMIT_PACKAGE=	Yes
 
 WANTLIB +=	c curses iconv
 
-MASTER_SITES=		https://invisible-mirror.net/archives/vile/current/ \
-			ftp://ftp.invisible-island.net/vile/current/ \
-			ftp://dickey.his.com/vile/current/
+MASTER_SITES=		https://invisible-island.net/archives/vile/current/ \
+			https://invisible-mirror.net/archives/vile/current/ \
+			ftp://ftp.invisible-island.net/vile/current/
 
 EXTRACT_SUFX=	.tgz
 
 CONFIGURE_STYLE=gnu
+CONFIGURE_ARGS+=	--with-builtin-filters --with-screen=ncursesw
 CONFIGURE_ENV=	LDFLAGS="-L${LOCALBASE}/lib" \
 		CPPFLAGS="-I${LOCALBASE}/include"
 
diff --git a/editors/vile/distinfo b/editors/vile/distinfo
index b8e910401fa..43143123837 100644
--- a/editors/vile/distinfo
+++ b/editors/vile/distinfo
@@ -1,2 +1,2 @@
-SHA256 (vile-9.8u.tgz) = MagoM/5P71pgBDvMMnjRqHWhAosbJXfJ4Po6F5z/Fl4=
-SIZE (vile-9.8u.tgz) = 2375989
+SHA256 (vile-9.8w.tgz) = eCU+w/euX0+dR5mjyLw1uFtH1FbyrBcoEACKSORgmBU=
+SIZE (vile-9.8w.tgz) = 2407322
diff --git a/editors/vile/patches/patch-crypt b/editors/vile/patches/patch-crypt
new file mode 100644
index 000..b2962a289c5
--- /dev/null
+++ b/editors/vile/patches/patch-crypt
@@ -0,0 +1,72 @@
+--- configure.orig	Sat Aug 20 15:48:11 2022
 configure	Thu Aug 25 14:05:32 2022
+@@ -27603,8 +27603,8 @@
+ 		;;
+ 	(*)
+ 
+-echo "$as_me:27606: checking for crypt function" >&5
+-echo $ECHO_N "checking for crypt function... $ECHO_C" >&6
++echo "$as_me:27606: checking for broken_crypt function" >&5
++echo $ECHO_N "checking for broken_crypt function... $ECHO_C" >&6
+ if test "${cf_cv_crypt_func+set}" = set; then
+   echo $ECHO_N "(cached) $ECHO_C" >&6
+ else
+@@ -27617,7 +27617,7 @@
+ int
+ main (void)
+ {
+-crypt()
++broken_crypt()
+   ;
+   return 0;
+ }
+@@ -27649,7 +27649,7 @@
+ int
+ main (void)
+ {
+-crypt()
++broken_crypt()
+   ;
+   return 0;
+ }
+@@ -27686,8 +27686,8 @@
+ if test "$cf_cv_crypt_func" != no ; then
+ 	cf_save_LIBS="$LIBS"
+ 	test "$cf_cv_crypt_func" != yes && LIBS="$cf_cv_crypt_func $LIBS"
+-echo "$as_me:27689: checking if crypt works" >&5
+-echo $ECHO_N "checking if crypt works... $ECHO_C" >&6
++echo "$as_me:27689: checking if broken_crypt works" >&5
++echo $ECHO_N "checking if broken_crypt works... $ECHO_C" >&6
+ if test "${cf_cv_crypt_works+set}" = set; then
+   echo $ECHO_N "(cached) $ECHO_C" >&6
+ else
+@@ -27701,9 +27701,9 @@
+ #include "confdefs.h"
+ 
+ #include 
+-extern char *crypt();
++extern char *broken_crypt();
+ int main(void) {
+-	char *s = crypt("vi-crypt", "vi");
++	char *s = broken_crypt("vi-crypt", "vi");
+ 	${cf_cv_main_return:-return}(strcmp("vi6r2tczBYLvM", s) != 0);
+ }
+ 
+@@ -28114,7 +28114,7 @@
+ _nc_free_tinfo \
+ access \
+ alarm \
+-crypt \
++broken_crypt \
+ getcwd \
+ getegid \
+ geteuid \
+@@ -32763,7 +32763,7 @@
+ atoi \
+ chdir \
+ close \
+-crypt \
++broken_crypt \
+ dup \
+ execlp \
+ fclose \
diff --git a/editors/vile/pkg/PLIST b/editors/vile/pkg/PLIST
index acc4f58beb2..c10f971582a 100644
--- a/editors/vile/pkg/PLIST
+++ b/editors/vile/pkg/PLIST
@@ -6,89 +6,8 @@ lib/vile/
 @bin lib/vile/atr2ansi
 @bin lib/vile/atr2html
 @bin lib/vile/atr2text
-@bin lib/vile/vile-ada-filt
-@bin lib/vile/vile-as-filt
-@bin lib/vile/vile-asm-filt
-@bin lib/vile/vile-au3-filt
-@bin lib/vile/vile-awk-filt
-@bin lib/vile/vile-basic-filt
-@bin lib/vile/vile-bat-filt
-@bin lib/vile/vile-bnf-filt
-@bin lib/vile/vile-c-filt
-@bin lib/vile/vile-cfg-filt
-@bin lib/vile/vile-conf-filt
 @bin lib/vile/vile-crypt
-@bin lib/vile/vile-css-filt
-@bin lib/vile/vile-cweb-filt
-@bin lib/vile/vile-dcl-filt
-@bin lib/vile/vile-def-filt
-@bin lib/vile/vile-diff-filt
-@bin lib/vile/vile-ecl-filt
-@bin lib/vile/vile-erl-filt
-@bin lib/vile/vile-esql-filt
-@bin lib/vile/vile-est-filt
-@bin lib/vile/vile-fdl-filt
-@bin lib/vile/vile-hs-filt
-@bin lib/vile/vile-html-filt
-@bin lib/vile/vile-imake-filt
-@bin lib/vile/vile-info-filt
-@bin lib/vile/vile-ini-filt
-@bin lib/vile/vile-iss-filt
-@bin lib/vile/vile-json-filt
-@bin lib/vile/vile-key-filt
-@bin lib/vile/vile-latex-filt
-@bin lib/vile/vile-lex-filt
-@bin lib/vile/vile-lisp-filt
-@bin lib/vile/vile-lua-filt
-@bin lib/vile/vile-m4-filt
-@bin lib/vile/vile-mail-filt
-@bin lib/vile/vile-mailcap-filt
-@bin 

[Update] editors/vile: 9.8y -> 9.8w

[Thomas Dickey]

Attached is an update for editors/vile.  From 9.8u to 9.8w.

Changes are summarized here:

https://invisible-island.net/vile/CHANGES.html#v9_8w

This update also amends the existing port to work better on OpenBSD:

a) use built-in syntax filters, workaround for OpenBSD permissions

b) use curses rather than terminfo, also needed with OpenBSD

c) workaround for configure check for crypt

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Re: package/freebsd/*vile content is for 9.8v rather than for 9.8w

[Thomas Dickey]

On Mon, Aug 22, 2022 at 04:09:17PM -0400, Thomas Dickey wrote:
> On Mon, Aug 22, 2022 at 01:48:21PM +0200, Gary Jennejohn wrote:
> > I tried to build {,x}vile9.8w for FreeBSD using what's under 
> > package/freebsd,
> > but all the files are for 9.8v.
> > 
> > This would be trivial to fix, but what's missing are the correct
> > TIMESTAMPs for the distfiles and I'm not sure how to get them.
> > 
> > The size is known and SHA256 values I can generate myself.
> 
> yes - I know about that, but hadn't found a nicer solution.
> 
> I use that particular set of files for testing after an update
> (and to help check if there's some change to the makefile
> that I should account for).
> 
> Since they're part of the release tarball, it's not possible to have the
> sha256's match.  Generally I update the distinfo using make(whatever) in
> the ports tree, and make packages for myself.

make makesum

(it's hard to remember because different package systems use different
commands)
 
> > Note that I at one time was the FreeBSD maintainer of vile and xvile,
> > so I know how things should work.
> 
> I'm currently the maintainer for those packages - but have to check on
> how moving to Git has changed the procedure :-)
> 
> I started updating the MacPorts file this morning (not exactly the maintainer,
> but made the last update).

done...
 
> Over the next day or so, I'll be updating that stuff (unless someone else
> gets there first).

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265996

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

ANN: vile-9.8w

[Thomas Dickey]

Files:
  https://invisible-island.net/archives/vile/current/vile-9.8w.tgz
  https://invisible-island.net/archives/vile/current/vile-9.8w.tgz.asc
  https://invisible-island.net/archives/vile/patches/MD5sums
  https://invisible-island.net/archives/vile/patches/vile-9.8w.patch.gz
  https://invisible-island.net/archives/vile/patches/vile-9.8w.patch.gz.asc
  https://invisible-island.net/archives/vile/patches/vile-9.8w.patch.gz

 patch by Thomas E. Dickey 
 created  Mon Aug 22 01:05:58 UTC 2022
 --
 CHANGES|   30 
 MANIFEST   |8 
 aclocal.m4 |   42 
 basic.c|4 
 configure  | 3353 +++
 display.c  |4 
 doc/vile-hlp.html  |4 
 doc/vile-toc.html  |4 
 estruct.h  |4 
 eval.c |4 
 file.c |   12 
 filters/genmake.mak|5 
 filters/imakeflt.l |7 
 filters/makefilt.l |7 
 filters/manfilt.c  |   67 
 filters/sh-filt.l  |   14 
 filters/spellflt.l |   11 
 filters/vilefilt.l |4 
 history.c  |   14 
 input.c|7 
 insert.c   |   51 
 line.c |   14 
 macros/UXVile.ad   |6 
 macros/XVile.ad|4 
 macros/manpage.rc  |   13 
 macros/modes.rc|   21 
 main.c |4 
 makefile.in|5 
 map.c  |   56 
 mktbls.c   |   14 
 ntwinio.c  |4 
 package/convile.nsi|8 
 package/debian/changelog   |6 
 package/freebsd/vile/Makefile  |2 
 package/freebsd/vile/distinfo  |6 
 package/freebsd/xvile/Makefile |1 
 package/freebsd/xvile/distinfo |6 
 package/minvile.nsi|8 
 package/vile.spec  |   10 
 package/winvile.iss|4 
 package/winvile.nsi|6 
 patchlev.h |4 
 perl.xs|7 
 plink.sh   |   11 
 proto.h|8 
 random.c   |4 
 regexp.c   |   32 
 region.c   |4 
 revlist|  118 -
 tcap.c |8 
 vile-9.8w/filters/md-filt.l|  616 +++
 vile-9.8w/filters/md.key   |1 
 vile-9.8w/filters/raku.key |2 
 vile-9.8w/filters/rakufilt.c   | 1672 +++
 vile.hlp   |6 
 w32cbrd.c  |4 
 w32info.rc |   12 
 w32ole.cpp |6 
 wvwrap.cpp |6 
 xterm.c|4 
 60 files changed, 4466 insertions(+), 1913 deletions(-)
 --
 Please remove the following files before applying this patch.
 (You can feed this patch to 'sh' to do so.)

rm -f filters/perl6.key
rm -f filters/pl6filt.c
rm -f revlist.bak
exit


 20220821 (w)
> Brendan O'Dea:
+ the font specification in /etc/X11/app-defaults/UXVile was being
  overridden by the one in XVile.  Additionally update the xvile font
  to use the Latin-1 equivalent (9x18 instead of 8x13).
+ apply memory-leak fix from pl-filt.c in 9.8v to pl6filt.c
+ rename perl6mode and corresponding syntax filter to "raku" (report by
  Steve Lembark).
+ update suffix-list for rakumode.
> Tom Dickey:
+ portability-fixes for plink.sh
+ fixes for regexp.c:
  + build-fix for test_regexp
  + add parentheses in non-multibyte is_CLASS() macro to correct a
problem with pointer expressions.
  + add I/i toggle in test_regexp to exercise ignorecase.
+ revise change for lins_chars() to handle UTF-8 in scripts, as that
  interfered with normal insertions (report by Chris Green).
+ fix a check in vile-manfilt, to ensure that stepping into previous
  lines does not use flushed/discarded rows.
+ build-fix for perl 5.36 (Debian #1014289)
+ modify error-message from vile-manfilt to show the program name.
+ fix a state-transition in sh-filt.l, which left some text uncolored
  (report by Wayne Cuddy).
+ add markdown mode (mdmode).
+ update copyright dates
+ update package/freebsd/*
+ fix some issues found with Coverity.
+ fix a few compiler-warnings.

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Re: Leak in XKeysymToString

[Thomas Dickey]

On Sat, Aug 20, 2022 at 09:51:42AM -0700, Alan Coopersmith wrote:
> Thanks - while gitlab is our preferred method, when that's not possible,
> we prefer using the xorg-devel mailing list (cc'ed) instead of trying to
> guess which individual developer to contact.
> 
> This bug has been previously reported, but no one has developed a good
> fix yet - I don't know if many XKeysymToString callers keep references to
> the returned pointers and would be broken if those pointers suddenly had a
> different string or were invalid due to a realloc() call.

The manpage hints that callers should make a copy of the string,
since that "static area" implies that the library overwrites the
data for each call:

   The returned string is in a static area and must not be modified.  The
   returned string is in the Host Portable Character Encoding.  If the
   specified KeySym is not defined, XKeysymToString returns a NULL.

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Re: [PATCH] Fix build failure with Perl 5.36

[Thomas Dickey]

On Tue, Aug 09, 2022 at 06:44:58PM -0700, Kevin Buettner wrote:
> On Mon, 4 Jul 2022 15:12:27 +1000
> Brendan O'Dea  wrote:
> 
> > Fix a build failure for Perl 5.36 caused by a namespace conflict of
> > the symbol `regexp' (http://bugs.debian.org/1014289).
> 
> I've tested this fix on my (Fedora) rawhide machine.  It works for me.

sounds good (same here).  I have most of 9.8w done, except for finishing
the markdown-highlighter that I began.  I might complete that today.

See this for other fixes:

https://github.com/ThomasDickey/vile-snapshots

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Re: [Lynx-dev] lynx blinking after terminal window resizing

[Thomas Dickey]

On Tue, Aug 02, 2022 at 10:37:46PM +, Thorsten Glaser wrote:
> Thomas Dickey dixit:
> 
> >> I see it on Debian stable/bullseye, for example.
> >
> >I still don't see it with this combination.
> 
> Huh.
> 
> >The blinking that you're describing would be full-screen repainting.
> 
> Yes. I can verify that it does that in a typescript (attached).

I see - it requires a slow connection to reproduce this.

Just turning the code off isn't a fix; the variable that's
used to remember that there's a recent size-change has to be reset
(and retested :-)

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Re: [Lynx-dev] lynx blinking after terminal window resizing

[Thomas Dickey]

On Mon, Aug 01, 2022 at 10:19:17PM +, Thorsten Glaser wrote:
> Thomas Dickey dixit:
> 
> >On Sun, Jun 12, 2022 at 03:16:40AM +0300, mark zaharov wrote:
> >> here is the solution which my friend provides. He said it works well with 
> >> slang and this bug exists for ncurces only.
> 
> Huh, I didn’t get that mail.
> 
> >Perhaps this would be reproducible if the version of lynx were identified,
> >as well as which platform.  I don't see it using
> > - xterm 372,
> > - ncurses 6.1 and 6.3,
> > - lynx 2.8.9rel.1 and 2.9.0dev.10
> 
> I see it on Debian stable/bullseye, for example.

I still don't see it with this combination.  The blinking that you're
describing would be full-screen repainting.  When I resize the screen and
press ^R, subsequent cursor movement is only updating the expected
link-highlighting characters.

Perhaps it's something in your lynx configuration which is relevant.
In my check, I used a test account which doesn't customize anything.

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Re: UTF8 has stopped working in vile after OS upgrade

[Thomas Dickey]

On Tue, Aug 02, 2022 at 03:23:26PM +1000, Brendan O'Dea wrote:
> OK, so this appears to have been caused by the change:
> 
>   "modify lins_chars() to handle a case where a script inserts a UTF-8
> character (report by Thomas Dupond)."
> 
> lins_chars is being invoked with wide=0, and is working for codepoints >=
> 256 (which is why ę works, and £ does not).

yes...  the change can probably be made to work as intended by accounting
for whether lins_chars is called from a script or interactively by adding
the clexec variable to the check, e.g.

if ((!clexec || !global_is_utfXX()) && (c > 127) && b_is_utfXX(curbp)) {

though the code has changed, and that's untested :-)

I'll investigate that over the next day or so.
 
> I've pushed a rollback of that change to Debian as 0d1f060a.  Relevant
> patch attached.
> 
> --bod
> 
> On Sat, 30 Jul 2022 at 00:00, Chris Green  wrote:
> 
> > On Fri, Jul 29, 2022 at 04:27:05AM -0400, Thomas Dickey wrote:
> > > On Fri, Jul 29, 2022 at 03:40:12PM +1000, Brendan O'Dea wrote:
> > > > Testing the vile 9.8v-2 package on my Debian machine I get some
> > decidedly
> > > > odd behaviour:
> > > >
> > > > The following sequence:
> > > >
> > > >   l- e' c,
> > > >
> > > > is rendered in vile as:
> > > >
> > > >   \?A3\?E9\?E7
> > > >
> > > > outside of vile, in the same terminal that appears fine:
> > > >
> > > >   Łéç
> > > >
> > > > which would suggest that vile doesn't handle UTF-8 at all, although as
> > > > Chris noted, entering those three characters using C-v x  works
> > fine,
> > > > and renders in vile correctly.
> > >
> > > hmm - with some time, I can bisect to pinpoint the problem.
> > >
> > > (pasting outside of 0..255 seems ok)
> > >
> > Weirdly I find that using the vile defined 'compose' key *does* work
> > for accented characters, but using the default 'compose' key (as
> > defined in .Xmodmap) it doesn't work.
> >
> > I.e. I have "source digraphs.rc" in my .vilerc file as follows:-
> >
> > ;
> > ;
> > ; Set up ^K as 'compose' key for accented characters
> > ;
> > source digraphs.rc
> >
> > ... and, rather to my surprise, when I entered ^ke' I got an e with an
> > accute accent.  I rarely (if ever) use this in vile, I'd really
> > forgotten it was there.  It doesn't work for a pound sign though (^kl=).
> >
> > --
> > Chris Green
> >
> >

> diff --git a/insert.c b/insert.c
> index 645c05d..158ad0e 100644
> --- a/insert.c
> +++ b/insert.c
> @@ -446,7 +446,7 @@ replacechar(int f, int n)
>   if (isbackspace(c)) {   /* vi beeps here */
>   s = TRUE;   /* replaced with nothing */
>   } else {
> - t = s = lins_chars(n, c, FALSE);
> + t = s = lins_chars(n, c);
>   }
>   }
>   }
> @@ -981,11 +981,11 @@ inschar(int c, int *backsp_limit_p)
>   rc = inspound();
>   } else {
>   autoindented = -1;
> - rc = lins_chars(1, c, FALSE);
> + rc = lins_chars(1, c);
>   }
>   } else {
>   autoindented = -1;
> - rc = lins_chars(1, c, FALSE);
> + rc = lins_chars(1, c);
>   }
>  }
>  return rc;
> @@ -1515,7 +1515,7 @@ quote_next(int f, int n)
>   s = lnewline();
>   } while ((s == TRUE) && (--n != 0));
>   } else {
> - s = lins_chars(n, c, TRUE);
> + s = lins_chars(n, c);
>   }
>  }
>  return s;
> diff --git a/line.c b/line.c
> index d56a6f6..bd5b8a5 100644
> --- a/line.c
> +++ b/line.c
> @@ -534,7 +534,7 @@ lins_bytes(int n, int c)
>   * or in insert-mode.
>   */
>  int
> -lins_chars(int n, int c, int wide)
> +lins_chars(int n, int c)
>  {
>  int rc = FALSE;
>  UCHAR target[10];
> @@ -542,7 +542,7 @@ lins_chars(int n, int c, int wide)
>  int nn;
>  int mapped;
>  
> -if (wide && (c > 127) && b_is_utfXX(curbp)) {
> +if ((c > 127) && b_is_utfXX(curbp)) {
>   nbytes = vl_conv_to_utf8(target, (UINT) c, sizeof(target));
>  } else if (okCTYPE2(vl_wide_enc) && !vl_mb_is_8bit(c)) {
>   nbytes = 1;
> diff --git a/proto.h b/proto.h
> index 4c8198f..77ab7e0 100644
> --- a/proto.h
> +++ b/proto.h
> @@ -873,10 +873,10 @@ extern int lrepl_regex (REGEXVAL *expr, const char 
> *iline, int ilen);
>  
>  #if OPT_MULTIBYTE
>  extern int ldel_chars (B_COUNT n, int kflag);
> -extern int lins_chars (int n, int c, int wide);
> +extern int lins_chars (int n, int c);
>  #else
>  #define ldel_chars(n, kflag) ldel_bytes(n, kflag)
> -#define lins_chars(n, c, wide)  lins_bytes(n, c)
> +#define lins_chars(n, c)  lins_bytes(n, c)
>  #endif
>  
>  #if OPT_REGS_CMPL


-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

[Ubuntu-x-swat] [Bug 1983276] Re: xterm processing grep color loses char at end of line

[Thomas Dickey]

If you don't like that, you should (see the FAQ) avoid using Linux
console as well.

-- 
You received this bug notification because you are a member of Ubuntu-X,
which is subscribed to xterm in Ubuntu.
https://bugs.launchpad.net/bugs/1983276

Title:
  xterm processing grep color loses char at end of line

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xterm/+bug/1983276/+subscriptions


___
Mailing list: https://launchpad.net/~ubuntu-x-swat
Post to : ubuntu-x-swat@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-x-swat
More help   : https://help.launchpad.net/ListHelp

[Ubuntu-x-swat] [Bug 1983276] Re: xterm processing grep color loses char at end of line

[Thomas Dickey]

You might find the FAQ helpful:

https://invisible-island.net/xterm/xterm.faq.html#vt100_wrapping

-- 
You received this bug notification because you are a member of Ubuntu-X,
which is subscribed to xterm in Ubuntu.
https://bugs.launchpad.net/bugs/1983276

Title:
  xterm processing grep color loses char at end of line

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xterm/+bug/1983276/+subscriptions


___
Mailing list: https://launchpad.net/~ubuntu-x-swat
Post to : ubuntu-x-swat@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-x-swat
More help   : https://help.launchpad.net/ListHelp

[Ubuntu-x-swat] [Bug 1983276] Re: xterm processing grep color loses char at end of line

[Thomas Dickey]

That's not a bug.  Here's a cleaned-up demo for 80 columns:

echo '--
--\33[01;31m\33[KABCD\33[m\33[KE'

See for example

https://invisible-island.net/vttest/vttest-wrap.html

** Changed in: xterm (Ubuntu)
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Ubuntu-X,
which is subscribed to xterm in Ubuntu.
https://bugs.launchpad.net/bugs/1983276

Title:
  xterm processing grep color loses char at end of line

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xterm/+bug/1983276/+subscriptions


___
Mailing list: https://launchpad.net/~ubuntu-x-swat
Post to : ubuntu-x-swat@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-x-swat
More help   : https://help.launchpad.net/ListHelp

Re: UTF8 has stopped working in vile after OS upgrade

[Thomas Dickey]

On Fri, Jul 29, 2022 at 04:27:05AM -0400, Thomas Dickey wrote:
> On Fri, Jul 29, 2022 at 03:40:12PM +1000, Brendan O'Dea wrote:
> > Testing the vile 9.8v-2 package on my Debian machine I get some decidedly
> > odd behaviour:
> > 
> > The following sequence:
> > 
> >   l- e' c,
> > 
> > is rendered in vile as:
> > 
> >   \?A3\?E9\?E7
> > 
> > outside of vile, in the same terminal that appears fine:
> > 
> >   £éç
> > 
> > which would suggest that vile doesn't handle UTF-8 at all, although as
> > Chris noted, entering those three characters using C-v x  works fine,
> > and renders in vile correctly.
> 
> hmm - with some time, I can bisect to pinpoint the problem.

did that.  It's a small change, which I'll have to rethink.
Attaching a diff showing what I changed to get this problem.

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net
Index: CHANGES
--- vile/CHANGES	2020-09-09 00:17:55.0 +
+++ vile-bad/CHANGES	2020-11-30 00:56:48.0 +
@@ -1,9 +1,11 @@
 Changes for vile 9.9 (released ??? ??? ?? )
 
- 20200908 (v)
+ 20201129 (v)
  	> Stephan Schulz:
 	+ add popup-choices mode (Savannah #58999)
 	> Tom Dickey:
+	+ modify lins_chars() to handle a case where a script inserts a UTF-8
+	  character (report by Thomas Dupond).
 	+ modify configure/makefiles to support ".PHONY" feature.
 	+ change configure/makefiles to use ARFLAGS rather than AR_OPTS
 	+ change configure --with-warnings to --enable-warnings for consistency
Index: estruct.h
Prereq:  1.757 
--- vile/estruct.h	2020-08-23 19:03:03.0 +
+++ vile-bad/estruct.h	2020-11-29 22:41:44.0 +
@@ -12,7 +12,7 @@
 */
 
 /*
- * $Id: estruct.h,v 1.757 2020/08/23 19:03:03 Stephan.Schulz Exp $
+ * $Id: estruct.h,v 1.758 2020/11/29 22:41:44 tom Exp $
  */
 
 #ifndef _estruct_h
@@ -1316,10 +1316,14 @@
  * True if the buffer contents are in UTF-8 (or -16, -32).
  */
 #if OPT_MULTIBYTE
+#define global_is_utfXX()((global_b_val(VAL_FILE_ENCODING) >= enc_UTF8) \
+			   || (global_b_val(VAL_FILE_ENCODING) == enc_LOCALE \
+			&& vl_encoding >= enc_UTF8))
 #define b_is_utfXX(bp)   ((b_val(bp, VAL_FILE_ENCODING) >= enc_UTF8) \
 			   || (b_val(bp, VAL_FILE_ENCODING) == enc_LOCALE \
 			&& vl_encoding >= enc_UTF8))
 #else
+#define global_is_utfXX()0
 #define b_is_utfXX(bp)   0
 #endif
 
Index: insert.c
Prereq:  1.184 
--- vile/insert.c	2015-03-13 10:29:15.0 +
+++ vile-bad/insert.c	2020-11-29 22:44:16.0 +
@@ -4,7 +4,7 @@
  * Most code probably by Dan Lawrence or Dave Conroy for MicroEMACS
  * Extensions for vile by Paul Fox
  *
- * $Header: /tmp/vile/RCS/insert.c,v 1.184 2015/03/13 10:29:15 tom Exp $
+ * $Header: /tmp/vile/RCS/insert.c,v 1.185 2020/11/29 22:44:16 tom Exp $
  */
 
 #include	"estruct.h"
@@ -1039,7 +1039,7 @@
 	while (n--) {
 	tp = tstring;
 	while (*tp) {
-		if ((status = inschar(*tp++, _limit)) != TRUE) {
+		if ((status = inschar(CharOf(*tp++), _limit)) != TRUE) {
 		n = 0;
 		break;
 		}
Index: line.c
Prereq:  1.235 
--- vile/line.c	2019-12-19 09:32:10.0 +
+++ vile-bad/line.c	2020-11-30 00:46:44.0 +
@@ -10,7 +10,7 @@
  * editing must be being displayed, which means that "b_nwnd" is non zero,
  * which means that the dot and mark values in the buffer headers are nonsense.
  *
- * $Id: line.c,v 1.235 2019/12/19 09:32:10 bod Exp $
+ * $Id: line.c,v 1.236 2020/11/30 00:46:44 tom Exp $
  */
 
 /* #define POISON */
@@ -542,7 +542,7 @@
 int nn;
 int mapped;
 
-if ((c > 127) && b_is_utfXX(curbp)) {
+if (!global_is_utfXX() && (c > 127) && b_is_utfXX(curbp)) {
 	nbytes = vl_conv_to_utf8(target, (UINT) c, sizeof(target));
 } else if (okCTYPE2(vl_wide_enc) && !vl_mb_is_8bit(c)) {
 	nbytes = 1;


signature.asc
Description: PGP signature

Re: [Lynx-dev] lynx blinking after terminal window resizing

[Thomas Dickey]

On Sun, Jun 12, 2022 at 03:16:40AM +0300, mark zaharov wrote:
> here is the solution which my friend provides. He said it works well with 
> slang and this bug exists for ncurces only.
> --- lynx-2.9.0dev.10.orig/src/LYStrings.c   2021-10-24 12:05:19.0 
> +0300
> +++ lynx-2.9.0dev.10/src/LYStrings.c2022-06-11 23:58:18.946192456 +0300
> @@ -2250,7 +2250,7 @@
> recent_sizechange));
>  #endif /* HAVE_SIZECHANGE || USE_SLANG */
> if (!recent_sizechange) {
> -#if defined(NCURSES)
> +#if defined(NCURSES) && 0
> /*
>  * Work-around for scenario (Linux libc5) where we got a
>  * recent sizechange before reading KEY_RESIZE.  If we do

Perhaps this would be reproducible if the version of lynx were identified,
as well as which platform.  I don't see it using
- xterm 372,
- ncurses 6.1 and 6.3,
- lynx 2.8.9rel.1 and 2.9.0dev.10

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Re: UTF8 has stopped working in vile after OS upgrade

[Thomas Dickey]

On Fri, Jul 29, 2022 at 03:40:12PM +1000, Brendan O'Dea wrote:
> Testing the vile 9.8v-2 package on my Debian machine I get some decidedly
> odd behaviour:
> 
> The following sequence:
> 
>   l- e' c,
> 
> is rendered in vile as:
> 
>   \?A3\?E9\?E7
> 
> outside of vile, in the same terminal that appears fine:
> 
>   £éç
> 
> which would suggest that vile doesn't handle UTF-8 at all, although as
> Chris noted, entering those three characters using C-v x  works fine,
> and renders in vile correctly.

hmm - with some time, I can bisect to pinpoint the problem.

(pasting outside of 0..255 seems ok)

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Re: UTF8 has stopped working in vile after OS upgrade

[Thomas Dickey]

On Thu, Jul 28, 2022 at 10:27:05PM +0100, Chris Green wrote:
> ... and further, no compose key sequences work in vile 9.8v whereas
> they do work in vile 9.8u.
> 
> E.g. I can't enter accented characters using COMPOSE + e + ' (for e
> with acute accent) or COMPOSE + c + , (for c with a cedilla).

hmm - in a quick check (without getting into keyboard configuration
or compose), I can reproduce this in my Ubuntu 22.04 machine,
by pasting text selected/copied between xterms(*)
and don't see the problem in the older Debian machine that I'm using.

So there's something that I can investigate.

At the moment, I'm getting ready for a trip (email yes, development no),
but am supposing that I can dig into this next week :-)

(*) something that I can fix.  I've noticed that gnome-terminal is really
flakey in Ubuntu 22.04, but _that_ is off-topic.

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Re: UTF8 has stopped working in vile after OS upgrade

[Thomas Dickey]

On Thu, Jul 28, 2022 at 09:21:52PM +0100, Chris Green wrote:
> Further information...
> 
> I've built vile 9.7 on this system and pound signs work correctly, if
> I build vile 9.8 with the same build environment pound signs don't work.

That's a fairly long timespan, since I started 9.8 in 2010.
But you might be able to pinpoint that more closely using

https://github.com/ThomasDickey/vile-snapshots

(about 250 tags since 2010, or ~8 steps).

I have an Ubuntu 20.04 and 22.04 machine for test-compiles;
"locale -a" (the easy fix) only shows C.UTF-8 changing to C.utf8

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Re: UTF8 has stopped working in vile after OS upgrade

[Thomas Dickey]

On Thu, Jul 28, 2022 at 11:54:54AM +0100, Chris Green wrote:
> I just upgraded my systems from xubuntu 21.10 to xubuntu 22.04.

I don't know about "xubuntu", but Ubuntu 22.04 doesn't seem an improvement.
 
> My UTF8 confiuguration in vile and xvile is broken now. 
> 
> Well, entering pound sterling signs no longer works, here is one:-
> 
> �
> 
> (That looks a bit like an iso 8859-1 character to me, not sure really)
> 
> vile has been upgraded to version 9.8v, all my locale settings are
> unchanged I think, and pound signs seem to be working correctly
> everywhere else.

Perhaps

locale -a

would show only UTF-8 encoding (vile is designed to know about a combination
of non-UTF-8 and UTF-8, which used to be a problem).  I've not changed any of
that for quite a while -- locale support is the first place to check.

> It's the character *entry* in vile/xvile that's broken, if I create a
> file with pound signs in it and then open it with vile then the pound
> signs display correctly.
> 
> -- 
> Chris Green
> 

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#31477: #31477 lynx: bookmark file is relative to home dir

[Thomas Dickey]

The documentation was updated in 2.8.2dev.4, to state

.h2 DEFAULT_BOOKMARK_FILE
# DEFAULT_BOOKMARK_FILE is the filename used for storing personal 
bookmarks.
# It will be prepended by the user's home directory.
# NOTE that a file ending in .html or other suffix mapped to text/html
# should be used to ensure its treatment as HTML.  The built-in default
# is lynx_bookmarks.html.  On both Unix and VMS, if a subdirectory off 
of
# the HOME directory is desired, the path should begin with "./" (e.g.,
# ./BM/lynx_bookmarks.html), but the subdirectory must already exist.
# Lynx will create the bookmark file, if it does not already exist, on
# the first ADD_BOOKMARK attempt if the HOME directory is indicated
# (i.e., if the definition is just filename.html without any slashes),
# but requires a pre-existing subdirectory to create the file there.
# The user can re-define the default bookmark file, as well as a set
# of sub-bookmark files if multiple bookmark file support is enabled
# (see below), via the 'o'ptions menu, and can save those definitions
# in the .lynxrc file.
#
#DEFAULT_BOOKMARK_FILE:lynx_bookmarks.html

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Re: [Lynx-dev] lynx misrenders many valid xhtml5 pages on my site

[Thomas Dickey]

On Tue, Jul 26, 2022 at 04:51:05AM +0300, Shlomi Fish wrote:
> Hi Mr. Dickey!
> 
> lynx 
> https://www.shlomifish.org/humour/Summerschool-at-the-NSA/ongoing-text.html
> still misrenders.

I don't see the problem in a quick check.  The apparent problem before
was that the page was truncated (about 200 lines).  In both the Fedora
package and my own build, I'm getting ~2200 lines, which seems complete.

some hints about what's not working right would help :-)
 
> 
> 
> Name : lynx Version : 2.9.0 Release : dev.10.2.fc37 Architecture:
> x86_64 Install Date: Sat 16 Jul 2022 17:56:18 IDT Group : Unspecified
> Size : 6447354 License : GPLv2 Signature : (none) Source RPM :
> lynx-2.9.0-dev.10.2.fc37.src.rpm Build Date : Sat 16 Jul 2022 17:54:16
> IDT Build Host : localhost Packager : Shlomi Fish URL :
> https://lynx.invisible-island.net/ Summary : A text-based Web browser
> Description : Lynx is a text-based Web browser. Lynx does not display
> any images, but it does support frames, tables, and most other HTML
> tags. One advantage Lynx has over graphical browsers is speed; Lynx
> starts and exits quickly and swiftly displays web pages.
> 
> On Mon, Jun 13, 2022 at 1:07 PM Thomas Dickey  wrote:
> >
> > - Original Message -
> > | From: "Shlomi Fish" 
> > | To: "Thomas Dickey" 
> > | Cc: "lynx-dev" 
> > | Sent: Monday, June 13, 2022 5:38:43 AM
> > | Subject: Re: [Lynx-dev] lynx misrenders many valid xhtml5 pages on my site
> >
> > | Hi Mr. Dickey!
> > |
> > | On Sun, Jun 12, 2022 at 4:57 PM Thomas Dickey  wrote:
> > |>
> > |> On Sat, Jun 11, 2022 at 06:06:37AM +0300, Shlomi Fish wrote:
> > |> > Hi Mr. Dickey!
> > |> >
> > |> > Given https://src.fedoraproject.org/rpms/lynx/pull-request/4 , can you
> > |> > please review the patch?
> > |>
> > |> That's a little more polished, but the unconditional change in the patch
> > |> is a possible problem.
> > |>
> > |
> > | thanks for the reply. Can you provide a problematic testcase?
> >
> > I followed up on the pull-request.
> >
> > --
> > Thomas E. Dickey 
> > http://invisible-island.net
> > ftp://ftp.invisible-island.net
> 
> 
> 
> -- 
> Shlomi Fish https://www.shlomifish.org/
> 
> Chuck Norris was challenged to fight the world, and accepted. He bet
> on himself, won, and collected the bet money.
> 
> Please reply to list if it's a mailing list post - http://shlom.in/reply .

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

[Lynx-dev] [n...@netguru.com: Cookies, Lynx and the beginnings of the Web – a story worth telling]

[Thomas Dickey]

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net
--- Begin Message ---
Hello Thomas,

I hope you're doing great.

We've recently published a story about one of the co-founders of Lynx – Lou
Montulli.


*You can read the story here.
*


As you are now working on the browser maintenance today I'd really like to
hear your feedback.


The story is a part of a new publishing initiative authored by Steven
Johnson – *Hidden Heroes* , to promote
under-represented pioneers from the history of software. We want to bring
innovators who shaped our world to the front and give the credit they truly
deserve.


I'd also appreciate it if you can share the story with your network.


Let me know your thoughts and have a fabulous week ahead!

Best,

Nat
--- End Message ---


signature.asc
Description: PGP signature

Bug#1015756: lynx: segfault when setting 'default colors' to 'OFF'

[Thomas Dickey]

On Wed, Jul 20, 2022 at 06:37:18PM -0400, Thomas Dickey wrote:
> On Wed, Jul 20, 2022 at 06:27:34PM -0400, Thomas Dickey wrote:
> > On Wed, Jul 20, 2022 at 06:01:01PM -0400, Thomas Dickey wrote:
> > > On Wed, Jul 20, 2022 at 05:50:48PM +0200, Cédric Hannotier wrote:
> > > > Package: lynx
> > > > Version: 2.9.0dev.10-1
> > > > Severity: normal
> > > > 
> > > > Dear Maintainer,
> > > > 
> > > > Seems that toggling off the "default colors" in the option menu
> > > > crashes lynx (segfault).
> > > > 
> > > > Steps:
> > > >  - $ lynx
> > > >  - Press o
> > > >  - navigate to "Default colors (!)"
> > > >  - switch from "ON_" (default) to "OFF"
> > > >  - navigate to "Accept Changes" and press enter
> > > > 
> > > > Disabling it using the command-line option
> > > > (lynx -default_colors) seems to work.
> > > > However, toggling it ON, then OFF makes it segfault.
> > > 
> > > thanks (I can reproduce this, will investigate)
> > 
> > The issue that I can reproduce is in ncurses.
> 
> (my traceback is longer than that given in the bug report)
> 
> > Will reassign & resolve it there.
> 
> The apparent problem is from this change:
> 
> 20211106
>   + fix a memory-leak in del_curterm (prompted by discussion with Bram
> Moolenaar, cf: 20210821).
> 
> Lynx uses delscreen (in libncurses*) when resetting curses,
> which calls del_curterm (in libtinfo*).
> 
> Few programs do this, so it's taken a while to notice.

There was more than one problem, all older than the indicated change.
That just happened to move things around to make the problems noticeable.

In the diffstat:

 ncurses/base/lib_set_term.c   |8 +--
 ncurses/tinfo/lib_setup.c |4 +--
 ncurses/tinfo/lib_tputs.c |9 
 ncurses/trace/lib_trace.c |   22 +++-
 ncurses/tty/tty_update.c  |   16 ++-

The changes in "tinfo" and "tty" are relevant.  The core dump is fixed
by the change in tty_update.c, while the other changes are things that
would be a problem at another time.  (The change to lib_set_term.c is
just to be more certain, and the trace change doesn't affect Debian).

However, there's still a less-visible issue in lynx source (seen with
valgrind), which is fixed in

v2-9-0dev_10i

seen here

https://github.com/ThomasDickey/lynx-snapshots/commit/76e3af60e119146f4da21a008af1ff752c61136f

Since that didn't cause the core-dump which I can reproduce,
it's just fyi - will be in dev.11

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature