Menu
▾
▴
tcl-core — Tcl Core Team discussions about Tcl development
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(19) |
Jul
(96) |
Aug
(144) |
Sep
(222) |
Oct
(496) |
Nov
(171) |
Dec
(6) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(4) |
Feb
(4) |
Mar
(9) |
Apr
(4) |
May
(12) |
Jun
(6) |
Jul
|
Aug
|
Sep
(1) |
Oct
(2) |
Nov
|
Dec
|
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(52) |
Aug
(47) |
Sep
(47) |
Oct
(95) |
Nov
(56) |
Dec
(34) |
| 2003 |
Jan
(99) |
Feb
(116) |
Mar
(125) |
Apr
(99) |
May
(123) |
Jun
(69) |
Jul
(110) |
Aug
(130) |
Sep
(289) |
Oct
(211) |
Nov
(98) |
Dec
(140) |
| 2004 |
Jan
(85) |
Feb
(87) |
Mar
(342) |
Apr
(125) |
May
(101) |
Jun
(60) |
Jul
(151) |
Aug
(118) |
Sep
(162) |
Oct
(117) |
Nov
(125) |
Dec
(95) |
| 2005 |
Jan
(141) |
Feb
(54) |
Mar
(79) |
Apr
(83) |
May
(74) |
Jun
(125) |
Jul
(63) |
Aug
(89) |
Sep
(130) |
Oct
(89) |
Nov
(34) |
Dec
(39) |
| 2006 |
Jan
(98) |
Feb
(62) |
Mar
(56) |
Apr
(94) |
May
(169) |
Jun
(41) |
Jul
(34) |
Aug
(35) |
Sep
(132) |
Oct
(722) |
Nov
(381) |
Dec
(36) |
| 2007 |
Jan
(34) |
Feb
(174) |
Mar
(15) |
Apr
(35) |
May
(74) |
Jun
(15) |
Jul
(8) |
Aug
(18) |
Sep
(39) |
Oct
(125) |
Nov
(89) |
Dec
(129) |
| 2008 |
Jan
(176) |
Feb
(91) |
Mar
(69) |
Apr
(178) |
May
(310) |
Jun
(434) |
Jul
(171) |
Aug
(73) |
Sep
(187) |
Oct
(132) |
Nov
(259) |
Dec
(292) |
| 2009 |
Jan
(27) |
Feb
(54) |
Mar
(35) |
Apr
(54) |
May
(93) |
Jun
(10) |
Jul
(36) |
Aug
(36) |
Sep
(93) |
Oct
(52) |
Nov
(45) |
Dec
(74) |
| 2010 |
Jan
(20) |
Feb
(120) |
Mar
(165) |
Apr
(101) |
May
(56) |
Jun
(12) |
Jul
(73) |
Aug
(306) |
Sep
(154) |
Oct
(82) |
Nov
(63) |
Dec
(42) |
| 2011 |
Jan
(176) |
Feb
(86) |
Mar
(199) |
Apr
(86) |
May
(237) |
Jun
(50) |
Jul
(26) |
Aug
(56) |
Sep
(42) |
Oct
(62) |
Nov
(62) |
Dec
(52) |
| 2012 |
Jan
(35) |
Feb
(33) |
Mar
(128) |
Apr
(152) |
May
(133) |
Jun
(21) |
Jul
(74) |
Aug
(423) |
Sep
(165) |
Oct
(129) |
Nov
(387) |
Dec
(276) |
| 2013 |
Jan
(105) |
Feb
(30) |
Mar
(130) |
Apr
(42) |
May
(60) |
Jun
(79) |
Jul
(101) |
Aug
(46) |
Sep
(81) |
Oct
(14) |
Nov
(43) |
Dec
(4) |
| 2014 |
Jan
(25) |
Feb
(32) |
Mar
(30) |
Apr
(80) |
May
(42) |
Jun
(23) |
Jul
(68) |
Aug
(127) |
Sep
(112) |
Oct
(72) |
Nov
(29) |
Dec
(69) |
| 2015 |
Jan
(35) |
Feb
(49) |
Mar
(95) |
Apr
(10) |
May
(70) |
Jun
(64) |
Jul
(93) |
Aug
(85) |
Sep
(43) |
Oct
(38) |
Nov
(124) |
Dec
(29) |
| 2016 |
Jan
(253) |
Feb
(181) |
Mar
(132) |
Apr
(419) |
May
(68) |
Jun
(90) |
Jul
(52) |
Aug
(142) |
Sep
(131) |
Oct
(80) |
Nov
(84) |
Dec
(192) |
| 2017 |
Jan
(329) |
Feb
(842) |
Mar
(248) |
Apr
(85) |
May
(247) |
Jun
(186) |
Jul
(37) |
Aug
(73) |
Sep
(98) |
Oct
(108) |
Nov
(143) |
Dec
(143) |
| 2018 |
Jan
(155) |
Feb
(139) |
Mar
(72) |
Apr
(112) |
May
(82) |
Jun
(119) |
Jul
(24) |
Aug
(33) |
Sep
(179) |
Oct
(295) |
Nov
(111) |
Dec
(34) |
| 2019 |
Jan
(20) |
Feb
(29) |
Mar
(49) |
Apr
(89) |
May
(185) |
Jun
(131) |
Jul
(9) |
Aug
(59) |
Sep
(30) |
Oct
(44) |
Nov
(118) |
Dec
(53) |
| 2020 |
Jan
(70) |
Feb
(108) |
Mar
(50) |
Apr
(9) |
May
(70) |
Jun
(24) |
Jul
(103) |
Aug
(82) |
Sep
(132) |
Oct
(119) |
Nov
(174) |
Dec
(169) |
| 2021 |
Jan
(75) |
Feb
(51) |
Mar
(76) |
Apr
(73) |
May
(53) |
Jun
(120) |
Jul
(114) |
Aug
(73) |
Sep
(70) |
Oct
(18) |
Nov
(26) |
Dec
|
| 2022 |
Jan
(26) |
Feb
(63) |
Mar
(64) |
Apr
(64) |
May
(48) |
Jun
(74) |
Jul
(129) |
Aug
(106) |
Sep
(238) |
Oct
(169) |
Nov
(149) |
Dec
(111) |
| 2023 |
Jan
(110) |
Feb
(47) |
Mar
(82) |
Apr
(106) |
May
(168) |
Jun
(101) |
Jul
(155) |
Aug
(35) |
Sep
(51) |
Oct
(55) |
Nov
(134) |
Dec
(202) |
| 2024 |
Jan
(103) |
Feb
(129) |
Mar
(154) |
Apr
(89) |
May
(60) |
Jun
(162) |
Jul
(201) |
Aug
(61) |
Sep
(167) |
Oct
(111) |
Nov
(133) |
Dec
(141) |
| 2025 |
Jan
(122) |
Feb
(88) |
Mar
(106) |
Apr
(113) |
May
(203) |
Jun
(185) |
Jul
(124) |
Aug
(202) |
Sep
(176) |
Oct
(206) |
Nov
(259) |
Dec
(276) |
| 2026 |
Jan
(207) |
Feb
(180) |
Mar
(303) |
Apr
(390) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Kevin W. <kw...@co...> - 2026-04-30 19:33:14
|
I ran the test suite against rtl_text and trunk on my machine and here's what I see: rtl_text: Files with failing tests: event.test focus.test pack.test place.test send.test unixEmbed.test unixWm.test winfo.test wm.test Trunk: Files with failing tests: focus.test pack.test place.test send.test unixEmbed.test unixWm.test winfo.test wm.test Same failures on both, all pertaining to Wayland restrictions, except for one: event.test also fails on X11. These tests pertain to events in the text widget, which makes sense. Clearly I'll need to review them in regards to X11, and possibly Windows and macOS as well - let's see what the Github test runner shows. No merging will happen until the test suite is clean. - Kevin -- Kevin Walzer kw...@co... On Thu, Apr 30 2026 at 10:56:03 AM -04:00:00, Kevin Walzer <kw...@co...> wrote: > I am developing on Debian Trixie with Gnome, which has Wayland. > Running the test suite in the normal DE generates a TON of wm errors > because Wayland doesn’t let Tk do things that X11 does. Most of > those errors are Wayland noise unrelated to any changes I am making. > Running under xvfb gives a more accurate assessment of the test > suite. I’ve fixed all the text widget failures we were seeing. I > will review again when I am able. > — > Kevin Walzer kw...@co... > >> On Apr 30, 2026, at 10:44 AM, Jan Nijtmans >> <jan...@gm...> wrote: >> >> >> Op do 30 apr 2026 om 16:36 schreef Kevin Walzer <kw...@co... >> <mailto:kw...@co...>>: >>> Jan, >>> >>> The rtl_text branch has not been tested on Github. Where are you >>> seeing these failures? >> >> Just running on Ubuntu 26-04 LTS locally. >> >> Hope this helps, >> Jan Nijtmans |
|
From: Donald G P. <don...@ni...> - 2026-04-30 18:47:42
|
Now available at https://sourceforge.net/projects/tcl/files/Tcl/8.6.18/ are RC0 candidate source code distribution pre-releases of Tcl and Tk 8.6.18. These are the first candidate releases leading to the release of Tcl/Tk 8.6.18. The target date for release is May 11, 2026. The Tcl pre-release includes a pre-release of the package Thread 2.8.13, The released packages Itcl 4.3.7, TDBC* 1.1.13, and sqlite3 3.53.0 are also included. Please test these candidates on your platforms and report any blocking issues you discover. Thank you for your contributions and assistance. -- | Don Porter Applied and Computational Mathematics Division | | don...@ni... Information Technology Laboratory | | http://math.nist.gov/~DPorter/ NIST | |______________________________________________________________________| |
|
From: Kevin W. <kw...@co...> - 2026-04-30 14:56:30
|
<html class="apple-mail-supports-explicit-dark-mode"><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">I am developing on Debian Trixie with Gnome, which has Wayland. Running the test suite in the normal DE generates a TON of wm errors because Wayland doesn’t let Tk do things that X11 does. Most of those errors are Wayland noise unrelated to any changes I am making. Running under xvfb gives a more accurate assessment of the test suite. I’ve fixed all the text widget failures we were seeing. I will review again when I am able. <br id="lineBreakAtBeginningOfSignature"><div dir="ltr"><div>—</div>Kevin Walzer kw...@co...</div><div dir="ltr"><br><blockquote type="cite">On Apr 30, 2026, at 10:44 AM, Jan Nijtmans <jan...@gm...> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div dir="ltr">Op do 30 apr 2026 om 16:36 schreef Kevin Walzer <<a href="mailto:kw...@co...">kw...@co...</a>>:</div><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Jan,<div><br></div><div>The rtl_text branch has not been tested on Github. Where are you seeing these failures?</div></div></blockquote><div><br></div><div>Just running on Ubuntu 26-04 LTS locally.</div><div><br></div><div>Hope this helps,</div><div> Jan Nijtmans</div></div></div> </div></blockquote></body></html> |
|
From: da S. P. J <pet...@fl...> - 2026-04-30 14:46:38
|
I want to say that I don't remember when chan was introduced but I was very happy to discover it when I learned about it. From: Massimo Manghi <mas...@ri...> Date: Thursday, April 30, 2026 at 04:05 To: Steve Landers <st...@di...>; 'Donal Fellows' <don...@ma...>; 'Tcl Core' <tcl...@li...>; apn...@ya... <apn...@ya...> Subject: Re: [TCLCORE] CFV: TIP 735 "Simpler List Filtering", TIP 745 "Functions from C99" CAUTION - EXTERNAL EMAIL: This message originated from outside of your organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. My (less than) 2 cents I do not remember exactly when the `chan` command was introduced, but the individual commands it brought together into an ensemble — and in some cases replaced — had already existed for quite a long time. I understand that in many cases, and in most day-to-day use, `puts` is more convenient than `chan puts`. Still, chan is valuable because it gathers much of the channel-related functionality under a single ensemble, including the global commands that were already existing at the time of its introduction. When thinking about the future of Tcl, I would not give up on the idea of bringing that ship safely into harbor. There are 12 list-related commands, not counting `list` itself, and together they make up a significant portion of Tcl’s base command set which sounds to me as not entirely justifiable -- Massimo On 4/30/26 04:40, Steve Landers wrote: > I fear the list ensemble ship sailed decades ago, but I still see > value. From my perspective, a general principle is an ensemble command > is better than a namespace command which is better than a global command > which is better than new syntax. > > -- Steve > On 29 Apr 2026 at 12:45 AM +0800, apnmbx-public--- via Tcl-Core <tcl- > co...@li...>, wrote: >> >> An idle comment a little bit along the lines of what Pietro was >> saying ... at this point I presume we have abandoned the idea of a >> “list” ensemble command a la string. “lutil filter|zip” etc. Unlike >> Donal (if I understood him correctly), I do see a use for additional >> list commands beyond what Donal listed from Python. Presumably they >> will be all added as global commands if accepted. Otherwise, this >> might have been a good time to introduce an “lutil” ensemble with >> filter as a subcommand. >> >> /Ashok >> > > > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://urldefense.us/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_tcl-2Dcore&d=DwIGaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=PVRdKcuZI9OGim2pBXVs9DinZEGfgTQNd2_j5REEgvUGOKpaBCaDlen85fy02R2t&s=VDFhKChRTQUlWNTYcDRaG35SVwv35bchaLBOB1f-Hd0&e= _______________________________________________ Tcl-Core mailing list Tcl...@li... https://urldefense.us/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_tcl-2Dcore&d=DwIGaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=PVRdKcuZI9OGim2pBXVs9DinZEGfgTQNd2_j5REEgvUGOKpaBCaDlen85fy02R2t&s=VDFhKChRTQUlWNTYcDRaG35SVwv35bchaLBOB1f-Hd0&e= |
|
From: Jan N. <jan...@gm...> - 2026-04-30 14:44:08
|
Op do 30 apr 2026 om 16:36 schreef Kevin Walzer <kw...@co...>:
> Jan,
>
> The rtl_text branch has not been tested on Github. Where are you seeing
> these failures?
>
Just running on Ubuntu 26-04 LTS locally.
Hope this helps,
Jan Nijtmans
|
|
From: Kevin W. <kw...@co...> - 2026-04-30 14:36:50
|
Jan,
The rtl_text branch has not been tested on Github. Where are you seeing these failures?
-Kevin
—
Kevin Walzer kw...@co...
> On Apr 30, 2026, at 9:49 AM, Jan Nijtmans <jan...@gm...> wrote:
>
>
> Op wo 29 apr 2026 om 17:37 schreef apnmbx-public--- via Tcl-Core:
>> 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!).
>>
>
> I'm seeing test failures like:
> === unixWm-59.1 exit processing FAILED
> ==== Contents of test case:
>
> set script [makeFile {
> update
> exit
> } script]
> if {[catch {exec [interpreter] $script -geometry 10x10+0+0} msg]} {
> set error 1
> } else {
> set error 0
> }
> removeFile script
> list $error $msg
>
> ---- Result was:
> 1 {Fontconfig warning: using without calling FcInit()}
> ---- Result should have been (exact matching):
> 0 {}
>
> Zo, could you hold off the merge until the test-suite is failure-free? It's
> OK to disable some tests (or - better -restrict them for the no-bidi case),
> but it's not OK to turn Github Actions red for more than a few days.
>
> Regards,
> Jan Nijtmans
>
|
|
From: Jan N. <jan...@gm...> - 2026-04-30 13:50:02
|
Op wo 29 apr 2026 om 17:37 schreef apnmbx-public--- via Tcl-Core:
> 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!).
>
I'm seeing test failures like:
=== unixWm-59.1 exit processing FAILED
==== Contents of test case:
set script [makeFile {
update
exit
} script]
if {[catch {exec [interpreter] $script -geometry 10x10+0+0} msg]} {
set error 1
} else {
set error 0
}
removeFile script
list $error $msg
---- Result was:
1 {Fontconfig warning: using without calling FcInit()}
---- Result should have been (exact matching):
0 {}
Zo, could you hold off the merge until the test-suite is failure-free? It's
OK to disable some tests (or - better -restrict them for the no-bidi case),
but it's not OK to turn Github Actions red for more than a few days.
Regards,
Jan Nijtmans
|
|
From: Florent M. <flo...@gm...> - 2026-04-30 10:58:57
|
Hi Steve, Le 30/04/2026 à 04:40, Steve Landers a écrit : > I fear the list ensemble ship sailed decades ago, but I still see > value. From my perspective, a general principle is an ensemble > command is better than a namespace command which is better than a > global command which is better than new syntax. > This is a far too generic assertion. Here is a example of the usefullness that can give a new syntax, taken form a little parser I'm writing now, with the help of the expr shortand new syntax whose prototype can be found at : https://github.com/florentis/tcl90-exprSH/tree/core-9-0-branch/install_SH The shorthand expr version is 796 chars : timerate { namespace eval lex {( NODE_TYPE = 0xC0; BINARY = 0x40; UNARY = 0x80; LEAF = 0xC0; # Ambigous lexemes PLUS = 1; MINUS = 2; BAREWORD = 3; INCOMPLETE = 4; INVALID = 5; COMMENT = 6; # leaf lexemes NUMBER = $LEAF | 1; SCRIPT = $LEAF | 2; BRACED = $LEAF | 4; VARIABLE = $LEAF | 5; QUOTED = $LEAF | 6; EMPTY = $LEAF | 7; # unary operator lexemes UNARY_PLUS = $UNARY | $PLUS; UNARY_MINUS = $UNARY | $MINUS; START = $UNARY | 4; OPEN_PAREN = $UNARY | 5; # binary operators lexemes COMMA = $BINARY | 3; # list of index DOT = $BINARY | 4; # nested level CLOSE_PAREN = $BINARY | 5; RANGE = $BINARY | 6; )} } # 15.0767 µs/# 66327 # 66327.5 #/sec 999.992 net-ms The normal version is 950 chars : timerate { namespace eval lex { set NODE_TYPE 0xC0 set BINARY 0x40 set UNARY 0x80 set LEAF 0xC0 # Ambigous lexemes set PLUS 1 set MINUS 2 set BAREWORD 3 set INCOMPLETE 4 set INVALID 5 set COMMENT 6 # leaf lexemes set NUMBER [expr {$LEAF | 1}] set SCRIPT [expr {$LEAF | 2}] set BRACED [expr {$LEAF | 4}] set VARIABLE [expr {$LEAF | 5}] set QUOTED [expr {$LEAF | 6}] set EMPTY [expr {$LEAF | 7}] # unary operator lexemes set UNARY_PLUS [expr {$UNARY | $PLUS}] set UNARY_MINUS [expr {$UNARY | $MINUS}] set START [expr {$UNARY | 4}] set OPEN_PAREN [expr {$UNARY | 5}] # binary operators lexemes set COMMA [expr {$BINARY | 3}]; # list of index set DOT [expr {$BINARY | 4}]; # nested level set CLOSE_PAREN [expr {$BINARY | 5}] set RANGE [expr {$BINARY | 6}] } } # 15.5551 µs/# 77961 # 64287.7 #/sec 1212.689 net-ms 16 % chars less to write, more clear, more clean, less error prone, and at the end : exactly the same bytecode, so as fast as the original ! A richest syntax isn't an ennemy then, but an allie. Regards, Florent > -- Steve > On 29 Apr 2026 at 12:45 AM +0800, apnmbx-public--- via Tcl-Core > <tcl...@li...>, wrote: >> >> An idle comment a little bit along the lines of what Pietro was >> saying ... at this point I presume we have abandoned the idea of a >> “list” ensemble command a la string. “lutil filter|zip” etc. Unlike >> Donal (if I understood him correctly), I do see a use for additional >> list commands beyond what Donal listed from Python. Presumably they >> will be all added as global commands if accepted. Otherwise, this >> might have been a good time to introduce an “lutil” ensemble with >> filter as a subcommand. >> >> /Ashok >> > > > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core |
|
From: Massimo M. <mas...@ri...> - 2026-04-30 09:03:46
|
My (less than) 2 cents I do not remember exactly when the `chan` command was introduced, but the individual commands it brought together into an ensemble — and in some cases replaced — had already existed for quite a long time. I understand that in many cases, and in most day-to-day use, `puts` is more convenient than `chan puts`. Still, chan is valuable because it gathers much of the channel-related functionality under a single ensemble, including the global commands that were already existing at the time of its introduction. When thinking about the future of Tcl, I would not give up on the idea of bringing that ship safely into harbor. There are 12 list-related commands, not counting `list` itself, and together they make up a significant portion of Tcl’s base command set which sounds to me as not entirely justifiable -- Massimo On 4/30/26 04:40, Steve Landers wrote: > I fear the list ensemble ship sailed decades ago, but I still see > value. From my perspective, a general principle is an ensemble command > is better than a namespace command which is better than a global command > which is better than new syntax. > > -- Steve > On 29 Apr 2026 at 12:45 AM +0800, apnmbx-public--- via Tcl-Core <tcl- > co...@li...>, wrote: >> >> An idle comment a little bit along the lines of what Pietro was >> saying ... at this point I presume we have abandoned the idea of a >> “list” ensemble command a la string. “lutil filter|zip” etc. Unlike >> Donal (if I understood him correctly), I do see a use for additional >> list commands beyond what Donal listed from Python. Presumably they >> will be all added as global commands if accepted. Otherwise, this >> might have been a good time to introduce an “lutil” ensemble with >> filter as a subcommand. >> >> /Ashok >> > > > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core |
|
From: Arjen M. <Arj...@de...> - 2026-04-30 07:14:07
|
TIP 735: YES As Donal described, a script to return the decision gives more freedom, so in my opinion that is a good change. The alternative of an expression might be syntactically more elegant, but only in certain cases, like the [lseq] example in the TIP. TIP 745: YES This TIP adds new mathematical functions for use in [expr]. There could be a clash with extensions that already define such functions, but such an extension would override the new function, rather than the other way around. Regards, Arjen From: Steve Landers <st...@di...> Sent: 30 April 2026 04:36 To: Donal Fellows <don...@ma...> Cc: Tcl Core <tcl...@li...> Subject: Re: [TCLCORE] CFV: TIP 735 "Simpler List Filtering", TIP 745 "Functions from C99" Caution: This message was sent from outside of Deltares. Please do not click links or open attachments unless you recognize the source of this email and know the content is safe. Please report all suspicious emails to "Ser...@de...<mailto:Ser...@de...>" as an attachment. TIP 735: YES TIP 745: YES On 26 Apr 2026 at 1:03 PM +0800, schreef Donal Fellows <don...@ma...<mailto:don...@ma...>>, wrote: This is a call for votes on two self-contained TIPs that I've been sitting on for far too long. -- Steve DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
|
From: Steve L. <st...@di...> - 2026-04-30 02:58:57
|
I fear the list ensemble ship sailed decades ago, but I still see value. From my perspective, a general principle is an ensemble command is better than a namespace command which is better than a global command which is better than new syntax. -- Steve On 29 Apr 2026 at 12:45 AM +0800, apnmbx-public--- via Tcl-Core <tcl...@li...>, wrote: An idle comment a little bit along the lines of what Pietro was saying ... at this point I presume we have abandoned the idea of a “list” ensemble command a la string. “lutil filter|zip” etc. Unlike Donal (if I understood him correctly), I do see a use for additional list commands beyond what Donal listed from Python. Presumably they will be all added as global commands if accepted. Otherwise, this might have been a good time to introduce an “lutil” ensemble with filter as a subcommand. /Ashok |
|
From: Steve L. <st...@di...> - 2026-04-30 02:36:23
|
TIP 735: YES TIP 745: YES On 26 Apr 2026 at 1:03 PM +0800, schreef Donal Fellows <don...@ma...>, wrote: > > This is a call for votes on two self-contained TIPs that I've been sitting on for far too long. -- Steve |
|
From: Kevin W. <kw...@co...> - 2026-04-29 20:41:49
|
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... |
|
From: Benjamin R. <b.r...@tu...> - 2026-04-29 18:25:43
|
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 |
|
From: Kevin W. <kw...@co...> - 2026-04-29 17:20:12
|
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 |
|
From: Kevin W. <kw...@co...> - 2026-04-29 17:06:08
|
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 |
|
From: Kevin W. <kw...@co...> - 2026-04-29 17:03:59
|
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. |
|
From: Benjamin R. <b.r...@tu...> - 2026-04-29 16:46:45
|
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. |
|
From: Benjamin R. <b.r...@tu...> - 2026-04-29 16:44:21
|
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 |
|
From: Kevin W. <kw...@co...> - 2026-04-29 15:47:00
|
<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> </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> </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> </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:"Calibri",sans-serif">From:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Kevin Walzer <kw...@co...> <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> </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. <o:p></o:p></p><div><p class="MsoNormal" style="margin-left:.5in"><o:p> </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:"Arial",sans-serif"> </span>PM, Kevin Walzer <<a href="mailto:kw...@co...">kw...@co...</a>> 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:"Tahoma",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:. <o:p></o:p></p><div><p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p></div><div><p class="MsoNormal" style="margin-left:.5in"> 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: <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> </o:p></p></div><div><p class="MsoNormal" style="margin-left:.5in"> 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. <o:p></o:p></p></div><div><p class="MsoNormal" style="margin-left:.5in"><o:p> </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:"Arial",sans-serif"> </span>PM, Kevin Walzer <<a href="mailto:kw...@co...">kw...@co...</a>> 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:"Tahoma",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> |
|
From: <apn...@ya...> - 2026-04-29 15:37:20
|
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 |
|
From: Florent M. <flo...@gm...> - 2026-04-29 11:47:22
|
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 ? > |
|
From: Jan N. <jan...@gm...> - 2026-04-29 10:06:06
|
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
|
|
From: Kevin W. <kw...@co...> - 2026-04-29 09:58:20
|
<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> </o:p></p><p class="MsoNormal">Question about this <a href="https://core.tcl-lang.org/tk/fdiff?v1=8290d0f8233b7e60&v2=2ee29119c2a85451&proof=515536268">Tk commit</a> on trunk.<o:p></o:p></p><p class="MsoNormal"><o:p> </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. <br><blockquote type="cite"><div dir="ltr"><div class="WordSection1"><p class="MsoNormal"><o:p></o:p></p><p class="MsoNormal"><o:p> </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. <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> |
|
From: Donal F. <don...@ma...> - 2026-04-29 08:24:43
|
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 ? |
26 messages has been excluded from this view by a project administrator.
