tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] Bidi text

[Kevin W. <kw...@co...>]

On Apr 29, 2026, at 1:25 PM, Benjamin Riefenstahl <b.r...@tu...> wrote:
> 
> I'm comparing with Emacs.  I also just checked GEdit.  Both handle the
> problems I noticed.
> 
>> Correct word wrap, RTL cursor movement, [...] are out of scope.
> 
> Those are serious limitations.  I consider these aspects essential.  I
> don't think I could not actually use it without.  OTOH, I am sure
> somebody (TM) can fix them later, if you can't do it now.

Emacs and Gedit have completely different architectures that provide a full bidi editing stack. My work is focused more on clean display of bidi text. Tk’s support for SVG implements a subset of the spec. Same logic applies here. 
—
Kevin Walzer kw...@co...

Re: [TCLCORE] Bidi text

[Benjamin R. <b.r...@tu...>]

Hi Kevin,

Kevin Walzer writes:
> What platform are you testing on?

This is Debian 13, Harfbuzz 10.2.0.

> It may be necessary to document that bidi support is limited. There is
> wide variation in how it’s supported across platforms and apps. On
> macOS, the benchmark is NSTextView (TextEdit); on X11, it’s
> GtkTextView (Mousepad); and on Windows, it’s Notepad++. Tk has rough
> parity with these apps.

I'm comparing with Emacs.  I also just checked GEdit.  Both handle the
problems I noticed.

> Correct word wrap, RTL cursor movement, [...] are out of scope.

Those are serious limitations.  I consider these aspects essential.  I
don't think I could not actually use it without.  OTOH, I am sure
somebody (TM) can fix them later, if you can't do it now.

Thanks again, benny

Re: [TCLCORE] Bidi text

[Kevin W. <kw...@co...>]

And finally, THANK YOU for testing!  I will see what we can do. 
—
Kevin Walzer kw...@co...

> On Apr 29, 2026, at 12:06 PM, Kevin Walzer <kw...@co...> wrote:
> 
> Having said this, I will run your test sample when I am back at the keyboard.
> —
> Kevin Walzer kw...@co...
> 
>> On Apr 29, 2026, at 12:04 PM, Kevin Walzer <kw...@co...> wrote:
>> 
>> Hi Benny,
>> 
>> What platform are you testing on?
>> 
>> It may be necessary to document that  bidi support is limited. There is wide variation in how it’s supported across platforms and apps. On macOS, the benchmark is NSTextView (TextEdit); on X11, it’s GtkTextView (Mousepad); and on Windows, it’s Notepad++. Tk has rough parity with these apps.
>> 
>> This means:
>> 
>> 1.  Correct visual RTL rendering and shaping.
>> 2. Logical (LTR) cursor placement without visual artifacts.
>> 3. Nothing else.
>> 
>> Correct word wrap, RTL cursor movement, and other components of complete BiDi support are out of scope. We will never match LibreOffice or Chrome/Webkit in this regard. Some prior feedback suggested that these were showstopper bugs, but I disagree.
>> 
>> Implementation of full BiDi support at this level would require a full re-write of the text widget. That is not in scope.
>> 
>> - Kevin
>> 
>> —
>> Kevin Walzer kw...@co...
>> 
>>>> On Apr 29, 2026, at 11:46 AM, Benjamin Riefenstahl <b.r...@tu...> wrote:
>>> 
>>> Another one:
>>> 
>>> * I can not place the cursor in the middle of an RTL line with the
>>> mouse.  The cursor goes to the beginning of the line.
>> 
>> 
>> _______________________________________________
>> Tcl-Core mailing list
>> Tcl...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] Bidi text

[Kevin W. <kw...@co...>]

Having said this, I will run your test sample when I am back at the keyboard. 
—
Kevin Walzer kw...@co...

> On Apr 29, 2026, at 12:04 PM, Kevin Walzer <kw...@co...> wrote:
> 
> Hi Benny,
> 
> What platform are you testing on?
> 
> It may be necessary to document that  bidi support is limited. There is wide variation in how it’s supported across platforms and apps. On macOS, the benchmark is NSTextView (TextEdit); on X11, it’s GtkTextView (Mousepad); and on Windows, it’s Notepad++. Tk has rough parity with these apps.
> 
> This means:
> 
> 1.  Correct visual RTL rendering and shaping.
> 2. Logical (LTR) cursor placement without visual artifacts.
> 3. Nothing else.
> 
> Correct word wrap, RTL cursor movement, and other components of complete BiDi support are out of scope. We will never match LibreOffice or Chrome/Webkit in this regard. Some prior feedback suggested that these were showstopper bugs, but I disagree.
> 
> Implementation of full BiDi support at this level would require a full re-write of the text widget. That is not in scope.
> 
> - Kevin
> 
> —
> Kevin Walzer kw...@co...
> 
>> On Apr 29, 2026, at 11:46 AM, Benjamin Riefenstahl <b.r...@tu...> wrote:
>> 
>> Another one:
>> 
>> * I can not place the cursor in the middle of an RTL line with the
>> mouse.  The cursor goes to the beginning of the line.
> 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] Bidi text

[Kevin W. <kw...@co...>]

Hi Benny,

What platform are you testing on?

It may be necessary to document that  bidi support is limited. There is wide variation in how it’s supported across platforms and apps. On macOS, the benchmark is NSTextView (TextEdit); on X11, it’s GtkTextView (Mousepad); and on Windows, it’s Notepad++. Tk has rough parity with these apps. 

This means:

1.  Correct visual RTL rendering and shaping. 
2. Logical (LTR) cursor placement without visual artifacts. 
3. Nothing else. 

Correct word wrap, RTL cursor movement, and other components of complete BiDi support are out of scope. We will never match LibreOffice or Chrome/Webkit in this regard. Some prior feedback suggested that these were showstopper bugs, but I disagree. 

Implementation of full BiDi support at this level would require a full re-write of the text widget. That is not in scope. 

- Kevin

—
Kevin Walzer kw...@co...

> On Apr 29, 2026, at 11:46 AM, Benjamin Riefenstahl <b.r...@tu...> wrote:
> 
> Another one:
> 
> * I can not place the cursor in the middle of an RTL line with the
>  mouse.  The cursor goes to the beginning of the line.

Re: [TCLCORE] Bidi text

[Benjamin R. <b.r...@tu...>]

Another one:

* I can not place the cursor in the middle of an RTL line with the
  mouse.  The cursor goes to the beginning of the line.

Re: [TCLCORE] Bidi text

[Benjamin R. <b.r...@tu...>]

Hi Kevin.

Kevin Walzer writes:
> I think this is as good as I can make it, and I'd like to request some
> testing. I will be AFK next week for work, so this will give everyone
> some time to review the changes.

Sorry for taking so much time to respond.  First of all thank you for
taking this on!

I have just tested Hebrew so far.  I see these problems with the text
widget:

* Composition with Hebrew combining marks does not work.  (I haven't
  tested Latin combining characters yet.)

* RTL lines are not left-aligned automatically.  This should be decided
  by the first "non-neutral" character.  Where punctuation and digits
  and other characters that are normal at the start of an RTL line are
  considered "neutral".  (There is probably a Unicode property for
  this.)

