New version: 4.50.18

[S.E. Mitchell]

For Windows:
https://semware.com/files/tse-pro-install/tse-setup-4.50.18.zip

For Linux:
https://semware.com/files/tse-pro-install/tse-linux-4.50.18.tgz
https://semware.com/files/tse-pro-install/tse-linux-4.50.18.zip

The Linux version archives will create a directory called "tse".
After unarchiving, you can rename/move that to whatever you want.

---------------------------------------------------------------
19 Dec 2025 v4.50.18
---------------------------------------------------------------
Process commands have been reverted to using COMSPEC to get the
name of the shell to use. Reported by Knud van Eeden.

Font bug addressed. Reported by Carlo Hogeveen.

[knud van eeden]

> from the TSE for Linux version 4.50.18 read.me:

> Changed cursor shape/size as follows:

0    - no cursor

1    - steady underline

2, 3 - steady block

4    - steady vertical bar

5    - no cursor

6    - blinking underline

7, 8 - blinking block

9    - blinking vertical bar

===

a. The current default for TSE for Linux is thus for 4.50.18 currently (see also the screenshot):

'4'    - steady vertical bar (for insert)

'2'    - steady block (for overwrite)

===

b. But in TSE for Microsoft Windows also 4.50.18 the choice historically for many decades back has always been more like this:

'7'    - blinking block (for insert)  

'6'    - blinking underline (for overwrite)

===

(FYI: see values at TSE menu > 'Full Configuration' > 'Display' > 'Cursor Size' > 'Insert' | 'Overwrite' | ')

===

Any reason why there has been deviated from these cursor shape settings for 'Insert' and 'Overwrite'? 

The preferred choice for TSE for Linux would thus be out of the box default 7 for insert and 6 for overwrite.

Of course my choice here would be to keep it as most as possible the same in both TSE for Linux and TSE for Microsoft Windows version,

so reverting back to a much more TSE Microsoft Windows compatible choice.

Thanks

with friendly greetings

Knud van Eeden

[J. David Boyd]

> Process commands have been reverted to using COMSPEC to get the
> name of the shell to use. Reported by Knud van Eeden.

Thanks so much for putting this back.  I use TCC exclusively, and I would hate to have to be in a CMD shell for anything!

--

---
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 visit https://groups.google.com/d/msgid/semware/CA%2BgEvkbRdAu_RY9D9Cz9eUEQkuQSa%3D2VLxk4cREUq_avzKr1ww%40mail.gmail.com.

--

What's so funny about peace, love, and understanding? 

[zhong zhao]

I found isWinClipAvailable() in 4.50.13 return _LINE_ or _COLUMN_ when just call CopyToWinClip() for mark block type _LINE_ or _COLUMN_,that is OK;

but, isWinClipAvailable() in 4.50.17 and 4.50.18 return _LINE_ both when just call CopyToWinClip() for mark block type _LINE_ or _COLUMN_,that is BUG.

[S.E. Mitchell]

Changed the subject to be inline with the subject :)
This (isWinClipAvailable()) is another casualty of adding the Linux
clipboard support. I consolidated too much code, and did not have
enough comments.
I have fixed this, and also added it to sanity - Windows only, sadly.
Thanks for the report.

[knud van eeden]

Hello,

FYIO

with friendly greetings

Knud van Eeden 

> Determines if there is any data in the Windows Clipboard that can be pasted

> into the editor.

>

> Syntax:     INTEGER isWinClipAvailable()

>

> Returns:    Zero (FALSE) if there is not suitable data in the Windows

>             Clipboard;  If there is a block, the return value is one of the

>             following:

>

>             - _INCLUSIVE_ for an inclusive character block

>

>             - _NONINCLUSIVE_ for a non-inclusive character block

>

>             - _LINE_ for a line block

>

>             - _COLUMN_ for a column block

>

> Notes:      The primary use for this command is to disable, and "gray out,"

>             appropriate menu selections related to pasting from the Windows

>             Clipboard, if there is no suitable data in the Clipboard.

>

This (isWinClipAvailable()) is another casualty of adding the Linux

