build problem and misbehavior in current master

[balducci]

hello

I find the following two problems with latest master (3c8026be54e10a0bfedbb66ab8e600fd29859560)

1. The only way to get a successful (meson) build is to run with:

   -Dtrue-color=true
   -D88-colors=true
   -D256-colors=true

   Turning any of the above options to false or relying on defaults in meson_options.txt (all false), fails with errors like the one below:

    gcc -m64 -Isrc/elinks.p -Isrc -I../src -I. -I.. -I/opt/stow.d/stow/zlib/usr/include -I/opt/stow.d/versions/openssl-3.0.2/usr/include -I/opt/stow.d/versions/expat-2.4.7/usr/include -I/opt/stow.d/versions/python3-3.10.3/usr/python3/include/python3.10 -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -O0 -g '-DGETTEXT_PACKAGE="elinks"' '-DBUILD_ID=""' -DHAVE_CONFIG_H -fno-strict-aliasing -Wno-builtin-declaration-mismatch -Wno-address -Wc++-compat -MD -MQ src/elinks.p/bfu_style.c.o -MF src/elinks.p/bfu_style.c.o.d -o src/elinks.p/bfu_style.c.o -c ../src/bfu/style.c
    ../src/bfu/style.c: In function ‘get_bfu_color88_node’:
    ../src/bfu/style.c:79:64: error: ‘COLOR_MODE_88’ undeclared (first use in this function); did you mean ‘COLOR_MODE_16’?
       79 |                 set_term_color(&entry->c88, &entry->colors, 0, COLOR_MODE_88);
          |                                                                ^~~~~~~~~~~~~
          |                                                                COLOR_MODE_16
    ../src/bfu/style.c:79:64: note: each undeclared identifier is reported only once for each function it appears in
    ../src/bfu/style.c: In function ‘get_bfu_color256_node’:
    ../src/bfu/style.c:92:65: error: ‘COLOR_MODE_256’ undeclared (first use in this function); did you mean ‘COLOR_MODE_16’?
       92 |                 set_term_color(&entry->c256, &entry->colors, 0, COLOR_MODE_256);
          |                                                                 ^~~~~~~~~~~~~~
          |                                                                 COLOR_MODE_16
    ../src/bfu/style.c: In function ‘get_bfu_true_color_node’:
    ../src/bfu/style.c:105:64: error: ‘COLOR_MODE_TRUE_COLOR’ undeclared (first use in this function)
      105 |                 set_term_color(&entry->c24, &entry->colors, 0, COLOR_MODE_TRUE_COLOR);
          |                                                                ^~~~~~~~~~~~~~~~~~~~~

Until now I always built without any of the above options and had no problems

2. After successful build (as per point 1. above), elinks fills (text) lines with an @ character, as shown by this example https://gist.github.com/balducci/8f070523abb07911fa79b3945a13d983

Git bisection points to this as the first bad commit:

    6d6a058e378c42bab5adb8515efa2bf35cfc45eb is the first bad commit
    commit 6d6a058e378c42bab5adb8515efa2bf35cfc45eb
    Author: Witold Filipczyk <witekfl@poczta.onet.pl>
    Date:   Sun Mar 20 16:46:55 2022 +0100

        [viewer] Fill backgroud with Turbo Vision's char

        It is a workaround, because I did not know how to fix issue
        with shadows in 24bit mode.

     src/viewer/text/draw.c | 12 ++++++++++++
     1 file changed, 12 insertions(+)

I run elinks in an xterm

My usual configuration (ie not including the three color related options mentioned in point 1 above):

    -Dperl=false
    -Dpython=true
    -Dgnutls=false
    -Dspidermonkey=false
    -Dsm-scripting=false
    -Dtre=false
    -Dfsp=false
    -Dgpm=false

My elinks.conf file is here https://gist.github.com/balducci/b57f242835b8ff07f50f3658de3ce37b

Thanks a lot for your valuable work -g