* "-wrap word" does not wrap.

* I see artifacts when I go through a (not) wrapped text with the
  cursor.

* Pressing the key "Left" with cursor at the end of an RTL line (that
  is, at the left side of the line) goes to the line up instead of going
  down.  In theory it is arguable where this should logically go, but
  when I am moving the cursor forward through a text, I expect the
  cursor to go down when I reach the end of the line.

* The keys "Pos1" and "End" go to the wrong side of an RTL line.

I should say that I am not a native speaker of any language written in
an RTL script, so my expectations may be off.

I'm attaching my test case.

benny

Re: [TCLCORE] Bidi text

[Kevin W. <kw...@co...>]

<html class="apple-mail-supports-explicit-dark-mode"><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Certainly!<br id="lineBreakAtBeginningOfSignature"><div dir="ltr"><div>—</div>Kevin Walzer kw...@co...</div><div dir="ltr"><br><blockquote type="cite">On Apr 29, 2026, at 10:37 AM, apn...@ya... wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><meta name="Generator" content="Microsoft Word 15 (filtered medium)"><!--[if gte mso 9]><xml>
<w:WordDocument>
<w:DontUseAdvancedTypographyReadingMail/>
<w:DontUseJustificationAdvancedTypographyReadingMail/>
<w:DontUseHyphenationAdvancedTypographyReadingMail/>
</w:WordDocument>
</xml><![endif]--><style>@font-face { font-family: "Cambria Math"; }
@font-face { font-family: Calibri; }
@font-face { font-family: Aptos; }
@font-face { font-family: Tahoma; }
p.MsoNormal, li.MsoNormal, div.MsoNormal { margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif; }
a:link, span.MsoHyperlink { color: blue; text-decoration: underline; }
span.EmailStyle19 { font-family: Aptos, sans-serif; color: windowtext; }
.MsoChpDefault { font-size: 10pt; }
@page WordSection1 { size: 8.5in 11in; margin: 1in; }
div.WordSection1 { page: WordSection1; }</style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--><div class="WordSection1"><p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US">Kevin,<o:p></o:p></span></p><p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US"><o:p>&nbsp;</o:p></span></p><p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US">Please hold off on the merge for a couple of days. It sounds like a significant enough feature that it deserves a closer look and feedback. I will try to do that by the weekend (though I’m not sure I’m qualified to review, hopefully others will!). <o:p></o:p></span></p><p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US"><o:p>&nbsp;</o:p></span></p><p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US">/Ashok<o:p></o:p></span></p><p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US"><o:p>&nbsp;</o:p></span></p><div><div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in"><p class="MsoNormal" style="margin-left:.5in"><b><span lang="EN-US" style="font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif">From:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif"> Kevin Walzer &lt;kw...@co...&gt; <br><b>Sent:</b> Wednesday, April 29, 2026 3:57 AM<br><b>To:</b> tcl...@li...<br><b>Subject:</b> Re: [TCLCORE] Bidi text<o:p></o:p></span></p></div></div><p class="MsoNormal" style="margin-left:.5in"><o:p>&nbsp;</o:p></p><p class="MsoNormal" style="margin-left:.5in">Haven’t seen any feedback yet. I plan to merge the branch next week and call it done if no concerns are raised.&nbsp;<o:p></o:p></p><div><p class="MsoNormal" style="margin-left:.5in"><o:p>&nbsp;</o:p></p></div><div><p class="MsoNormal" style="margin-left:.5in">- Kevin<o:p></o:p></p><div><div><p class="MsoNormal" style="margin-left:.5in">—<o:p></o:p></p></div><p class="MsoNormal" style="margin-left:.5in">Kevin Walzer <a href="mailto:kw...@co...">kw...@co...</a><o:p></o:p></p></div><div><p class="MsoNormal" style="margin-left:.5in"><br><br><o:p></o:p></p><blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"><p class="MsoNormal" style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in">On Apr 25, 2026, at 9:29<span style="font-family:&quot;Arial&quot;,sans-serif"> </span>PM, Kevin Walzer &lt;<a href="mailto:kw...@co...">kw...@co...</a>&gt; wrote:<o:p></o:p></p></blockquote></div><blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"><div><p class="MsoNormal" style="margin-left:.5in"><span style="font-family:&quot;Tahoma&quot;,sans-serif"></span>One additional note. There are two remaining bugs with bidi text on Tk X11 that we probably need to document as known issues that cannot be corrected at this time:.&nbsp;<o:p></o:p></p><div><p class="MsoNormal" style="margin-left:.5in"><o:p>&nbsp;</o:p></p></div><div><p class="MsoNormal" style="margin-left:.5in">&nbsp;1. Harfbuzz badly renders CJK fonts with spacing that is too tight. Christian Werner has reported this, and I can reproduce it. This appears to be an upstream bug in Harfbuzz that will not be addressed:&nbsp;<a href="https://github.com/harfbuzz/harfbuzz/issues/4651?utm_source=copilot.com">https://github.com/harfbuzz/harfbuzz/issues/4651</a><o:p></o:p></p></div><div><p class="MsoNormal" style="margin-left:.5in"><o:p>&nbsp;</o:p></p></div><div><p class="MsoNormal" style="margin-left:.5in">&nbsp;2. &nbsp;RTL text gets subtly darker when I click the cursor through it then gets lighter when the cursor leaves. This is probably an upstream Xft drawing bug involving partial vs. full redraws in the XRender pipeline. I am not aware of a solution.&nbsp;<o:p></o:p></p></div><div><p class="MsoNormal" style="margin-left:.5in"><o:p>&nbsp;</o:p></p></div><div><p class="MsoNormal" style="margin-left:.5in">-Kevin<o:p></o:p></p><div><div><p class="MsoNormal" style="margin-left:.5in">—<o:p></o:p></p></div><p class="MsoNormal" style="margin-left:.5in">Kevin Walzer <a href="mailto:kw...@co...">kw...@co...</a><o:p></o:p></p></div><div><p class="MsoNormal" style="margin-left:.5in"><br><br><o:p></o:p></p><blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"><p class="MsoNormal" style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in">On Apr 25, 2026, at 7:33<span style="font-family:&quot;Arial&quot;,sans-serif"> </span>PM, Kevin Walzer &lt;<a href="mailto:kw...@co...">kw...@co...</a>&gt; wrote:<o:p></o:p></p></blockquote></div><blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"><div><p class="MsoNormal" style="margin-left:.5in"><span style="font-family:&quot;Tahoma&quot;,sans-serif"></span>Quick update:<br><br>1. I have modified "configure" to run "--enable-bidi" by default on X11. Bidi support is already the default on macOS and Windows.<br><br>2. I've spent a couple of days working on updating the test suite. I've modified six or seven tests to recognize different results because of the internal changes to bidi, set a win32 constraint on one test, and made a few tweaks to C code.<br><br>I think this is as good as I can make it, and I'd like to request some testing. I will be AFK next week for work, so this will give everyone some time to review the changes.<br><br>-Kevin<br><br>On 4/24/26 9:23 AM, Kevin Walzer wrote:<br><br><o:p></o:p></p><blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"><p class="MsoNormal" style="margin-left:.5in">The test failures may come later IMHO. Of cause, it is important.<o:p></o:p></p></blockquote><blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"><p class="MsoNormal" style="margin-left:.5in">But I would prefer first a comment by other experts, if they agree with the proposed change. <o:p></o:p></p></blockquote><p class="MsoNormal" style="margin-left:.5in"><br>-- <br>Kevin Walzer <a href="mailto:kw...@co...">kw...@co...</a><br><br><br><br>_______________________________________________<br>Tcl-Core mailing list<br><a href="mailto:Tcl...@li...">Tcl...@li...</a><br><a href="https://lists.sourceforge.net/lists/listinfo/tcl-core">https://lists.sourceforge.net/lists/listinfo/tcl-core</a><o:p></o:p></p></div></blockquote></div><p class="MsoNormal" style="margin-left:.5in">_______________________________________________<br>Tcl-Core mailing list<br><a href="mailto:Tcl...@li...">Tcl...@li...</a><br><a href="https://lists.sourceforge.net/lists/listinfo/tcl-core">https://lists.sourceforge.net/lists/listinfo/tcl-core</a><o:p></o:p></p></div></blockquote></div></div></div></blockquote></body></html>

