New version of TSE available

[S.E. Mitchell]

New version of TSE available:

Windows:
https://semware.com/files/tse-pro-install/tse-setup-4.50-rc11.zip

Linux:
https://semware.com/files/tse-pro-install/tse-linux-4.50-rc11.tgz

---------------------------------------------------------------------------------
02 Sep 2023 v4.50 release candidate 11
---------------------------------------------------------------------------------
Both versions:
If the editor issues a warning before the output system has
been initialized, it can cause it to crash. Fixed. Thanks to
Carlo Hogeveen for the report.

Windows only:
If you mark a COLUMN block that only contains columns past the
end of a line, and copy it to the Windows clipboard, then
TSE's clipboard menu does not gray out pasting from the
Windows clipboard, but if you select it, then you get a
message that the Windows clipboard is empty. Fixed. Thanks to
H. Pikaar for the report, and to Carlo Hogeveen for helping me
to reproduce the problem.

Linux only:
New command line options:

-color
-color 8
Force using 8 color mode

-color 16
Force using 16 color mode

-color rgb
Force using 24-bit color mode

GetColorTableValue() and SetColorTableValue() now work, as long as the
editor is in 24-bit color mode. This means that the setpalette macro
now works in Linux-land if 24-bit color mode is in use.

Current logic editor uses to determines which mode to use:

If TERM environment variable = "xterm256", then use 24-bit color mode.
else If TERM environment variable includes the word "xterm", then use
16-bit color mode,
else use 8 color mode

The new command line option overrides this.

Thanks to Carlo Hogveen for lots of help (and code!) in getting 24-bit
color mode working.

In sync with Windows version

[Carlo Hogeveen]

About the new Linux 4.50 rc 11 release:

Typo:
In the read.me "16-bit color" range should be "16 color(s)".

Minor flaw:
"e -color" does not overrule the default selected color range.
For comparison, "e -color 8" correctly does.

Major flaw (I think):
I wrote a tool that lets us visually test how well TSE supports RGB colors.
https://ecarlo.nl/tse/DemosAndTests.html#Test_RGB_color_support
This works for the Windows GUI version of TSE, but not for its new Linux version, on none of my Linux systems.
In Linux it also does not work if TSE is started with "e -color rgb".

Wish:
The promised configuration setting for the color range, so that we are not dependent on setting it on the command line if TSE selects a wrong default color range.

FYI
My two main Linux systems thru their terminal both support RGB colors.
Their TERM variable values are "xterm" and "xterm-256color".

Carlo

[S.E. Mitchell]

On Tue, Sep 5, 2023 at 7:15 AM Carlo Hogeveen <t...@ecarlo.nl> wrote:
>>Wish:
>>The promised configuration setting for the color range, so that we are not dependent on setting it on the command line if TSE selects a wrong default color range.

I'm debating on how to implement this.

Ideally, I'd like to be able to use the same tse.cfg file for Windows or Linux.
So, if I overload one of the existing identifiers, that might break that goal.

So, maybe add a new variable? term - with values being:
_default_ - editor will figure it out
_8_ - same as -color 8
_16_ - same as -color 16
_rgb_ - same as -color rgb

Feedback welcome!

[Carlo Hogeveen]

To disambiguate "variable": I gather you mean a TSE editor variable, that would be usable with TSE's Query() and Set() commands, and would be settable in TSE's configuration menu.

I think a new TSE editor variable is a good solution.
It can just be ignored by the two Windows TSE variants.
Its proposed values seem reasonable.

I think "term" is not a good editor variable name:
Linux TSE selecting a default color range/scope based on the "TERM" environment variable is as implemented a proven imperfect method, that might still be expanded on or rethought, so it does not make sense to associate an editor variable name with the environment variable name.
And by itself It is a technical name, meaningless to users.
I suggest "ColorRange" and "ColorScope" as the possible new editor variable name.

Carlo

--

---
You received this message because you are subscribed to the Google Groups "SemWare TSE Pro text editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to semware+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/semware/CA%2BgEvkbghcjcMu13CddDG5t2XMBdqg-vPMnbEPEqhJFtz%3DmZrw%40mail.gmail.com.

[Guy Rouillier]

Since we are discussing a new variable, I would suggest avoiding ambiguous terms if possible.  For example, color range and color scope are not immediately understood terms.

What we are actually discussing is bits per pixel, or alternatively, total available colors based on that number of bits.  So, I would vote for something like color_bpp or num_colors, or some alternative to those more completely spelled out, like color_bits_per_pixel or number_available_colors.  I'm not clear if the you want the values to be numeric or alphanumeric.  Especially for the number of available colors, using a numeric value would get cumbersome for, say, 32-bit colors: 4294967296.  Alphanumeric would be easier to work with; 32-bit color would simply be 4G, 16-bit color 64K, etc.

--

Guy Rouillier

To view this discussion on the web visit https://groups.google.com/d/msgid/semware/000501d9e088%2476139830%24623ac890%24%40ecarlo.nl.

[Carlo Hogeveen]

 

For context, the full meaning of the current Linux color command line option values is:

8:   8 background colors and 16 foreground colors.

16:   16 background colors and 16 foreground colors.

rgb:   16,777,216 background colors and 16,777,216 foreground colors.

That actual meaning needs to be simplified, and I think the current solution is a good one.

 

As for Sammy’s proposed editor variable values _8_ and _16_, I suggest simply using 8 and 16.

I suggest _rgb_ to stand for 1, because if I recall correctly editor integer variables cannot be larger than 65536, and because this avoids referencing a meaning that is different from the other values’ meaning.

We do not have to anticipate larger numbers of colors, because those would break TSE’s current architecture.

 

Based on Guy’s feedback I propose an even simpler name: “colors”.

 

And definitely for the command line option and the editor variable to get the same name!

 

Carlo

To view this discussion on the web visit https://groups.google.com/d/msgid/semware/em09160d20-d7d8-427e-8891-90e6e0c2437a%4054701274.com.

[Carlo Hogeveen]

 

Sammy,

 

For your consideration,

 

Context:

I have pre-started on making some of my Windows GUI extensions Linux compatible, namely some of those that are dependent on RGB color support.

 

I created a mock function rgb_support() to test backwards-compatibly whether the user’s TSE variant and version supports RGB colors.

 

From this mock function I learned two things that are of interest for implementing the next Linux TSE release:

 

1.

Obviously TSE’s INTERNAL_VERSION directive needs to be incremented.

 

2.

The editor variable "Colors" (or what its name actually will be) also needs to have value _RGB_ when the command line option "-colors rgb" was used.

 

Carlo

 

 

integer proc rgb_support()

  integer result = FALSE

  #ifdef LINUX

    #if INTERNAL_VERSION >= 12373

      if Query('Colors') == _rgb_

        result = TRUE

      endif

    #endif

  #else

    if isGUI()

      result = TRUE

    endif

  #endif

  return(result)

end rgb_support

 

proc Main()

  Warn('RGB support:'; iif(rgb_support(), 'Yes', 'No.'))

  PurgeMacro(CurrMacroFilename())

end Main