clipboard support. I consolidated too much code, and did not have

enough comments.

I have fixed this, and also added it to sanity - Microsoft Windows only, sadly.

Question: How to check if there is data on the Linux clipboard? (TSE SAL is written in Borland C)?

[ChatGPT]

On Linux there is not a single "clipboard API" like Windows. What you can do depends on **which display system you are running under**:

* **X11 (xterm/gnome-terminal on Xorg, or Xwayland):** you can query the clipboard selection owner via Xlib.

* **Wayland (native Wayland terminals):** there is *no global clipboard owner you can query via Xlib*; you typically talk to the compositor (Wayland protocols) or shell out to `wl-paste`.

* **Pure terminal clipboard (OSC 52):** that is a *terminal feature*, not an OS clipboard you can query reliably.

Below are the practical options.

---

## 1) X11: check if CLIPBOARD (or PRIMARY) has an owner

In X11 the "clipboard" is a **selection**. If it has **no owner**, there is nothing to paste.

`XGetSelectionOwner()` returns `None` if there is no owner for that selection. ([tronche.com][1])

**Minimal C check (X11):**

```c

// returns 1 if CLIPBOARD likely has something, else 0

int isX11ClipboardAvailable(void)

{

    Display *dpy = XOpenDisplay(NULL);

    if (!dpy) return 0;

    Atom clip = XInternAtom(dpy, "CLIPBOARD", False);

    Window owner = XGetSelectionOwner(dpy, clip);   // None => no owner

    XCloseDisplay(dpy);

    return (owner != None) ? 1 : 0;

}

// optional: PRIMARY selection (middle-click paste on X11)

int isX11PrimaryAvailable(void)

{

    Display *dpy = XOpenDisplay(NULL);

    if (!dpy) return 0;

    Atom prim = XInternAtom(dpy, "PRIMARY", False);

    Window owner = XGetSelectionOwner(dpy, prim);

    XCloseDisplay(dpy);

    return (owner != None) ? 1 : 0;

}

```

### Caveat (important)

An owner existing does not guarantee it offers **text**. For a closer "isWinClipAvailable"-style test, you should request the selection's supported **TARGETS** (via `XConvertSelection`) and check for `UTF8_STRING`, `TEXT`, `STRING`, etc. (X11 clipboard is *lazy*: the owner provides the data when asked.)

---

## 2) Wayland: you can not do the above; use wl-clipboard (or a Wayland client)

On Wayland, clipboard access is mediated by the compositor; Xlib selection-owner tricks do not apply.

The practical route for a terminal editor is to **shell out** to `wl-paste` (from `wl-clipboard`) and decide "available" based on whether it returns anything.

Also note: in `wl-paste --watch` mode, the tool explicitly distinguishes clipboard state (`data`, `nil`, `clear`). ([Debian Manpages][2])

(That "nil vs clear" distinction is Wayland-specific behavior you will see discussed a lot; clipboard persistence can depend on a clipboard manager. ([Hyprland][3]))

### A robust-ish Wayland check

Because `wl-paste` can block in some "clipboard empty" situations on some setups (there are reports of hangs), many programs do one of:

* run `wl-paste` with a small timeout, or

* run `wl-paste --list-types` and see if it prints anything (behavior can still vary by environment).

If you are implementing inside TSE's C core, the "safe" approach is:

* Try X11 owner check **if `$DISPLAY` is set** and XOpenDisplay works.

* Else, if `$WAYLAND_DISPLAY` is set, run `wl-paste` with a **short timeout** and treat "got any bytes" as "available".

(Your Linux clipboard support already likely shells out somewhere, so this fits your architecture.)

---

## 3) Recommended combined strategy (what editors typically do)

1. **If X11 available:** `XGetSelectionOwner(CLIPBOARD)` (and optionally PRIMARY) fast and non-blocking. ([tronche.com][1])

2. **Else if Wayland:** shell out to `wl-paste` with a timeout (or `--list-types`), treat non-empty output as "available". ([Ubuntu Manpages][4])

3. **Else (no GUI clipboard):** return "not available" (or rely on terminal paste paths only).