Re: [TCLCORE] Bidi text

[<apn...@ya...>]

Kevin,

 

Please hold off on the merge for a couple of days. It sounds like a significant enough feature that it deserves a closer look and feedback. I will try to do that by the weekend (though I’m not sure I’m qualified to review, hopefully others will!). 

 

/Ashok

 

From: Kevin Walzer <kw...@co...> 
Sent: Wednesday, April 29, 2026 3:57 AM
To: tcl...@li...
Subject: Re: [TCLCORE] Bidi text

 

Haven’t seen any feedback yet. I plan to merge the branch next week and call it done if no concerns are raised. 

 

- Kevin

—

Kevin Walzer kw...@co... <mailto:kw...@co...> 





On Apr 25, 2026, at 9:29 PM, Kevin Walzer <kw...@co... <mailto:kw...@co...> > wrote:

One additional note. There are two remaining bugs with bidi text on Tk X11 that we probably need to document as known issues that cannot be corrected at this time:. 

 

 1. Harfbuzz badly renders CJK fonts with spacing that is too tight. Christian Werner has reported this, and I can reproduce it. This appears to be an upstream bug in Harfbuzz that will not be addressed: https://github.com/harfbuzz/harfbuzz/issues/4651 <https://github.com/harfbuzz/harfbuzz/issues/4651?utm_source=copilot.com> 

 

 2.  RTL text gets subtly darker when I click the cursor through it then gets lighter when the cursor leaves. This is probably an upstream Xft drawing bug involving partial vs. full redraws in the XRender pipeline. I am not aware of a solution. 

 

-Kevin

—

Kevin Walzer kw...@co... <mailto:kw...@co...> 





On Apr 25, 2026, at 7:33 PM, Kevin Walzer <kw...@co... <mailto:kw...@co...> > wrote:

Quick update:

1. I have modified "configure" to run "--enable-bidi" by default on X11. Bidi support is already the default on macOS and Windows.

2. I've spent a couple of days working on updating the test suite. I've modified six or seven tests to recognize different results because of the internal changes to bidi, set a win32 constraint on one test, and made a few tweaks to C code.

I think this is as good as I can make it, and I'd like to request some testing. I will be AFK next week for work, so this will give everyone some time to review the changes.

-Kevin

On 4/24/26 9:23 AM, Kevin Walzer wrote:



The test failures may come later IMHO. Of cause, it is important.

But I would prefer first a comment by other experts, if they agree with the proposed change. 


-- 
Kevin Walzer kw...@co... <mailto:kw...@co...> 



_______________________________________________
Tcl-Core mailing list
Tcl...@li... <mailto:Tcl...@li...> 
https://lists.sourceforge.net/lists/listinfo/tcl-core

_______________________________________________
Tcl-Core mailing list
Tcl...@li... <mailto:Tcl...@li...> 
https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] CFV: TIP 735 "Simpler List Filtering", TIP 745 "Functions from C99"

[Florent M. <flo...@gm...>]

Le 29/04/2026 à 10:24, Donal Fellows a écrit :
> The voting at this stage indicates that, yes, it (probably) is justified.
You misunderstand the justification for the votes: It is sometimes to be 
found more in the laws that govern organizations than in the utilitarian 
and technical relevance of the proposal.

Ask people if they vote "yes" because they have a real and urgent need 
of this command.

> Otherwise, we could do it all with just a *while* loop (as *for *is a 
> specialisation of that, and *foreach * is a specialisation of that, 
> and *lmap *is a specialisation of that in turn, and *lfilter *is a 
> specialisation of that... Going more primitive than *while* is awkward 
> in conventional Tcl).
>
> Going extremely general for everything ends up building a system 
> that's difficult to use. It's a fundamental trade-off.
>
> Donal.
>
The complexity of too much abstraction exists, of course.
But why do human beings resort to abstraction? To make reality less complex.

Indeed, a large number of simple things is no less complex than a 
single, highly abstract thing.
That's why human beeings think by categories, to simplify reality.

So multiplying simple commands will not making Tcl less complex. Put 
yourself in the shoes of a Tcl beginner.

There's a balance to be struck between having commands that aren't too 
abstract while maintaining a reasonable number of commands.

You will spent time on this command, wheras everybody can write it in 5 
lines of Tcl script.

This will add yet another line to an already full manual, obscuring the 
really important commands.

There is already 17th command just for list !!!

Regards

Florent.
> ------------------------------------------------------------------------
> *From:* Florent Merlet <flo...@gm...>
> *Sent:* Tuesday, April 28, 2026 20:44
> *To:* tcl...@li... <tcl...@li...>
> *Subject:* Re: [TCLCORE] CFV: TIP 735 "Simpler List Filtering", TIP 
> 745 "Functions from C99"
>
> Does such a limited use case justify introducing a new command ?
>

Re: [TCLCORE] Question on emojis and no-bidi configuration options

[Jan N. <jan...@gm...>]

Op wo 29 apr 2026 om 11:58 schreef Kevin Walzer <kw...@co...>:

> ::tk::build-info returns “no-xft” if bidi support is turned on, so emojis
> don’t display in the widget demo.
>
>
>
> And what is the dependency on bidi/no-bidi for emoji support?
>
>
> I believe Jan was the one who added this change. It broke emoli display,
> likely unintentionally.
>

So, that's wrong!  no-xft should not be set if bidi-support is on. I'll
have a look

Thanks!
       Jan Nijtmans

Re: [TCLCORE] Question on emojis and no-bidi configuration options

[Kevin W. <kw...@co...>]