[rkd77]

Thanks for the report. I hope is compilable at least now. I want to fix issue with background colors. Now there are stripes on many sites. The idea was to associate numbers with every node of html instead of colors directly. It will be slower, but some things would be easier. When nodes are numbered, somehow (not know yet how), orphan cells with background (TV) will be added to nodes with numbers, especiallly block elements like DIV, etc. and coloured. I have no too much enthusiasm to code long on branches. Instead of I would like to add gradual changes in small chunks. Latest changes broke something, for example mono mode and shadows in some cases. It will take some time to find out what is wrong.

[rkd77]

Ad 2) If you set ui.colors.color.desktop.text and ui.colors.color.desktop.background to the same color, you'll get similar result to earlier elinks versions.

[balducci]

Thanks for the report. I hope is compilable at least now.

I confirm that current master now builds fine WITHOUT explicit true-color/88-colors/256-colors options, like it used to be until now: thanks a lot

As for problem n.2, I have tried what you suggested, but that didn't fix things

But I have to make more tests, since I seem to understand that it's a not so simple game between elinks AND xterm: so maybe tuning xterm X resources I can make current elinks work well...

[rkd77]

@balducci Could you describe it, or show current screenshot? Empty cells will be filled with spaces of desktop color, if desktop text color and desktop background color are same. It is not the same as before, because before it was filled with document's colors. That's why I wrote "similar result".

[balducci]

@balducci Could you describe it, or show current screenshot? Empty cells will be filled with spaces of desktop color, if desktop text color and desktop background color are same. It is not the same as before, because before it was filled with document's colors. That's why I wrote "similar result".

I made some more work on this. I run elinks in an xterm and in my configuration file I had: set terminal.xterm.colors = 0 That was making your suggested fix ineffective

Once I turned set terminal.xterm.colors = 1 things worked

So, AFAICS, current elinks with set terminal.xterm.colors = 1 plus your suggestion:

set ui.colors.color.desktop.text = "gray"
set ui.colors.color.desktop.background = "gray"

works nicely

OTOH, running with set terminal.xterm.colors = 0 (meaning no color, ie mono, I guess) is still broken, with the main window appearing as per https://gist.github.com/balducci/8f070523abb07911fa79b3945a13d983

thanks a lot for spending time on this

[rkd77]

Now, with with ui.background_char set to code value of inverted space, and different colors for desktop background and text, also on mono terminals ought to be possible to view background "spaces". By inverted space I mean 0x2588, 9608 in decimal.

[Strahinja]