If you tell me what your Linux clipboard support in TSE currently uses (Xlib selection code vs calling `xclip/xsel/wl-paste` vs OSC 52), I can sketch an `isLinClipAvailable()` that matches *exactly* that backend and would not hang your UI/menu logic.

[1]: https://tronche.com/gui/x/xlib/window-information/XGetSelectionOwner.html?utm_source=chatgpt.com "XGetSelectionOwner - Xlib Programming Manual"

[2]: https://manpages.debian.org/testing/wl-clipboard/wl-paste.1.en.html?utm_source=chatgpt.com "wl-paste(1) - wl-clipboard - Debian testing"

[3]: https://wiki.hypr.land/Useful-Utilities/Clipboard-Managers/?utm_source=chatgpt.com "Clipboard Managers"

[4]: https://manpages.ubuntu.com/manpages/noble/en/man1/wl-paste.1.html?utm_source=chatgpt.com "wl-clipboard - Wayland copy and paste command line utilities"

--

---
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 visit https://groups.google.com/d/msgid/semware/CA%2BgEvkZktRHx%2BuSYnd4wdC9O0UKwW66my5wqTiKrfYzi6xvhNw%40mail.gmail.com.

[Henriques18]

Sammy,

When talking about isWinClipAvailable(), sometimes (and I can't reproduce this) I get the following messages see the jpg. First the cliperror and then the warn.

This happens after the statements     If isWinClipAvailable()  EmptyWinClip()  EndIf .
But the error doesn't return after there has been something in the winclip. 

Op dinsdag 23 december 2025 om 12:13:34 UTC+1 schreef S.E. Mitchell:

[H P]

Sammy, missed one jpg. Namely handle

Met vriendelijke groet,
With kind regards,

Muy atentamente,
Mit Freundliche Gruß,

Sinceramente,


H. Pikaar
Henri...@gmail.com

Op di 23 dec 2025 om 12:48 schreef Henriques18 <henri...@gmail.com>:

--

---
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 visit https://groups.google.com/d/msgid/semware/f938424c-dc9d-417d-87c4-cfe49461fb60n%40googlegroups.com.

[S.E. Mitchell]

Here is what I've found:
If I access the Windows clipboard too quickly (e.g., quickly as in a
macro) sometimes I also get those errors.
I've gotten them a lot in the sanity macros.
I added delays in the sanity macros, and the problems went away.
So I think it is a Windows problem.
I never had these clipboard issues on Windows XP and Windows 7. I
don't remember about Windows 10. But I get them frequently in Windows
11, and adding the delays (up to delay(5)) fixes it everytime.
If you happen to run into a reproducible scenario, try adding delay(),
and see if that fixes the issue. If not, please let me know!

> --
>
> ---
> 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 visit https://groups.google.com/d/msgid/semware/f938424c-dc9d-417d-87c4-cfe49461fb60n%40googlegroups.com.

[knud van eeden]

'Error 5 opening Windows Clipboard'

Known issue, I have debugged that some years ago using the clipboardownerdebug program.

 https://pretentiousname.com/miscsoft/#ClipboardOwnerDebug

It is most likely some 3rd party program that grabs the content of the clipboard

(e.g. JPSoft TakeCommand / tcc.exe (try and use latest version 35 (download trial and install)), 

Microsoft Word,

...). 

The debugger will show which program(s) interfere(s) on the clipboard.

with friendly greetings

Knud van Eeden

To view this discussion visit https://groups.google.com/d/msgid/semware/CA%2BgEvkYFUR-9PNnZR44nMp3FOHLThsOdGdqX8Q7XDkd4MS2L_A%40mail.gmail.com.

[knud van eeden]

Q. TSE: 'Error 5 opening Windows Clipboard. No text in Windows clipboard'

A.

I had come across this 'no text' error some years before, before it was

caused by a Microsoft Office program, now it showed thus to be JPSoft

tcc.exe. 

I did run a utility program called 'clipboardownerdebug' to

troubleshoot that and see the culprit process. 

After killing that process it

suddenly worked in TSE thus.