<html class="apple-mail-supports-explicit-dark-mode"><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><br id="lineBreakAtBeginningOfSignature"><div dir="ltr"><div>—</div>Kevin Walzer kw...@co...</div><div dir="ltr"><br><blockquote type="cite">On Apr 29, 2026, at 2:05 AM, apn...@ya... wrote:<br></blockquote></div><blockquote type="cite"><div dir="ltr"><div class="WordSection1"><p class="MsoNormal"><o:p>&nbsp;</o:p></p><p class="MsoNormal">Question about this <a href="https://core.tcl-lang.org/tk/fdiff?v1=8290d0f8233b7e60&amp;v2=2ee29119c2a85451&amp;proof=515536268">Tk commit</a> on trunk.<o:p></o:p></p><p class="MsoNormal"><o:p>&nbsp;</o:p></p><p class="MsoNormal">Doesn’t this change the sense of the no-xft check?</p></div></div></blockquote><div><br></div>::tk::build-info returns “no-xft” if bidi support is turned on, so emojis don’t display in the widget demo.&nbsp;<br><blockquote type="cite"><div dir="ltr"><div class="WordSection1"><p class="MsoNormal"><o:p></o:p></p><p class="MsoNormal"><o:p>&nbsp;</o:p></p><p class="MsoNormal">And what is the dependency on bidi/no-bidi for emoji support?</p></div></div></blockquote><div><br></div>I believe Jan was the one who added this change. It broke emoli display, likely unintentionally.&nbsp;<br><blockquote type="cite"><div dir="ltr"><div class="WordSection1"><p class="MsoNormal"><o:p></o:p></p></div></div></blockquote><style>@font-face { font-family: "Cambria Math"; }
@font-face { font-family: Aptos; }
p.MsoNormal, li.MsoNormal, div.MsoNormal { margin: 0in; font-size: 11pt; font-family: Aptos, sans-serif; }
a:link, span.MsoHyperlink { color: rgb(70, 120, 134); text-decoration: underline; }
span.EmailStyle17 { font-family: Aptos, sans-serif; color: windowtext; }
.MsoChpDefault { font-size: 11pt; }
@page WordSection1 { size: 8.5in 11in; margin: 1in; }
div.WordSection1 { page: WordSection1; }</style><div><br></div><div>- Kevin</div></body></html>

Re: [TCLCORE] CFV: TIP 735 "Simpler List Filtering", TIP 745 "Functions from C99"

[Donal F. <don...@ma...>]

The voting at this stage indicates that, yes, it (probably) is justified. Otherwise, we could do it all with just a while loop (as for is a specialisation of that, and foreach is a specialisation of that, and lmap is a specialisation of that in turn, and lfilter is a specialisation of that... Going more primitive than while is awkward in conventional Tcl).

Going extremely general for everything ends up building a system that's difficult to use. It's a fundamental trade-off.

Donal.

________________________________
From: Florent Merlet <flo...@gm...>
Sent: Tuesday, April 28, 2026 20:44
To: tcl...@li... <tcl...@li...>
Subject: Re: [TCLCORE] CFV: TIP 735 "Simpler List Filtering", TIP 745 "Functions from C99"

Does such a limited use case justify introducing a new command ?

Re: [TCLCORE] Question on emojis and no-bidi configuration options

[Jan N. <jan...@gm...>]

Op wo 29 apr 2026 om 09:05 schreef apnmbx-public--- via Tcl-Core <
tcl...@li...>:

> Kevin,
>
>
>
> Question about this Tk commit
> <https://core.tcl-lang.org/tk/fdiff?v1=8290d0f8233b7e60&v2=2ee29119c2a85451&proof=515536268>
> on trunk.
>
>
>
> Doesn’t this change the sense of the no-xft check?
>
>
>
> And what is the dependency on bidi/no-bidi for emoji support?
>

I also had the same doubt, seeing this commit.  I don't think
bibi-support has any relation to whether emoji's are supported
or not, so I think this commit is wrong. I suggest to revert it.

Thanks, Ashok, for reminding me. I saw it, but didn't take
the time to reply.

Regards,
        Jan Nijtmans

[TCLCORE] Question on emojis and no-bidi configuration options

[<apn...@ya...>]

Kevin,

 

Question about this Tk commit
<https://core.tcl-lang.org/tk/fdiff?v1=8290d0f8233b7e60&v2=2ee29119c2a85451&
proof=515536268>  on trunk.

 

Doesn't this change the sense of the no-xft check?

 

And what is the dependency on bidi/no-bidi for emoji support?

 

/Ashok

Re: [TCLCORE] Starkits for Tcl 9

[Steve L. <st...@di...>]

"zip" is an implementation detail not a feature.  I strongly advocate that we stick with the nomenclature that has worked for the last quarter century.

Did Microsoft rename Excel to Zipcell when the file format changed to the zip-based Open XML format in 2007?