With that latest commit, background fill color and the document background color look different: (This is a capture of my home page, https://strahinja.org.)

This is my elinks.conf: https://git.sr.ht/~strahinja/dotfiles/tree/master/item/elinks/elinks.conf

[rkd77]

Yes, I know. It will be like this until someone fixes it. In theory this background should look like as on Linux console, but with antialiasing it looks like on screen. You can change background character code. (ui.background_char) and ui.colors.color.desktop.text and ui.colors.color.desktop.background. Now these settings are 0x2591, blue and white. It is a step back. Its purpose is to motivate to fix background colors rendering.

[Strahinja]

May I ask where does the antialiasing happen? My screenshot is of st (suckless terminal) using the PCF version of Terminus.

[balducci]

Now, with with ui.background_char set to code value of inverted space, and different colors for desktop background and text, also on mono terminals ought to be possible to view background "spaces". By inverted space I mean 0x2588, 9608 in decimal.

I confirm that xterm in mono mode (set terminal.xterm.colors = 0) works fine for me with current master (8ee9062955280a22c529b602dbbe55130deb3730) For reasons probably related with the used locale (I use C locale) I have to use set ui.background_char = 32 instead of set ui.background_char = 9608; moreover, also the setting of document.colors.background is crucial and I have to set it to black. So for me the working combination is:

set document.colors.background = "black"
set ui.colors.mono.desktop.text = "white"
set ui.colors.mono.desktop.background = "white"
set ui.background_char = 32

Which gives me what I want:

I don't know why document.colors.background has to be defined to black (where ui.colors.mono.desktop.* are both white): if I set document.colors.background to any other color, including white, the result is not satisfactory:

So to summarize, for me both color and mono xterm work fine with current master.

1. color xterm: set terminal.xterm.colors = 1

   set document.colors.background = "gray"
   set ui.colors.color.desktop.text = "gray"
   set ui.colors.color.desktop.background = "gray"

2. mono xterm: set terminal.xterm.colors = 0

   
   set document.colors.background = "black"
   set ui.colors.mono.desktop.text = "white"
   set ui.colors.mono.desktop.background = "white"
   set ui.background_char = 32

I really appreciated your availability, help and assistance

[rkd77]

@Strahinja what is your config.h of st?

[Strahinja]

https://git.sr.ht/~strahinja/st/tree/master/item/config.h

Anyway, setting ui.background_char = 32 seems to work, but then there is no difference between menus/UI and the "desktop" background of ELinks:

While testing different options, I noticed what seems a bug, for which I am unsure if I should open a separate issue. When I open the configuration editor with o, then press / to search for a string, for example background, I get a dialog box with a message that the string is not found, but when I press Enter or Space, the shadow is left on the configuration editor dialog (it is not redrawn):

[rkd77]

Yes, shadows are broken. I don't know how to fix it. Desktop background is visible on startup, when there is no page to load, and in places where document's lines are ending.

I try to run st, but cannot set it with terminus font. I checked konsole, and with "smooth fonts" ticked it looks like on previous screen, without "smooth fonts" it looks different. fbterm with terminus font is ok.

[Strahinja]

This is likely because fontconfig needs specific configuration settings to recognize bitmap fonts. I have installed Terminus directly from its home page, and copied 75-yes-terminus.conf to /etc/fonts/conf.d. Also I have 70-yes-bitmaps.conf symlinked in /etc/fonts/conf.d from /usr/share/fontconfig/conf.avail/70-yes-bitmaps.conf.

I am not familiar with the internals of ELinks, but with regards to the shadow redraw issue, I think at least the "brute force" solution should be attempted, namely to fully redraw the parent dialog box when the child dialog box closes, if possible.

About the desktop background color issue, what I feel should be the most natural behavior is to have the current configuration setting only serve as the default value, setting the color when no document is loaded, and after a document is loaded the "desktop background color" should be the same as the background color of the document text.

[balducci]

About the desktop background color issue, what I feel should be the most natural behavior is to have the current configuration setting only serve as the default value, setting the color when no document is loaded, and after a document is loaded the "desktop background color" should be the same as the background color of the document text.

Shouldn't that be configurable with document.colors.use_document_colors?

    ## document.colors.use_document_colors <num>
    #  Use colors specified in document:
    #  0 is use always the default settings
    #  1 is use document colors if available, except background
    #  2 is use document colors, including background. This can
    #    mostly look very impressive, but some sites will appear
    #    really ugly. Note, that obviously if the background is
    #    not black, it will break the behaviour of transparency.

or maybe I'm misunderstanding something...

[Strahinja]

I have that set to 2, and the result is shown above.

Update: I have solved the issue of UI colors not being different than desktop background color by setting all ui.colors.color.*.background options (other than desktop) which were set to "white" to "lightgrey". Maybe that should be the default background for all UI elements in color mode, and "white" for ui.colors.color.desktop.background (or vice versa)?

Update 2: There is another issue with shadows: when the configuration editor dialog is open, if I press Enter when the Info button is selected, the info dialog box that is shown doesn't have its bottom shadow drawn:

[rkd77]

@Strahinja could you check if 1e27359afa651525bd7d1a042f4dd0fbdc858a7e fixes issue with shadow?

[Strahinja]

It solves both issues with shadows, thanks! The dialogs seem to be correctly drawn.