-- Steve
On 29 Apr 2026 at 2:05 PM +0800, CloudTk <hea...@ya...>, wrote:
> I strongly agree with preserving the "tclkit" + starkit style format as a distribution mechanism for Tcl applications. I distribute CloudTk as a single starkit, with binary extensions for different platforms and plans for more in the future. Also I use starkits when building docker containers, especially for use in over 100 online demos on the Tcler's Wiki. Most of the starkits used for the demos, I am sure will run with Tcl9. So I agree with all the package goals that Keith has listed.
>
> One thing that has me very confused at the moment is "What is a zipkit?". When I first heard about zipkits I was under the impression that it was, as Steve Landers mentioned, "zipkits are the modern starkits". Now I get the impression that a zipkit is a modern tclkit? For me "zipkits are the modern starkits" makes most sense. I think at this early stage of the project the terminology is important. (What's in a name? Honestly ... everything.)
>
> Kind Regards
>
> Jeff
> On Monday 27 April 2026 at 09:55:10 pm AEST, Kevin Walzer <kw...@co...> wrote:
>
>
> 💯
> —
> Kevin Walzer kw...@co...
>
> > On Apr 27, 2026, at 5:34 AM, Steve Landers <st...@di...> wrote:
> >
> > Zipkits are the modern starkits.  Why oh why can't we just call them that?
> >
> > As for core vs package, my personal view is the functionality to create a star/zipkit should be in every Tcl build.   Put the compatibility stuff in a separate package if we must but why do we constantly look for ways to make it harder to use Tcl?
> >
> > -- Steve
> > On 27 Apr 2026 at 4:43 PM +0800, Harald Oehlmann <har...@el...>, wrote:
> > > Dear Keith,
> > > thanks for your great work!
> > > Here is my personal opinion:
> > > I am not to much in favour of having starkit functionality in the core.
> > > We have zipkits now and look foreward.
> > > zipkits and starkits are quite similar.
> > > I personally use something like this for my own compatibility in main.tcl:
> > >
> > > if {[string equal -length 8 "//zipfs:" [info script]]} {
> > > namespace eval starkit [list variable topdir [file dirname [info script]]]
> > > } else {
> > > package require starkit
> > > starkit::startup
> > > }
> > >
> > > The other differences (zip wrap does not exclude .csv, no windows icon
> > > replacement) are handled outside.
> > >
> > > WouldnÄt it be ok to have this in a package?
> > >
> > > Thanks for all,
> > > Harald
> > >
> > >
> > > Am 26.04.2026 um 11:15 schrieb KEITH NASH:
> > > > Hi All,
> > > >
> > > > Version 2.1.0 of package starkit is available, including documentation and
> > > > tests.
> > > >
> > > > https://chiselapp.com/user/kjnash/repository/Starkit/home
> > > >
> > > > The package goals are to:
> > > >
> > > > 1. enable zip-based starkits that can be executed by a Tcl 9 installation or
> > > > by a "tclkit" (zipkit)
> > > > 2. provide the same facilities for zip-based starkits that version 1.3.3 of
> > > > starkit package provides for mk4 (Metakit) starkits
> > > > 3. make porting from mk4 starkits as easy as possible
> > > > * if its code is Tcl-9-compatible, unwrapping the mk4 starkit and
> > > > rewrapping it in zip format will suffice
> > > > 4. run mk4 starkits without modification if their code is Tcl-9-compatible
> > > > * EITHER the Tcl 9 installation or Tclkit must provide dynamic libraries
> > > > for vlerq and vfs
> > > > * OR starkit will use the included package readkit (which still has bugs)
> > > > to unwrap the mk4 archive
> > > > 5. preserve the tclkit + starkit format as a distribution mechanism for Tcl
> > > > applications
> > > >
> > > > All that is needed to make Tcl 9 compatible with zip-based starkits is to
> > > > provide the starkit library (29kB source, 17kB if comments stripped, plus 20kB
> > > > if readkit is needed for mk4 packages).
> > > >
> > > > The starkit package could be included in the tcl_library.
> > > >
> > > > I would be willing to write a TIP for this if it is wanted. A few issues to
> > > > discuss first:
> > > > * Are starkit facilities still wanted? I use them in my own work, but they
> > > > seem to have lost popularity over the last 20 years.
> > > > * Are the goals/features listed above suitable? For example, the package
> > > > could be smaller and simpler if mk4 compatibility is not required.
> > > > * The library is derived from starkit package version 1.3.3 by JCW, which did
> > > > not have a license statement. Will this matter?
> > > > * Version 2 of the starkit package is compatible with Tcl 9.0 upwards, because
> > > > it uses Tcl's zipfs facilities. Which version of Tcl should the TIP target?
> > > >
> > > > Keith.
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Tcl-Core mailing list
> > > > Tcl...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/tcl-core
> > >
> > >
> > > --
> > > ELMICRON Dr. Harald Oehlmann GmbH
> > > Koesener Str. 85
> > > 06618 NAUMBURG - Germany
> > > Phone: +49 3445 781120
> > > Direct: +49 3445 781127
> > > www.Elmicron.de
> > > German legal references:
> > > Geschaeftsfuehrer: Dr. Harald Oehlmann
> > > UST Nr. / VAT ID No.: DE206105272
> > > HRB 212803 Stendal
> > >
> > >
> > > _______________________________________________
> > > Tcl-Core mailing list
> > > Tcl...@li...
> > > https://lists.sourceforge.net/lists/listinfo/tcl-core
> > _______________________________________________
> > Tcl-Core mailing list
> > Tcl...@li...
> > https://lists.sourceforge.net/lists/listinfo/tcl-core
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] Starkits for Tcl 9

[CloudTk <hea...@ya...>]

 I strongly agree with preserving the "tclkit" + starkit style format as a distribution mechanism for Tcl applications. I distribute CloudTk as a single starkit, with binary extensions for different platforms and plans for more in the future. Also I use starkits when building docker containers, especially for use in over 100 online demos on the Tcler's Wiki. Most of the starkits used for the demos, I am sure will run with Tcl9. So I agree with all the package goals that Keith has listed.

One thing that has me very confused at the moment is "What is a zipkit?". When I first heard about zipkits I was under the impression that it was, as Steve Landers mentioned, "zipkits are the modern starkits". Now I get the impression that a zipkit is a modern tclkit? For me "zipkits are the modern starkits" makes most sense. I think at this early stage of the project the terminology is important. (What's in a name? Honestly ... everything.) 
Kind Regards
Jeff    On Monday 27 April 2026 at 09:55:10 pm AEST, Kevin Walzer <kw...@co...> wrote:  
 
 💯
—Kevin Walzer kw...@co...

On Apr 27, 2026, at 5:34 AM, Steve Landers <st...@di...> wrote:




Zipkits are the modern starkits.  Why oh why can't we just call them that? 

As for core vs package, my personal view is the functionality to create a star/zipkit should be in every Tcl build.   Put the compatibility stuff in a separate package if we must but why do we constantly look for ways to make it harder to use Tcl?
-- SteveOn 27 Apr 2026 at 4:43 PM +0800, Harald Oehlmann <har...@el...>, wrote:

Dear Keith,
thanks for your great work!
Here is my personal opinion:
I am not to much in favour of having starkit functionality in the core.
We have zipkits now and look foreward.
zipkits and starkits are quite similar.
I personally use something like this for my own compatibility in main.tcl:

if {[string equal -length 8 "//zipfs:" [info script]]} {
namespace eval starkit [list variable topdir [file dirname [info script]]]
} else {
package require starkit
starkit::startup
}

The other differences (zip wrap does not exclude .csv, no windows icon
replacement) are handled outside.

WouldnÄt it be ok to have this in a package?

Thanks for all,
Harald


Am 26.04.2026 um 11:15 schrieb KEITH NASH:

Hi All,

Version 2.1.0 of package starkit is available, including documentation and
tests.

https://chiselapp.com/user/kjnash/repository/Starkit/home

The package goals are to:

1. enable zip-based starkits that can be executed by a Tcl 9 installation or
by a "tclkit" (zipkit)
2. provide the same facilities for zip-based starkits that version 1.3.3 of
starkit package provides for mk4 (Metakit) starkits
3. make porting from mk4 starkits as easy as possible
* if its code is Tcl-9-compatible, unwrapping the mk4 starkit and
rewrapping it in zip format will suffice
4. run mk4 starkits without modification if their code is Tcl-9-compatible
* EITHER the Tcl 9 installation or Tclkit must provide dynamic libraries
for vlerq and vfs
* OR starkit will use the included package readkit (which still has bugs)
to unwrap the mk4 archive
5. preserve the tclkit + starkit format as a distribution mechanism for Tcl
applications

All that is needed to make Tcl 9 compatible with zip-based starkits is to
provide the starkit library (29kB source, 17kB if comments stripped, plus 20kB
if readkit is needed for mk4 packages).

The starkit package could be included in the tcl_library.

I would be willing to write a TIP for this if it is wanted. A few issues to
discuss first:
* Are starkit facilities still wanted? I use them in my own work, but they
seem to have lost popularity over the last 20 years.
* Are the goals/features listed above suitable? For example, the package
could be smaller and simpler if mk4 compatibility is not required.
* The library is derived from starkit package version 1.3.3 by JCW, which did
not have a license statement. Will this matter?
* Version 2 of the starkit package is compatible with Tcl 9.0 upwards, because
it uses Tcl's zipfs facilities. Which version of Tcl should the TIP target?

Keith.



_______________________________________________
Tcl-Core mailing list
Tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcl-core



--
ELMICRON Dr. Harald Oehlmann GmbH
Koesener Str. 85
06618 NAUMBURG - Germany
Phone: +49 3445 781120
Direct: +49 3445 781127
www.Elmicron.de
German legal references:
Geschaeftsfuehrer: Dr. Harald Oehlmann
UST Nr. / VAT ID No.: DE206105272
HRB 212803 Stendal


_______________________________________________
Tcl-Core mailing list
Tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcl-core

_______________________________________________
Tcl-Core mailing list
Tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcl-core
_______________________________________________
Tcl-Core mailing list
Tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcl-core
  

Re: [TCLCORE] Update on TIP 740 Enhanced Treeview Widget

[Brian O’H. <bri...@co...>]

Thanks. I’ll look these over and get back to you. I’m in the process of fighting with fossil to get this into a Tk branch. Hopefully I will have that done in the next day or two.


> On Apr 28, 2026, at 12:55 PM, Csaba Nemethi <csa...@t-...> wrote:
> 
> Hi Brian,
> 
> I have a few more remarks regarding the enhanced treeview widget:
> 
> 1. In the files ttkClassicTheme.c, ttkDefaultTheme.c, and ttkTreeview.c you set the default value of the "-indicatormargin" option of the Heading element to {3p 1.5p 1.5p 1.5p}.  OTOH, in altTheme.tcl, clamTheme.tcl, classicTheme.tcl, defaults.tcl, and winTheme.tcl you override this value by {3 1 2 1}.  This is confusing and IMHO not OK, because {3 1 2 1} is not scalable.
> 
> 2. In the files ttkTreeview.c and winTheme.tcl you set the default value of the "-indicatorsize" option of the Heading element to 3.5p, contrary to the other above-mentioned C and Tcl files, where it is set to 3p. Apart from being confusing, I wonder why you chose 3.5p, which on an unscaled screen translates to 4.666... px, i.e., 5 px.  BTW, on an unscaled screen, 5 px corresponds to exactly 3.75p.  My proposal: Eliminate these inconsistencies by using exclusively the value 3p.
> 
> 3. There are several similar issues regarding the default value of the "-indicatorsize" option of the Item element.  My proposal:  (a) In ttkClassicTheme.c, ttkDefaultTheme.c, altTheme.tcl, classicTheme.tcl, and winTheme.tcl use the value 6.75p, and (b) in ttkTreeview.c, clamTheme.tcl, and defaults.tcl use the value 3p.
> 
> 4. The item indicators of the themes alt, classic, and winnative don't look as expected: their height is larger than their width.  This is caused by the last 5 lines of the body of the TreeitemIndicatorSize() function in the files ttkDefaultTheme.c and ttkClassicTheme.c.  Please remove these lines.  In addition, re-add the line
> 
>    if (size % 2 == 0) --size;  /* An odd size is better for the indicator. */
> 
> just after line 1473 of ttkDefaultTheme.c and after line 970 of ttkClassicTheme.c.
> 
> 5. In ttkTreeview.c, the body of the function TreeitemIndicatorDraw() should be free of occurrences of ARROW_DOWN and ARROW_RIGHT.  Please replace them with CHEVRON_DOWN and CHEVRON_RIGHT.
> 
> 6. With the "default" theme the selected items become invisible when the treeview loses the focus.  This is caused by the identical lines 209 and 213 of the file defaults.tcl.  To fix this, please replace these lines with
> 
>                                background $colors(-darker) \
> 
> and
> 
>                                background $colors(-selectfg) \
> 
> respectively.
> 
> Best regards,
> 
> Csaba
> 
> --
> Csaba Nemethi  https://www.nemethi.de  mailto:csa...@t-...
> 

Re: [TCLCORE] Bidi text

[Kevin W. <kw...@co...>]

<html class="apple-mail-supports-explicit-dark-mode"><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Haven’t seen any feedback yet. I plan to merge the branch next week and call it done if no concerns are raised.&nbsp;<div><br></div><div>- Kevin<br id="lineBreakAtBeginningOfSignature"><div dir="ltr"><div>—</div>Kevin Walzer kw...@co...</div><div dir="ltr"><br><blockquote type="cite">On Apr 25, 2026, at 9:29 PM, Kevin Walzer &lt;kw...@co...&gt; wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><meta http-equiv="content-type" content="text/html; charset=utf-8">One additional note. There are two remaining bugs with bidi text on Tk X11 that we probably need to document as known issues that cannot be corrected at this time:.&nbsp;<div><br></div><div>&nbsp;1. Harfbuzz badly renders CJK fonts with spacing that is too tight. Christian Werner has reported this, and I can reproduce it. This appears to be an upstream bug in Harfbuzz that will not be addressed:&nbsp;<a href="https://github.com/harfbuzz/harfbuzz/issues/4651?utm_source=copilot.com">https://github.com/harfbuzz/harfbuzz/issues/4651</a></div><div><br></div><div>&nbsp;2. &nbsp;RTL text gets subtly darker when I click the cursor through it then gets lighter when the cursor leaves. This is probably an upstream Xft drawing bug involving partial vs. full redraws in the XRender pipeline. I am not aware of a solution.&nbsp;</div><div><br></div><div>-Kevin<br id="lineBreakAtBeginningOfSignature"><div dir="ltr"><div>—</div>Kevin Walzer kw...@co...</div><div dir="ltr"><br><blockquote type="cite">On Apr 25, 2026, at 7:33 PM, Kevin Walzer &lt;kw...@co...&gt; wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><span>Quick update:</span><br><span></span><br><span>1. I have modified "configure" to run "--enable-bidi" by default on X11. Bidi support is already the default on macOS and Windows.</span><br><span></span><br><span>2. I've spent a couple of days working on updating the test suite. I've modified six or seven tests to recognize different results because of the internal changes to bidi, set a win32 constraint on one test, and made a few tweaks to C code.</span><br><span></span><br><span>I think this is as good as I can make it, and I'd like to request some testing. I will be AFK next week for work, so this will give everyone some time to review the changes.</span><br><span></span><br><span>-Kevin</span><br><span></span><br><span>On 4/24/26 9:23 AM, Kevin Walzer wrote:</span><br><blockquote type="cite"><span>The test failures may come later IMHO. Of cause, it is important.</span><br></blockquote><blockquote type="cite"><span>But I would prefer first a comment by other experts, if they agree with the proposed change. </span><br></blockquote><span></span><br><span>-- </span><br><span>Kevin Walzer kw...@co...</span><br><span></span><br><span></span><br><span></span><br><span>_______________________________________________</span><br><span>Tcl-Core mailing list</span><br><span>Tcl...@li...</span><br><span>https://lists.sourceforge.net/lists/listinfo/tcl-core</span><br></div></blockquote></div><span>_______________________________________________</span><br><span>Tcl-Core mailing list</span><br><span>Tcl...@li...</span><br><span>https://lists.sourceforge.net/lists/listinfo/tcl-core</span><br></div></blockquote></div></body></html>

Re: [TCLCORE] CFV: TIP 735 "Simpler List Filtering", TIP 745 "Functions from C99"

[Marc C. <cul...@gm...>]

TIP 735: yes
TIP 745: yes

- Marc

On Sun, Apr 26, 2026 at 6:03 AM Donal Fellows <
don...@ma...> wrote:

> Hi everyone
>
> This is a call for votes on two self-contained TIPs that I've been sitting
> on for far too long.
>
> TIP 735: Simpler List Filtering
> <https://core.tcl-lang.org/tips/doc/trunk/tip/735.md>
> This adds a global *lfilter *command, because the current idiom for
> filtering out items of a list (when *lsearch -inline -all -not* can't do
> it) is weird. I've tried using an expression for the filter (that was the
> initial version of the TIP *but not the current one*), which works but
> feels more annoying to me than using a script (with expressions available
> by calling *expr*). I can be talked round to doing this the other way,
> but the current way is marginally simpler to implement (on the interpreted
> side; the compiled version is pretty much identically complex).
>
> TIP 745: Functions from C99
> <https://core.tcl-lang.org/tips/doc/trunk/tip/745.md>
> This imports virtually all the remaining math functions from C99
> <https://en.cppreference.com/w/c/numeric/math.html> into Tcl, pretty much
> as-is (bearing in mind that some "return" multiple values, which maps
> differently in Tcl; see below) with most just going into the
> *::tcl::mathfunc* namespace and so having limited global impact.
> Implementation bugs in the functions' C implementations are exactly bugs in
> the corresponding Tcl functions; I do not propose we reimplement them
> (except for *signbit*, which is extended to directly cover all Tcl
> numeric values).
> *NB:* Introduces four new global commands for the
> multiple-value-returners: * divmod*, *frexp*, *modf*, *remquo*. They
> don't sit nicely as standard functions.
>
> Implementation branches exist for both TIPs (tip-735
> <https://core.tcl-lang.org/tcl/timeline?r=tip-735>, c11-functions
> <https://core.tcl-lang.org/tcl/timeline?r=c11-functions>).
>
> Votes in the standard form to this mailing list. Vote closes at 12:00 my
> time, 4 May 2026, *[clock format 1777892400]*. My votes follow:
>
>   TIP 735: YES
>   TIP 745: YES
>
> Donal.
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Re: [TCLCORE] Side question about the lmap documentation ... Re: CFV: TIP 735 "Simpler List Filtering", TIP 745 "Functions from C99"

[Florent M. <flo...@gm...>]

Hi Peter, Harald, Kevin,
Hi All

With my expr shorthand 
<https://github.com/florentis/tcl90-exprSH/tree/core-9-0-branch/install_SH> 
you can choose between :

- either enclosing*the lmap script* into parenthesis to take it as an 
expression :

set values {1 2 3 4 5 6 7 8}

set goodOnes [lmap x /$values/ {( /$x/ % 2 == 0 ? /$x/ : [continue] )}]

- either enclosing*the then body *into parenthesis to take it as an 
expression (there is no need to use set or return) :

set goodOnes [lmap x /$values/ { if {/$x/ % 2 == 0} then *(/$x/)* else 
continue }]

Furthermore, if command with (*$x*) is not only shorter, but 
also/faster/ than if command with {set x}.

Anyway, obviously, that makes the code a lot more clear, isn't it ?

Regards,

Florent

Le 28/04/2026 à 17:30, da Silva, Peter J via Tcl-Core a écrit :
> set values {1 2 3 4 5 6 7 8}
> proc isEven {n} {expr {($n % 2) == 0}}
> set goodOnes [lmap x $values {expr { [isEven $x] ? $x : [continue] }}]
>
> Any particular reason this is expr {[isEven $x] ? $x : [continue]} 
> rather than if {[isEven $x]} {return $x} {continue} which seems a lot 
> more idiomatic, readable, and comprehensible to me.
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

-- 
<center>
<hr/>
<b>Florent MERLET</b><br/>
<i>4 rue Johann Strauss<br/>
Logement 7<br/>
86180 BUXEROLLES</i><br/>
<hr/>
<b>Mél.</b> : <i>flo...@gm...</i><br/>
<b>Tél.</b> : <i>06 70 00 63 48</i>
</center>

Re: [TCLCORE] CFV: TIP 735 "Simpler List Filtering", TIP 745 "Functions from C99"

[Florent M. <flo...@gm...>]

Hi Donal,

Does such a limited use case justify introducing a new command ?
In particular, reducing the program body to be only returning the first 
variable is a definite limitation.

Moreover, it is not difficult to create a generic script which include 
this behaviour, and add a lot more :

For instance (in my wish 
<https://github.com/florentis/tcl90-exprSH/tree/core-9-0-branch/install_SH>, 
with my script expr shorthand)

proc predicate_each {vars L switch} {
append script \{(
foreach {predicat body} $switch {
append script [format { [%s] ? [%s] : } $predicat $body ]
     }
append script  \[continue\]
append script )\}

lmap $vars $L {*}$script
}

Not only that script works like lfilter :

predicate_eachx [lseq 100] {
     (round($x**0.5)**2==$x) ($x)
}
-> 0 1 4 9 16 25 36 49 64 81

predicate_eachs {abc foo dad} {
     { # Is the string exactly equal to itself when reversed
string equal $s [string reverse $s]
     } ($s)
}
-> dad

But it can also :
- apply many tests (but exclusives from each other) to any mapped vars,
- apply many transformations to any mapped vars to produce the value

For example :
set L [list bold hello italic tcl underlined world ]

predicate_each {x y} $L {
     {( $x eq "bold" )} {( "<b>$y</b>" )}
     {regexp "italic" $x} {( "<i>$y</i>" )}
     {string match under* $x} {( "<u>$y</u>" )}
}
<b>hello</b> <i>tcl</i> <u>world</u>

The synopsis is :
*predicate_each */varlist list/ {/test body /?/test body /...?}

You'll find a complete set of procs about the common operations you were 
mentioning before in attachement.
They are all very tiny script. lmap is very powerfull indeed.

Regards

Florent

Le 27/04/2026 à 17:32, Donal Fellows a écrit :
> I tend to feel that operations shouldn't just be justified by a grand 
> plan. A wall is not just built by imagining it's totality, but also by 
> the placing of each brick where it belongs.
>
> For the operations you list:
>
>  *
>     Fold is obviated by variadic operators; we just do an expanded
>     application. It's a slightly different generalisation.
>  *
>     Take and Drop are just simple applications of *lrange*.
>  *
>     Nth is exactly within what *lindex *does.
>  *
>     Iota is *lseq*.
>
>
> Thinking about the other common operations in Python:
>
>  *
>     We could perhaps do with enumerate
>     <https://docs.python.org/3/library/functions.html#enumerate>(),
>     all <https://docs.python.org/3/library/functions.html#all>() and
>     any <https://docs.python.org/3/library/functions.html#any>()
>     sometime; they can be useful.
>  *
>     We don't have zip
>     <https://docs.python.org/3/library/functions.html#zip>(), but
>     don't need it so much either (again, that variadicity).
>  *
>     We don't agonise over the difference between tuples and lists, and
>     don't have /user-defined/ generators for various reasons at the
>     moment.
>  *
>     Sorting and searching by a collation key are annoying operations
>     right now, nor do we support min() or max() with a measure function.
>
>
> Thinking about operations from Java's List and ArrayList (similarly 
> for C# but with different names):
>
>  *
>     We've nothing like containsAll
>     <https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/List.html#containsAll(java.util.Collection)>()
>     or removeAll
>     <https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/List.html#removeAll(java.util.Collection)>()/retainAll().
>
>
> We could perhaps do with something like partition 
> <https://smlfamily.github.io/Basis/list.html#SIG:LIST.partition:VAL><https://smlfamily.github.io/Basis/list.html#SIG:LIST.partition:VAL>from 
> SML, though it might be low priority. You can probably list other 
> things from other languages, but I believe the above cover all the 
> common cases that we don't already have.
>
> We could also perhaps do with some operations more like those for 
> (insertion-time ordered, much as dicts are insertion-time ordered) 
> sets. They're reasonably useful. Linked lists and actual balanced 
> trees... not so useful except in special circumstances. I've never 
> missed having them!
>
> But this is a /huge /scope-creep relative to my TIP, so others may 
> pursue it, but I'll not do so here. I believe that *lfilter* is useful 
> in itself.
>
> Donal.
>
> ------------------------------------------------------------------------
> *From:* Pietro Cerutti
> *Sent:* Monday, April 27, 2026 09:54
> *To:* Donal Fellows
> *Cc:* Tcl Core
> *Subject:* Re: [TCLCORE] CFV: TIP 735 "Simpler List Filtering", TIP 
> 745 "Functions from C99"
>
> wouldn't it be better if we drafted a TIP for a complete
> set of list operations? Some of the functions of tcllib's struct::list
> such as reverse and map are already part of core (lreverse, lmap).
>
> How about we draft a set of function that we recognize being generally
> useful for lists and provide a complete set.  I can think of, e.g.,
> fold, take, drop, nth, iota.
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] Side question about the lmap documentation ... Re: CFV: TIP 735 "Simpler List Filtering", TIP 745 "Functions from C99"

[Kevin K. <kev...@gm...>]

If you wanted to use [return], it would be [return -level 0] - deliver the
value to the immediate context, not to the caller of the proc. But [set x]
would be more concise than [return -level 0 $x].



On Tue, Apr 28, 2026 at 11:46 AM Harald Oehlmann <
har...@el...> wrote:

> Am 28.04.2026 um 17:30 schrieb da Silva, Peter J via Tcl-Core:
> > set values {1 2 3 4 5 6 7 8}
> > proc isEven {n} {expr {($n % 2) == 0}}
> > set goodOnes [lmap x $values {expr { [isEven $x] ? $x : [continue] }}]
> >
> > Any particular reason this is expr {[isEven $x] ? $x : [continue]}
> > rather than if {[isEven $x]} {return $x} {continue} which seems a lot
> > more idiomatic, readable, and comprehensible to me.
> Great proposal! I would write it like:
> if {[isEven $x]} {set x} {continue}The "return" directly stops and sets
> the return value to "2".
>
> Try:
> catch {lmap a {1 2} {set a}} r
> -> 0
> r=1 2
>
> catch {lmap a {1 2} {return $a}} r
> -> 2 ( due to return, may raise error or other side-effects)
> r=2
>
> This is very strange, isn't it ;-)...
>
> Thanks for all,
> Harald
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>


-- 
73 de ke9tv/2, Kevin

Re: [TCLCORE] Side question about the lmap documentation ... Re: CFV: TIP 735 "Simpler List Filtering", TIP 745 "Functions from C99"

[da S. P. J <pet...@fl...>]

That's what I get for not testing my code. 😊

From: Harald Oehlmann <har...@el...>
Date: Tuesday, April 28, 2026 at 10:46
To: tcl...@li... <tcl...@li...>
Subject: Re: [TCLCORE] Side question about the lmap documentation ... Re: CFV: TIP 735 "Simpler List Filtering", TIP 745 "Functions from C99"

Am 28.04.2026 um 17:30 schrieb da Silva, Peter J via Tcl-Core:
> set values {1 2 3 4 5 6 7 8}
> proc isEven {n} {expr {($n % 2) == 0}}
> set goodOnes [lmap x $values {expr { [isEven $x] ? $x : [continue] }}]
>
> Any particular reason this is expr {[isEven $x] ? $x : [continue]}
> rather than if {[isEven $x]} {return $x} {continue} which seems a lot
> more idiomatic, readable, and comprehensible to me.
Great proposal! I would write it like:
if {[isEven $x]} {set x} {continue}The "return" directly stops and sets
the return value to "2".

Try:
catch {lmap a {1 2} {set a}} r
-> 0
r=1 2

catch {lmap a {1 2} {return $a}} r
-> 2 ( due to return, may raise error or other side-effects)
r=2

This is very strange, isn't it ;-)...

Thanks for all,
Harald

Re: [TCLCORE] Update on TIP 740 Enhanced Treeview Widget

[Csaba N. <csa...@t-...>]

Hi Brian,

I have a few more remarks regarding the enhanced treeview widget:

1. In the files ttkClassicTheme.c, ttkDefaultTheme.c, and ttkTreeview.c 
you set the default value of the "-indicatormargin" option of the 
Heading element to {3p 1.5p 1.5p 1.5p}.  OTOH, in altTheme.tcl, 
clamTheme.tcl, classicTheme.tcl, defaults.tcl, and winTheme.tcl you 
override this value by {3 1 2 1}.  This is confusing and IMHO not OK, 
because {3 1 2 1} is not scalable.

2. In the files ttkTreeview.c and winTheme.tcl you set the default value 
of the "-indicatorsize" option of the Heading element to 3.5p, contrary 
to the other above-mentioned C and Tcl files, where it is set to 3p. 
Apart from being confusing, I wonder why you chose 3.5p, which on an 
unscaled screen translates to 4.666... px, i.e., 5 px.  BTW, on an 
unscaled screen, 5 px corresponds to exactly 3.75p.  My proposal: 
Eliminate these inconsistencies by using exclusively the value 3p.

3. There are several similar issues regarding the default value of the 
"-indicatorsize" option of the Item element.  My proposal:  (a) In 
ttkClassicTheme.c, ttkDefaultTheme.c, altTheme.tcl, classicTheme.tcl, 
and winTheme.tcl use the value 6.75p, and (b) in ttkTreeview.c, 
clamTheme.tcl, and defaults.tcl use the value 3p.

4. The item indicators of the themes alt, classic, and winnative don't 
look as expected: their height is larger than their width.  This is 
caused by the last 5 lines of the body of the TreeitemIndicatorSize() 
function in the files ttkDefaultTheme.c and ttkClassicTheme.c.  Please 
remove these lines.  In addition, re-add the line

     if (size % 2 == 0) --size;  /* An odd size is better for the 
indicator. */

just after line 1473 of ttkDefaultTheme.c and after line 970 of 
ttkClassicTheme.c.

5. In ttkTreeview.c, the body of the function TreeitemIndicatorDraw() 
should be free of occurrences of ARROW_DOWN and ARROW_RIGHT.  Please 
replace them with CHEVRON_DOWN and CHEVRON_RIGHT.

6. With the "default" theme the selected items become invisible when the 
treeview loses the focus.  This is caused by the identical lines 209 and 
213 of the file defaults.tcl.  To fix this, please replace these lines with

                                 background $colors(-darker) \

and

                                 background $colors(-selectfg) \

respectively.

Best regards,

Csaba

-- 
Csaba Nemethi  https://www.nemethi.de  mailto:csa...@t-...