tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] Tcllib2.0 installer is broken on macOS

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

So, it turns out that the "ridiculous" path
/Library/Frameworks/Tk.framework/Versions  was added to ::tclPkgPath
by ME!

Apparently I did that in order to allow Tcl to find Tk when there are
multiple versions of Tcl installed [1562e10c58]
<https://core.tcl-lang.org/tk/tktview/1562e10c58>.  That directory is
perhaps not a ridiculous place to look for a package, if the package
happens to be Tk.  (I am not certain why that should be the case, however.
Would someone who understands the process by which Tcl finds Tk please tell
me whether that even makes sense?)

Nonetheless, that path is certainly is a ridiculous place to install Tcllib.

I presumably put that path at the end of ::tclPkgPath because it was
intended to be a last resort

I did not suspect that the Tcllib installer would choose to use the last
path on the list instead of the first.

The other strange part of the path
(~/Library/Tcl:/Library/Tcl:~/Library/Frameworks:/Library/Frameworks),
which is strange because I know of no standard installation process which
would create those directories, appears to be older, perhaps a vestige from
a time when installing Tcl in ~/Library was common.

So, once again, these two core principles of software development have been
reaffirmed:

* It is always something;
* Nothing gets fixed without breaking something else.

- Marc

On Sun, Jun 8, 2025 at 9:16 AM Marc Culler <cul...@gm...> wrote:

> I was surprised, when I tried to install Tcllib2.0,  to learn that it had
> been released without anyone having tested it on macOS.  The script
> installer.tcl wants to install the packages at the path:
>     /Library/Frameworks/Tk.framework/Versions
> which is completely ridiculous.
>
> The correct path (for Tcl 9.1) is:
>    /Library/Frameworks/Tcl.framework/Versions/9.1/Resources/Scripts
>
> The error occurs on line 298 of installer.tcl where you find this code:
>            if {[catch {set libdir [lindex $::tcl_pkgPath end]}]} {
>                 set libdir [file dirname [info library]]
>
> For some bizarre reason it is choosing to use the last element of the list
> ::tcl_pkgPath.
>
> When I inspect that list with tclsh9.1 I see:
> % puts "$::tcl_pkgPath"
> /Library/Frameworks/Tcl.framework/Versions/9.1/Resources/Scripts
> /Users/culler/Library/Tcl /Library/Tcl /Users/culler/Library/Frameworks
> /Library/Frameworks /Library/Frameworks/Tk.framework/Versions
>
> The last item, sure enough, is the same completely inappropriate location
> for packages that is shown in the installer gui.
>
> The subdirectories of the Versions directory in a framework are supposed
> to be the version numbers that are installed in the framework (plus a
> symlink Current which points to the version currently in use).  Installing
> a package in there would completely break Apple's specification for the
> structure of a framework bundle.
>
> The second and third items on the list are also ridiculous, since there is
> no straightforward installation process which would even create those
> paths.  They do not exist on my system.
>
> The correct path is the first item on the list.  The other three should
> not be in ::tcl_pkgPath at all, in my opinion.
>
> What peculiar logic led to the idea that the last element of ::tcl_pkgPath
> would be the correct choice?
> And what design choice led to the other crazy paths being in the list at
> all?
>
> - Marc
>
>

[TCLCORE] Tcllib2.0 installer is broken on macOS

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

I was surprised, when I tried to install Tcllib2.0,  to learn that it had
been released without anyone having tested it on macOS.  The script
installer.tcl wants to install the packages at the path:
    /Library/Frameworks/Tk.framework/Versions
which is completely ridiculous.

The correct path (for Tcl 9.1) is:
   /Library/Frameworks/Tcl.framework/Versions/9.1/Resources/Scripts

The error occurs on line 298 of installer.tcl where you find this code:
           if {[catch {set libdir [lindex $::tcl_pkgPath end]}]} {
                set libdir [file dirname [info library]]

For some bizarre reason it is choosing to use the last element of the list
::tcl_pkgPath.

When I inspect that list with tclsh9.1 I see:
% puts "$::tcl_pkgPath"
/Library/Frameworks/Tcl.framework/Versions/9.1/Resources/Scripts
/Users/culler/Library/Tcl /Library/Tcl /Users/culler/Library/Frameworks
/Library/Frameworks /Library/Frameworks/Tk.framework/Versions

The last item, sure enough, is the same completely inappropriate location
for packages that is shown in the installer gui.

The subdirectories of the Versions directory in a framework are supposed to
be the version numbers that are installed in the framework (plus a
symlink Current which points to the version currently in use).  Installing
a package in there would completely break Apple's specification for the
structure of a framework bundle.

The second and third items on the list are also ridiculous, since there is
no straightforward installation process which would even create those
paths.  They do not exist on my system.

The correct path is the first item on the list.  The other three should not
be in ::tcl_pkgPath at all, in my opinion.

What peculiar logic led to the idea that the last element of ::tcl_pkgPath
would be the correct choice?
And what design choice led to the other crazy paths being in the list at
all?

- Marc

[TCLCORE] New TIP #724

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

I have just added TIP #724: Add subcommand "transient" to the Tk clipboard
command <https://core.tcl-lang.org/tips/doc/trunk/tip/724.md>;
This is a call for discussion of the TIP.

As is explained in detail in the TIP it does two things: it fixes
[e94c8bc845] <https://core.tcl-lang.org/tk/tktview/e94c8bc845>: "macOS
clipboard managers do not notice clipboard changes done by Tk" and it adds
a new "transient" subcommand to the clipboard command.  The new command is
intended to make copying a password from Tk and pasting it into a web
browser somewhat safer.  Unfortunately I have no idea how to implement the
new subcommand on linux or Windows.  Also the bug is specific to Aqua.  So
this TIP only affects Åqua. The TIP targets 9.1.

Any thoughts?

- Marc

Re: [TCLCORE] TIP 722: return loaded packages by ”package present”

[Christian W. <Chr...@t-...>]

On 06/06/2025 02:03 PM, Harald Oehlmann wrote:

Harald, all,

> …
> TIP 722 proposes to return the list of currently loaded packages.
>
> Here is a usage example of a freshly installed tclsh:
>
> % package present
> tcl::zlib tcl::oo TclOO tcl::tommath tcl Tcl
>
> This looks usable and neat.
> …

while at this "package" point I'm asking myself if it wouldn't as
well interesting to borrow and augment another already present idea:
There's a "package files …" which collects all the sourced files
during "package require …". A very similar mechanism could be
established which gathers the first level "package require …"
invocations in order to get an idea of the first level dependencies
of the newly required package. So storage would be similar to
"package files …" i.e. per package. By combining the overall
information of all packages a dependency tree emerges which again
could be quite useful to make a software bill of materials or to
help in building single file applications using e.g. the zipfs.

What are your thoughts? Is this a useful addition?

BR,
Christian

[TCLCORE] TIP 722: return loaded packages by ”package present”

[Harald O. <har...@el...>]

Dear TCL team,

Christian is currently highly active, thanks for all!

TIP 722 proposes to return the list of currently loaded packages.

Here is a usage example of a freshly installed tclsh:

% package present
tcl::zlib tcl::oo TclOO tcl::tommath tcl Tcl

This looks usable and neat.

Only the documentation is missing. There is currently one test.

I saw a code path "NREPackageObj". Must this also be changed?

Any comments on this one?

---
This Tk tickets looks good to me:
https://core.tcl-lang.org/tk/info/c81e0ccee2b971b0

---
Monotonic clock:
IMHO, the only clean solution is:
timer on <TimeDelta>
timer at <TimePoint>
as the current "after" has two use-cases.
This is the long way solution.
I will at least update the TIP...
No time at the moment, sorry...

Thanks for all,
Harald

Re: [TCLCORE] On editing whitespace

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

On Thu, Jun 5, 2025 at 8:03 PM Brian Griffin <bri...@ea...>
wrote:

> I think this is a fools errand. There is no good answer here.
>

Brian,

This thread has moved off of its topic, as usually happens these days.  The
original post from Ashok was a request for us to please refrain from making
commits which change actual code in a handful of lines and change
whitespace in hundreds of other lines.  This actually does happen, and it
is costly.  Choosing not to do that is by no means a fool's errand.
Choosing to do that is to not follow your advice "fix your code and move
on".

I am sure that Ashok was worried about the course this discussion
would follow, and I assume that is why he began with the preface "Without
getting into a tabs vs spaces war ...".

Maybe we can just agree not to make commits like that any more.

- Marc

Re: [TCLCORE] On editing whitespace

[Brian G. <bri...@ea...>]

I think this is a fools errand. There is no good answer here. Having worked on large codebases with many developers, the only answer is to fix your code and move on. Make your changes as clean as is reasonable. Respect the existing indenting around it. Then move on.

The deleterious effects of increasing the size of a change, and introducing potential confusion from a blame and merge  perspective, is simply not worth the time and benefit of making the whitespace changes.

My answer is No, just don't go there. Stop fixating on air and move on to more important matters.

-Brian

Re: [TCLCORE] On editing whitespace

[François V. <fvo...@fr...>]

Hi,There has been such an attempt a long time ago:https://core.tcl-lang.org/tk/vdiff?branch=editorconfighttps://core.tcl-lang.org/tcl/vdiff?branch=editorconfigThe file content in these two repositories subtly differ though, which I interprete as the reason these branches were never merged...Regards,François 
-------- Message d'origine --------De : msc...@po... Date : 05/06/2025  20:15  (GMT+01:00) À : Tcl Core List <tcl...@li...> Objet : Re: [TCLCORE] On editing whitespace Hi,if it was possible to add some .editorconfig file to the repository, it would probably help quite a bit already to keep things correct regarding whitespace settings.https://editorconfig.org/MichaelAm 04.06.2025 23:53 schrieb Christian Werner:> Dear friends,> > do you think that it is possible to have an indent(1) profile which > 100%> fulfills the requirements of The Engineering Manual? If so, would it be > a> good idea to feed all source code once through indent(1) to have a > starting> point? And from this point on have any commit being filtered with that> procedure?> > My 0.02 pieces for code format harmonization,> Christian> > > > _______________________________________________> Tcl-Core mailing list> Tcl...@li...> https://lists.sourceforge.net/lists/listinfo/tcl-core_______________________________________________Tcl-Core mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] On editing whitespace

[<msc...@po...>]

Hi,

if it was possible to add some .editorconfig file to the repository, it 
would probably help quite a bit already to keep things correct regarding 
whitespace settings.

https://editorconfig.org/

Michael



Am 04.06.2025 23:53 schrieb Christian Werner:
> Dear friends,
> 
> do you think that it is possible to have an indent(1) profile which 
> 100%
> fulfills the requirements of The Engineering Manual? If so, would it be 
> a
> good idea to feed all source code once through indent(1) to have a 
> starting
> point? And from this point on have any commit being filtered with that
> procedure?
> 
> My 0.02 pieces for code format harmonization,
> Christian
> 
> 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] On editing whitespace

[Dipl. I. S. G. B. <se...@us...>]

 

+1 

Additionally to diff issues, there are other complications like
conflicts by merge or back-porting between branches (no matter whether
in tclcore itself or in some forks), or difficulty to blame the change
(find a commit or branch responsible for some issue) etc.
However I guess I tried already several times to press the issue... To
my regret, unsuccessfully.

Regards,
Serg. 

04.06.2025 18:24, apnmbx-public--- via Tcl-Core wrote: 

> On more than one occasion in the past couple of months, commits have been made that include copious changes of spaces to tabs. TIP 247, which presumably is the coding standard Tcl core follows, does not have any mandate to use tabs afaict. If that is the case, can we please desist from such changes? Without getting into a tabs vs spaces war (personally, I prefer spaces) can we just respect whatever exists as long as it meets the standard (indent of 4 etc.) It has practical implications in that, when reviewing diffs or merging, one has to go unnecessarily go through each diff to see what changed. 
> 
> /Ashok 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core [1]
 

Links:
------
[1] https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] On editing whitespace

[B H. <bra...@gm...>]

<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr"><br></div><div dir="ltr"><br><blockquote type="cite">On Jun 5, 2025, at 09:27, Marc Culler &lt;cul...@gm...&gt; wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div>Another issue that emerges when relying on emacs is that the files in the macosx directory are not actually C files&nbsp;(despite the .c extension).&nbsp; They are Objective C files.&nbsp; Emacs knows&nbsp;to use objc mode because the emacs <span style="font-family:monospace">Local Variables</span> comment specifies <span style="font-family:monospace">mode: objc</span><b>.</b>&nbsp; But the emacs indentation rules for Objective C are different from those for C, and they conflict with the Tcl guidelines.&nbsp; For example, emacs in objc mode thinks the following indentation is correct:</div><div><span style="font-family:monospace"><br></span></div><div><span style="font-family:monospace">v<b>oid<br>TkExampleFunction(<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Tcl_Interp *interp,<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Tk_Window tkwin)<br>{<br>&nbsp; &nbsp; return;<br>}<br></b></span></div><div><span style="font-family:monospace"><br></span></div><div><span style="font-family:monospace">whereas Tcl expects:</span></div><div><span style="font-family:monospace"><br></span></div><div><span style="font-family:monospace">v<b>oid<br>TkExampleFunction(<br>&nbsp; &nbsp; Tcl_Interp *interp,<br>&nbsp; &nbsp; Tk_Window tkwin)<br>{<br>&nbsp; &nbsp; return;</b></span><b><br>}</b></div><div><br></div><div>So I don't think that relying on emacs is the answer,&nbsp;not even during editing.&nbsp; Too bad that the real world is so complicated.</div><div><br></div></div></div></blockquote><div><br></div><div>This is certainly all configurable - do we have an actual specification other than “the way it is now” so that we can configure vi(1), indent(1), emacs(1), VS Code, etc to spec? That would have the benefit of letting anybody use their preferred tooling as long as the published results meet spec, and eventually pull out-of-spec code back in line.</div><div><br></div><div>If we don’t have this, it’s worth discussion, especially before some well-meaning janitor helpfully reformats the entire codebase and our blame/praise commands all land on a single commit.</div><div><br></div><div>-bch</div><br><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div>- Marc</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Jun 5, 2025 at 10:58 AM apnmbx-public--- via Tcl-Core &lt;<a href="mailto:tcl...@li...">tcl...@li...</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg6435832809847493291"><div lang="EN-IN" style="overflow-wrap: break-word;"><div class="m_6435832809847493291WordSection1"><p class="MsoNormal"><span style="font-size:11pt">Using emacs (or VS or whatever), as I do, is fine when used during the actual editing. If it is set up to format the entire file on a save, then I’m afraid lines will bounce between spaces and tabs if two developers have different settings in that respect.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt"><u></u>&nbsp;<u></u></span></p><p class="MsoNormal"><span style="font-size:11pt">Anyways, I just wanted to bring attention to this issue as a request to all.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt"><u></u>&nbsp;<u></u></span></p><p class="MsoNormal"><span style="font-size:11pt">/Ashok<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt"><u></u>&nbsp;<u></u></span></p><div><div style="border-width:1pt medium medium;border-style:solid none none;border-color:rgb(225,225,225) currentcolor currentcolor;padding:3pt 0in 0in"><p class="MsoNormal" style="margin-left:0.5in"><b><span lang="EN-US" style="font-size:11pt;font-family:&quot;Calibri&quot;,sans-serif">From:</span></b><span lang="EN-US" style="font-size:11pt;font-family:&quot;Calibri&quot;,sans-serif"> Kevin Walzer &lt;<a href="mailto:kw...@54..." target="_blank">kw...@54...</a>&gt; <br><b>Sent:</b> Wednesday, June 4, 2025 11:46 PM<br><b>To:</b> Marc Culler &lt;<a href="mailto:cul...@gm..." target="_blank">cul...@gm...</a>&gt;<br><b>Cc:</b> <a href="mailto:apn...@ya..." target="_blank">apn...@ya...</a>; <a href="mailto:tcl...@li..." target="_blank">tcl...@li...</a><br><b>Subject:</b> Re: [TCLCORE] On editing whitespace<u></u><u></u></span></p></div></div><p class="MsoNormal" style="margin-left:0.5in"><u></u>&nbsp;<u></u></p><p class="MsoNormal" style="margin-left:0.5in"><span style="border:1pt solid windowtext;padding:0in"><div>&lt;~WRD0000.jpg&gt;</div></span><u></u><u></u></p><div><p class="MsoNormal" style="margin-left:0.5in">My practice is up run my edits through Emacs C indentation before committing. I plan to continue that. &nbsp;<u></u><u></u></p></div><div><p class="MsoNormal" style="margin-left:0.5in"><br><br><u></u><u></u></p><blockquote style="margin-top:5pt;margin-bottom:5pt"><p class="MsoNormal" style="margin-right:0in;margin-bottom:12pt;margin-left:0.5in">On Jun 4, 2025, at 12:41<span style="font-family:&quot;Arial&quot;,sans-serif"> </span>PM, Marc Culler &lt;<a href="mailto:cul...@gm..." target="_blank">cul...@gm...</a>&gt; wrote:<u></u><u></u></p></blockquote></div><blockquote style="margin-top:5pt;margin-bottom:5pt"><div><p class="MsoNormal" style="margin-left:0.5in"><span style="font-family:&quot;Tahoma&quot;,sans-serif"></span><u></u><u></u></p><div><div><p class="MsoNormal" style="margin-left:0.5in">Also, if there really is a need to mess with whitespace, it would be very helpful to produce a commit with *only* whitespace changes and to give it a helpful comment that includes words like "only changes whitespace".<u></u><u></u></p></div><div><p class="MsoNormal" style="margin-left:0.5in"><u></u>&nbsp;<u></u></p></div><div><p class="MsoNormal" style="margin-left:0.5in">And, if it ever comes to a decision, I would also vote for spaces.&nbsp; They make life so much simpler when people mix ASCII art with internal code documentation (as in left&nbsp;justifying comments at a certain column.)&nbsp; We can easily afford the few extra bytes of storage.<u></u><u></u></p></div><div><p class="MsoNormal" style="margin-left:0.5in"><u></u>&nbsp;<u></u></p></div><div><p class="MsoNormal" style="margin-left:0.5in">- Marc&nbsp;<u></u><u></u></p></div></div><p class="MsoNormal" style="margin-left:0.5in"><u></u>&nbsp;<u></u></p><div><div><p class="MsoNormal" style="margin-left:0.5in">On Wed, Jun 4, 2025 at 11:26<span style="font-family:&quot;Arial&quot;,sans-serif"> </span>AM apnmbx-public--- via Tcl-Core &lt;<a href="mailto:tcl...@li..." target="_blank">tcl...@li...</a>&gt; wrote:<u></u><u></u></p></div><blockquote style="border-width:medium medium medium 1pt;border-style:none none none solid;border-color:currentcolor currentcolor currentcolor rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in"><div><div><div><p class="MsoNormal" style="margin-left:0.5in">On more than one occasion in the past couple of months, commits have been made that include copious changes of spaces to tabs. TIP 247, which presumably is the coding standard Tcl core follows, does not have any mandate to use tabs afaict. If that is the case, can we please desist from such changes? Without getting into a tabs vs spaces war (personally, I prefer spaces) can we just respect whatever exists as long as it meets the standard (indent of 4 etc.) It has practical implications in that, when reviewing diffs or merging, one has to go unnecessarily go through each diff to see what changed.<u></u><u></u></p><p class="MsoNormal" style="margin-left:0.5in">&nbsp;<u></u><u></u></p><p class="MsoNormal" style="margin-left:0.5in">/Ashok<u></u><u></u></p></div></div><p class="MsoNormal" style="margin-left:0.5in">_______________________________________________<br>Tcl-Core mailing list<br><a href="mailto:Tcl...@li..." target="_blank">Tcl...@li...</a><br><a href="https://fedbdhd.r.af.d.sendibt2.com/tr/cl/NtlkBQINf1J-xE5B-4H7iBhinSxAVHYNnprusCRtEou20blFmcOO45bb--AFRMReVMsKtk954QGMkd2kL77J0ZXe9mI1GEQ07NFs0j38qEQGXQcMsy0VoeRbLXmXEr3-tQaqrpK8I3XqqXl7nKHG5XjpgFNLgLdgABHf5LpFRQwffzMnWxnu5n2hIxPxYNF_JSBktedmYz0f1WuvWGLvDobGaVp0ByjCFYp0pdHj1xO5Lwr5n4SiGW19fkzL04NOefkuEZKWTQI8Q6eKrkcZ3PrYO7wItcQOgQJiV3Ba3K8anh6SNyrj7aVl" target="_blank">https://lists.sourceforge.net/lists/listinfo/tcl-core</a><u></u><u></u></p></div></blockquote></div><p class="MsoNormal" style="margin-left:0.5in">_______________________________________________<br>Tcl-Core mailing list<br><a href="mailto:Tcl...@li..." target="_blank">Tcl...@li...</a><br><a href="https://lists.sourceforge.net/lists/listinfo/tcl-core" target="_blank">https://lists.sourceforge.net/lists/listinfo/tcl-core</a><u></u><u></u></p></div></blockquote></div></div>_______________________________________________<br>
Tcl-Core mailing list<br>
<a href="mailto:Tcl...@li..." target="_blank">Tcl...@li...</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/tcl-core" rel="noreferrer" target="_blank">https://lists.sourceforge.net/lists/listinfo/tcl-core</a><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></body></html>

Re: [TCLCORE] On editing whitespace

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

<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><img width="1" height="1" src="https://fedbdhd.r.af.d.sendibt2.com/tr/op/WnBCGsVtXexyo_d6R8auIU2eLyouVlLI41kAbWV2AWuL40mZgR80DOQPWFpBoiYF19sz-O8ybrZowILT7Nhhj_QEdtW_z3ajoRBoku61AT6faWHFr6I521XRzzTKNSIDrLR6qy2pcr4rYJTrhd170yGIpofxZQAwNt9YVPfbULm9pY7COLl_42C_tGokugGkjPlKWDJT26fBJRAlYVN1OgqEvAD_RW8f" style="mso-hide:all"/><div dir="ltr"></div><div dir="ltr">I wish there were a tool that we could run files through that works standardize indentation according to the Tcl Engineering Manual. I am only willing to invest so much time in tidying up my code.&nbsp;</div><div dir="ltr"><br><blockquote type="cite">On Jun 5, 2025, at 12:28 PM, Marc Culler &lt;cul...@gm...&gt; wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div>Another issue that emerges when relying on emacs is that the files in the macosx directory are not actually C files&nbsp;(despite the .c extension).&nbsp; They are Objective C files.&nbsp; Emacs knows&nbsp;to use objc mode because the emacs <span style="font-family:monospace">Local Variables</span> comment specifies <span style="font-family:monospace">mode: objc</span><b>.</b>&nbsp; But the emacs indentation rules for Objective C are different from those for C, and they conflict with the Tcl guidelines.&nbsp; For example, emacs in objc mode thinks the following indentation is correct:</div><div><span style="font-family:monospace"><br></span></div><div><span style="font-family:monospace">v<b>oid<br>TkExampleFunction(<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Tcl_Interp *interp,<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Tk_Window tkwin)<br>{<br>&nbsp; &nbsp; return;<br>}<br></b></span></div><div><span style="font-family:monospace"><br></span></div><div><span style="font-family:monospace">whereas Tcl expects:</span></div><div><span style="font-family:monospace"><br></span></div><div><span style="font-family:monospace">v<b>oid<br>TkExampleFunction(<br>&nbsp; &nbsp; Tcl_Interp *interp,<br>&nbsp; &nbsp; Tk_Window tkwin)<br>{<br>&nbsp; &nbsp; return;</b></span><b><br>}</b></div><div><br></div><div>So I don't think that relying on emacs is the answer,&nbsp;not even during editing.&nbsp; Too bad that the real world is so complicated.</div><div><br></div><div>- Marc</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Jun 5, 2025 at 10:58 AM apnmbx-public--- via Tcl-Core &lt;<a href="mailto:tcl...@li...">tcl...@li...</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg6435832809847493291"><div lang="EN-IN" style="overflow-wrap: break-word;"><div class="m_6435832809847493291WordSection1"><p class="MsoNormal"><span style="font-size:11pt">Using emacs (or VS or whatever), as I do, is fine when used during the actual editing. If it is set up to format the entire file on a save, then I’m afraid lines will bounce between spaces and tabs if two developers have different settings in that respect.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt"><u></u>&nbsp;<u></u></span></p><p class="MsoNormal"><span style="font-size:11pt">Anyways, I just wanted to bring attention to this issue as a request to all.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt"><u></u>&nbsp;<u></u></span></p><p class="MsoNormal"><span style="font-size:11pt">/Ashok<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt"><u></u>&nbsp;<u></u></span></p><div><div style="border-width:1pt medium medium;border-style:solid none none;border-color:rgb(225,225,225) currentcolor currentcolor;padding:3pt 0in 0in"><p class="MsoNormal" style="margin-left:0.5in"><b><span lang="EN-US" style="font-size:11pt;font-family:&quot;Calibri&quot;,sans-serif">From:</span></b><span lang="EN-US" style="font-size:11pt;font-family:&quot;Calibri&quot;,sans-serif"> Kevin Walzer &lt;<a href="mailto:kw...@54..." target="_blank">kw...@54...</a>&gt; <br><b>Sent:</b> Wednesday, June 4, 2025 11:46 PM<br><b>To:</b> Marc Culler &lt;<a href="mailto:cul...@gm..." target="_blank">cul...@gm...</a>&gt;<br><b>Cc:</b> <a href="mailto:apn...@ya..." target="_blank">apn...@ya...</a>; <a href="mailto:tcl...@li..." target="_blank">tcl...@li...</a><br><b>Subject:</b> Re: [TCLCORE] On editing whitespace<u></u><u></u></span></p></div></div><p class="MsoNormal" style="margin-left:0.5in"><u></u>&nbsp;<u></u></p><p class="MsoNormal" style="margin-left:0.5in"><span style="border:1pt solid windowtext;padding:0in"><div>&lt;~WRD0000.jpg&gt;</div></span><u></u><u></u></p><div><p class="MsoNormal" style="margin-left:0.5in">My practice is up run my edits through Emacs C indentation before committing. I plan to continue that. &nbsp;<u></u><u></u></p></div><div><p class="MsoNormal" style="margin-left:0.5in"><br><br><u></u><u></u></p><blockquote style="margin-top:5pt;margin-bottom:5pt"><p class="MsoNormal" style="margin-right:0in;margin-bottom:12pt;margin-left:0.5in">On Jun 4, 2025, at 12:41<span style="font-family:&quot;Arial&quot;,sans-serif"> </span>PM, Marc Culler &lt;<a href="mailto:cul...@gm..." target="_blank">cul...@gm...</a>&gt; wrote:<u></u><u></u></p></blockquote></div><blockquote style="margin-top:5pt;margin-bottom:5pt"><div><p class="MsoNormal" style="margin-left:0.5in"><span style="font-family:&quot;Tahoma&quot;,sans-serif"></span><u></u><u></u></p><div><div><p class="MsoNormal" style="margin-left:0.5in">Also, if there really is a need to mess with whitespace, it would be very helpful to produce a commit with *only* whitespace changes and to give it a helpful comment that includes words like "only changes whitespace".<u></u><u></u></p></div><div><p class="MsoNormal" style="margin-left:0.5in"><u></u>&nbsp;<u></u></p></div><div><p class="MsoNormal" style="margin-left:0.5in">And, if it ever comes to a decision, I would also vote for spaces.&nbsp; They make life so much simpler when people mix ASCII art with internal code documentation (as in left&nbsp;justifying comments at a certain column.)&nbsp; We can easily afford the few extra bytes of storage.<u></u><u></u></p></div><div><p class="MsoNormal" style="margin-left:0.5in"><u></u>&nbsp;<u></u></p></div><div><p class="MsoNormal" style="margin-left:0.5in">- Marc&nbsp;<u></u><u></u></p></div></div><p class="MsoNormal" style="margin-left:0.5in"><u></u>&nbsp;<u></u></p><div><div><p class="MsoNormal" style="margin-left:0.5in">On Wed, Jun 4, 2025 at 11:26<span style="font-family:&quot;Arial&quot;,sans-serif"> </span>AM apnmbx-public--- via Tcl-Core &lt;<a href="mailto:tcl...@li..." target="_blank">tcl...@li...</a>&gt; wrote:<u></u><u></u></p></div><blockquote style="border-width:medium medium medium 1pt;border-style:none none none solid;border-color:currentcolor currentcolor currentcolor rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in"><div><div><div><p class="MsoNormal" style="margin-left:0.5in">On more than one occasion in the past couple of months, commits have been made that include copious changes of spaces to tabs. TIP 247, which presumably is the coding standard Tcl core follows, does not have any mandate to use tabs afaict. If that is the case, can we please desist from such changes? Without getting into a tabs vs spaces war (personally, I prefer spaces) can we just respect whatever exists as long as it meets the standard (indent of 4 etc.) It has practical implications in that, when reviewing diffs or merging, one has to go unnecessarily go through each diff to see what changed.<u></u><u></u></p><p class="MsoNormal" style="margin-left:0.5in">&nbsp;<u></u><u></u></p><p class="MsoNormal" style="margin-left:0.5in">/Ashok<u></u><u></u></p></div></div><p class="MsoNormal" style="margin-left:0.5in">_______________________________________________<br>Tcl-Core mailing list<br><a href="mailto:Tcl...@li..." target="_blank">Tcl...@li...</a><br><a href="https://fedbdhd.r.af.d.sendibt2.com/tr/cl/NtlkBQINf1J-xE5B-4H7iBhinSxAVHYNnprusCRtEou20blFmcOO45bb--AFRMReVMsKtk954QGMkd2kL77J0ZXe9mI1GEQ07NFs0j38qEQGXQcMsy0VoeRbLXmXEr3-tQaqrpK8I3XqqXl7nKHG5XjpgFNLgLdgABHf5LpFRQwffzMnWxnu5n2hIxPxYNF_JSBktedmYz0f1WuvWGLvDobGaVp0ByjCFYp0pdHj1xO5Lwr5n4SiGW19fkzL04NOefkuEZKWTQI8Q6eKrkcZ3PrYO7wItcQOgQJiV3Ba3K8anh6SNyrj7aVl" target="_blank">https://lists.sourceforge.net/lists/listinfo/tcl-core</a><u></u><u></u></p></div></blockquote></div><p class="MsoNormal" style="margin-left:0.5in">_______________________________________________<br>Tcl-Core mailing list<br><a href="mailto:Tcl...@li..." target="_blank">Tcl...@li...</a><br><a href="https://fedbdhd.r.af.d.sendibt2.com/tr/cl/a4LH6FNZ2Pa0uZLDL1MR8wpNyu0DxyKfgRyg_VX2qHqdYhKiFtzeg6ucXx7fyW3ALBFUPMKIEavrync7x9-QBei3FFvWZHmqWE_VwaYnzTijmcU1a_hPkrxVG8UGgz50jFQ6sZ-ncfd1u79jE2mgRgrZ9x7vjP7FpSo_M52pAdJX4jnkx4NhewUTtHJ6WlU9npicJZdEdPnAJZwFd5ekEqLSOWNSAaYl7qb1K_ZABt6k7cf5lr9rSfL9PSXEgA3Yvtz_2k1X6ySFJIETvxuSoFi_TSjq48zmRnpwaWf86KjLbO8xxk2evq7rh00LeMWtIw" target="_blank">https://lists.sourceforge.net/lists/listinfo/tcl-core</a><u></u><u></u></p></div></blockquote></div></div>_______________________________________________<br>
Tcl-Core mailing list<br>
<a href="mailto:Tcl...@li..." target="_blank">Tcl...@li...</a><br>
<a href="https://fedbdhd.r.af.d.sendibt2.com/tr/cl/rKGN81T2SADcaj9r9lOBjlJDQ82tKqos5Grr3bOoGVTdq6s-dnH_y_RgUX8W1QYITYYPqtbhhlLogbES9_LfGGHbc35_ZqMc2Ix3RpqNmbuZGgFSHj-Bz_-HPMGmgCUC4TH5sZ2jAbsepJqV3z3yp79gjdq9R8n2q9cyp7aUSpo6L95av6HEsSq48lKsLk2ShBFlDuOJpS6t4c4BTJaGyZIIdXZgYrDdsnULquJpgLoRldb62A_9oAp4GkWKcv3sNvo9A1wY4jUxxhfZ_a9SiE0tuqSi3eNTre4nq6UvnZh8tiHnMY4jd652NveDfEiEAQ" rel="noreferrer" target="_blank">https://lists.sourceforge.net/lists/listinfo/tcl-core</a><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></body></html>

Re: [TCLCORE] On editing whitespace

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

Another issue that emerges when relying on emacs is that the files in the
macosx directory are not actually C files (despite the .c extension).  They
are Objective C files.  Emacs knows to use objc mode because the emacs Local
Variables comment specifies mode: objc*.*  But the emacs indentation rules
for Objective C are different from those for C, and they conflict with the
Tcl guidelines.  For example, emacs in objc mode thinks the following
indentation is correct:

v






*oidTkExampleFunction(                  Tcl_Interp *interp,
  Tk_Window tkwin){    return;}*

whereas Tcl expects:

v




*oidTkExampleFunction(    Tcl_Interp *interp,    Tk_Window tkwin){
return;*
*}*

So I don't think that relying on emacs is the answer, not even during
editing.  Too bad that the real world is so complicated.

- Marc

On Thu, Jun 5, 2025 at 10:58 AM apnmbx-public--- via Tcl-Core <
tcl...@li...> wrote:

> Using emacs (or VS or whatever), as I do, is fine when used during the
> actual editing. If it is set up to format the entire file on a save, then
> I’m afraid lines will bounce between spaces and tabs if two developers have
> different settings in that respect.
>
>
>
> Anyways, I just wanted to bring attention to this issue as a request to
> all.
>
>
>
> /Ashok
>
>
>
> *From:* Kevin Walzer <kw...@54...>
> *Sent:* Wednesday, June 4, 2025 11:46 PM
> *To:* Marc Culler <cul...@gm...>
> *Cc:* apn...@ya...; tcl...@li...
> *Subject:* Re: [TCLCORE] On editing whitespace
>
>
>
> [image: Image removed by sender.]
>
> My practice is up run my edits through Emacs C indentation before
> committing. I plan to continue that.
>
>
>
> On Jun 4, 2025, at 12:41 PM, Marc Culler <cul...@gm...> wrote:
>
> 
>
> Also, if there really is a need to mess with whitespace, it would be very
> helpful to produce a commit with *only* whitespace changes and to give it a
> helpful comment that includes words like "only changes whitespace".
>
>
>
> And, if it ever comes to a decision, I would also vote for spaces.  They
> make life so much simpler when people mix ASCII art with internal code
> documentation (as in left justifying comments at a certain column.)  We can
> easily afford the few extra bytes of storage.
>
>
>
> - Marc
>
>
>
> On Wed, Jun 4, 2025 at 11:26 AM apnmbx-public--- via Tcl-Core <
> tcl...@li...> wrote:
>
> On more than one occasion in the past couple of months, commits have been
> made that include copious changes of spaces to tabs. TIP 247, which
> presumably is the coding standard Tcl core follows, does not have any
> mandate to use tabs afaict. If that is the case, can we please desist from
> such changes? Without getting into a tabs vs spaces war (personally, I
> prefer spaces) can we just respect whatever exists as long as it meets the
> standard (indent of 4 etc.) It has practical implications in that, when
> reviewing diffs or merging, one has to go unnecessarily go through each
> diff to see what changed.
>
>
>
> /Ashok
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
> <https://fedbdhd.r.af.d.sendibt2.com/tr/cl/NtlkBQINf1J-xE5B-4H7iBhinSxAVHYNnprusCRtEou20blFmcOO45bb--AFRMReVMsKtk954QGMkd2kL77J0ZXe9mI1GEQ07NFs0j38qEQGXQcMsy0VoeRbLXmXEr3-tQaqrpK8I3XqqXl7nKHG5XjpgFNLgLdgABHf5LpFRQwffzMnWxnu5n2hIxPxYNF_JSBktedmYz0f1WuvWGLvDobGaVp0ByjCFYp0pdHj1xO5Lwr5n4SiGW19fkzL04NOefkuEZKWTQI8Q6eKrkcZ3PrYO7wItcQOgQJiV3Ba3K8anh6SNyrj7aVl>
>
> _______________________________________________
> 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] On editing whitespace

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

Using emacs (or VS or whatever), as I do, is fine when used during the actual editing. If it is set up to format the entire file on a save, then I’m afraid lines will bounce between spaces and tabs if two developers have different settings in that respect.

 

Anyways, I just wanted to bring attention to this issue as a request to all.

 

/Ashok

 

From: Kevin Walzer <kw...@54...> 
Sent: Wednesday, June 4, 2025 11:46 PM
To: Marc Culler <cul...@gm...>
Cc: apn...@ya...; tcl...@li...
Subject: Re: [TCLCORE] On editing whitespace

 



My practice is up run my edits through Emacs C indentation before committing. I plan to continue that.  





On Jun 4, 2025, at 12:41 PM, Marc Culler <cul...@gm...> wrote:



Also, if there really is a need to mess with whitespace, it would be very helpful to produce a commit with *only* whitespace changes and to give it a helpful comment that includes words like "only changes whitespace".

 

And, if it ever comes to a decision, I would also vote for spaces.  They make life so much simpler when people mix ASCII art with internal code documentation (as in left justifying comments at a certain column.)  We can easily afford the few extra bytes of storage.

 

- Marc 

 

On Wed, Jun 4, 2025 at 11:26 AM apnmbx-public--- via Tcl-Core <tcl...@li... <mailto:tcl...@li...> > wrote:

On more than one occasion in the past couple of months, commits have been made that include copious changes of spaces to tabs. TIP 247, which presumably is the coding standard Tcl core follows, does not have any mandate to use tabs afaict. If that is the case, can we please desist from such changes? Without getting into a tabs vs spaces war (personally, I prefer spaces) can we just respect whatever exists as long as it meets the standard (indent of 4 etc.) It has practical implications in that, when reviewing diffs or merging, one has to go unnecessarily go through each diff to see what changed.

 

/Ashok

_______________________________________________
Tcl-Core mailing list
Tcl...@li... <mailto:Tcl...@li...> 
https://lists.sourceforge.net/lists/listinfo/tcl-core <https://fedbdhd.r.af.d.sendibt2.com/tr/cl/NtlkBQINf1J-xE5B-4H7iBhinSxAVHYNnprusCRtEou20blFmcOO45bb--AFRMReVMsKtk954QGMkd2kL77J0ZXe9mI1GEQ07NFs0j38qEQGXQcMsy0VoeRbLXmXEr3-tQaqrpK8I3XqqXl7nKHG5XjpgFNLgLdgABHf5LpFRQwffzMnWxnu5n2hIxPxYNF_JSBktedmYz0f1WuvWGLvDobGaVp0ByjCFYp0pdHj1xO5Lwr5n4SiGW19fkzL04NOefkuEZKWTQI8Q6eKrkcZ3PrYO7wItcQOgQJiV3Ba3K8anh6SNyrj7aVl> 

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

Re: [TCLCORE] CFV: TIP #712: Add "positive" options to the subst command

[Rolf A. <tcl...@po...>]

TIP #712:   YES

rolf

Reinhard Max <rei...@pu...> writes:
> This is a Call For Votes for TIP 712:
> Add "positive" options to the subst command
>
> Please send your votes until Jun 15, 12:00 UTC
> [clock format 1749988800].
>
> My vote:
> TIP #712:   YES
>
> cu
> Reinhard

Re: [TCLCORE] On editing whitespace

[Rolf A. <tcl...@po...>]

Using emacs is a resonable option (I also do). Typically your edits are
indented on the fly (or indentation is just a <TAB> away). There is
typically no need to re-indent a whole file. Emacs can be told to use
spaces instead of tabs for indentation.

rolf

"Kevin Walzer" <kw-...@pu...> writes:
> My practice is up run my edits through Emacs C indentation before committing. I plan to continue that.  
>
>  On Jun 4, 2025, at 12:41 PM, Marc Culler <cul...@pu...> wrote:
>
>  Also, if there really is a need to mess with whitespace, it would be very helpful to produce a commit with *only* whitespace
>  changes and to give it a helpful comment that includes words like "only changes whitespace".
>
>  And, if it ever comes to a decision, I would also vote for spaces.  They make life so much simpler when people mix ASCII art with
>  internal code documentation (as in left justifying comments at a certain column.)  We can easily afford the few extra bytes of
>  storage.
>
>  - Marc 
>
>  On Wed, Jun 4, 2025 at 11:26 AM apnmbx-public--- via Tcl-Core
>  <tcl...@pu...> wrote:
>
>  On more than one occasion in the past couple of months, commits have been made that include copious changes of spaces to
>  tabs. TIP 247, which presumably is the coding standard Tcl core follows, does not have any mandate to use tabs afaict. If that
>  is the case, can we please desist from such changes? Without getting into a tabs vs spaces war (personally, I prefer spaces)
>  can we just respect whatever exists as long as it meets the standard (indent of 4 etc.) It has practical implications in that, when
>  reviewing diffs or merging, one has to go unnecessarily go through each diff to see what changed.
>
>   
>
>  /Ashok
>
>  _______________________________________________
>  Tcl-Core mailing list
>  Tcl...@pu...
>  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...@pu...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] On editing whitespace

[Christian W. <Chr...@t-...>]

Dear friends,

do you think that it is possible to have an indent(1) profile which 100%
fulfills the requirements of The Engineering Manual? If so, would it be a
good idea to feed all source code once through indent(1) to have a starting
point? And from this point on have any commit being filtered with that
procedure?

My 0.02 pieces for code format harmonization,
Christian

Re: [TCLCORE] On editing whitespace

[Francois V. <fvo...@fr...>]

Let me just state that I strongly second this exact request I have made 
a few times before (at no avail).

Oh, and yes I know there is a switch in fossil allowing to ignore 
whitespaces in diffs. No, that does not make a true difference on the 
subject.

Again: this is not about choosing between spaces and tabs. The Tcl 
engineering manual is clear about this (set TIP #247). It is about not 
changing what is already there, be it spaces or tabs. And this is true 
too for whitespace at end of lines.

Regards,

Francois

Le 04/06/2025 à 18:24, apnmbx-public--- via Tcl-Core a écrit :
>
> On more than one occasion in the past couple of months, commits have 
> been made that include copious changes of spaces to tabs. TIP 247, 
> which presumably is the coding standard Tcl core follows, does not 
> have any mandate to use tabs afaict. If that is the case, can we 
> please desist from such changes? Without getting into a tabs vs spaces 
> war (personally, I prefer spaces) can we just respect whatever exists 
> as long as it meets the standard (indent of 4 etc.) It has practical 
> implications in that, when reviewing diffs or merging, one has to go 
> unnecessarily go through each diff to see what changed.
>
> /Ashok
>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] expose content of macOS' Info.plist

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

I have now implemented a new command, called ::tk::mac::getInfoAsJSON,
which behaves as I proposed in my previous message.

Here is an example of how it works in an interactive Wish session:

$ wish9.1
% package require json
1.3.6
% set info [::tk::mac::getInfoAsJSON]; list
% set infodict [::json::json2dict $info]; list
% puts [dict get $infodict "CFBundleName"]
Wish
%

The implementation is in a fossil branch named json_info_plist
<https://core.tcl-lang.org/tk/timeline?r=json_info_plist>.

*IOhannes m zmoelnig*: I hope you will build that branch and let me know if
it does what you were asking for.  I assume (but do not know for certain)
that adding a command in the ::tk::mac namespace requires a TIP.  Also, the
command is not documented yet.  But we can worry about the documentation
and the TIP after you test the command.

- Marc


On Wed, Jun 4, 2025 at 12:05 PM Marc Culler <cul...@gm...> wrote:

> I have done a bit more experimenting, after I learned of the existence of
> Apple's Objective C class NSJSONSerialization.  That class can serialize a
> Core Foundation object, such as the NSDictionary returned by [[NSBundle
> mainBundle] infoDictionary], producing a sequence of bytes in json format.
> There is a JSON parser
> <https://core.tcl-lang.org/tcllib/doc/trunk/embedded/md/tcllib/files/modules/json/json.md> written
> by Andreas Kupries in the Tcllib.  It can convert a JSON-encoded byte
> sequence into a Tcl dict.  (And that is **way easier** than creating an XML
> parser which could convert the bytes in an Info.plist file into a Tcl dict.)
>
> So my proposal would be to add a new command which returns a JSON encoding
> of the Info.plist file.  That data could then be processed however the user
> wished, but probably most easily by using:
>     package require json
>     set foo [::json::json2dict [<new command>]]
>
> Below is what the resulting byte sequence would look like for Wish 9.1.
>
> - Marc
>
> {
>   "CFBundleName" : "Wish",
>   "CFBundleNumericVersion" : 152059904,
>   "OSAScriptingDefinition" : "Wish.sdef",
>   "CFBundleDevelopmentRegion" : "English",
>   "CFBundleVersion" : "9.1a0",
>   "CFBundleDocumentTypes" : [
>     {
>       "CFBundleTypeName" : "NSStringPboardType",
>       "CFBundleTypeExtensions" : [
>         "tcl",
>         "TCL",
>         "*"
>       ],
>       "CFBundleTypeMIMETypes" : [
>         "application\/x-tcl",
>         "text\/plain"
>       ],
>       "CFBundleTypeOSTypes" : [
>         "TEXT",
>         "****"
>       ],
>       "CFBundleTypeRole" : "Viewer"
>     }
>   ],
>   "CFBundlePackageType" : "APPL",
>   "CFBundleIconFile" : "Wish.icns",
>   "CFBundleShortVersionString" : "9.1a0",
>   "NSHighResolutionCapable" : "True",
>   "CFBundleInfoDictionaryVersion" : "6.0",
>   "NSAppleScriptEnabled" : true,
>   "CFBundleExecutable" : "Wish",
>   "CFBundleURLTypes" : [
>     {
>       "CFBundleTypeRole" : "Viewer",
>       "CFBundleURLName" : "Get Foo",
>       "CFBundleURLSchemes" : [
>         "foo"
>       ]
>     }
>   ],
>   "CFBundleIdentifier" : "com.tcltk.wish",
>   "CFBundleSignature" : "WiSH",
>   "LSRequiresCarbon" : true,
>   "LSMinimumSystemVersion" : "10.6.0",
>   "CFBundleLocalizations" : [
>     "cs",
>     "da",
>     "de",
>     "el",
>     "en",
>     "en_gb",
>     "eo",
>     "es",
>     "fr",
>     "hu",
>     "it",
>     "nl",
>     "pl",
>     "pt",
>     "ru",
>     "sv"
>   ],
>   "CFBundleGetInfoString" : "Wish Shell 9.1a0,\n    Copyright © 1989-2025
> Tcl Core Team,\n    Copyright © 1989-2025 Contributors,\n    Copyright ©
> 2011-2025 Kevin Walzer\/WordTech Communications LLC,\n    Copyright ©
> 2014-2025 Marc Culler,\n    Copyright © 2002-2025 Daniel A. Steffen,\n
>  Copyright © 2001-2009 Apple Inc.,\n    Copyright © 2001-2002 Jim Ingham &
> Ian Reid",
>   "NSServices" : [
>     {
>       "NSPortName" : "Wish",
>       "NSSendTypes" : [
>         "NSStringPboardType",
>         "NSPasteboardTypeString"
>       ],
>       "NSMessage" : "provideService"
>     }
>   ]
> }
>
> On Tue, Jun 3, 2025 at 6:13 PM Marc Culler <cul...@gm...> wrote:
>
>> There are a few layers to this.
>>
>> First, a quick experiment on my computer reveals that it would be easy to
>> make some parts of the Info.plist available within Tk.  There is no problem
>> accessing the data.  It could be stored, in some format, in a static
>> variable or in the NSApplication object.  And it would be straightforward
>> to add a command which returned some of the data in some form.  I don't
>> know whether ::tk::mac or ::tk::unsupported would be a better namespace for
>> such a command.
>>
>> However, the next layer is quite a cesspool.  I guess everyone thinks it
>> is trivial to design a format for something which is basically a
>> dictionary with strings for keys and a limited set of value types, such as
>> strings, numbers, arrays of strings, arrays of numbers, and other
>> dictionaries which satisfy the same conditions.  The red flag pops up when
>> you list the different schemes that exist for doing this.  Restricting to
>> the most popular, we have at least the .ini format, the .json format, the
>> .toml format, the .yml format and the .plist format.  If this really were
>> such a simple thing, then why would people have tried so many different
>> ways of doing it, and still be completely unable to declare any one of
>> these to be s standard.  And one approach to doing this project would lead
>> to yet another such scheme.  (yayaml?)
>>
>> So, while I think this is an easy thing to do at the first level, if this
>> project is going to go forward, the second level needs to be addressed.
>> What I think is needed is a very clear and specific list of exactly which
>> data need to be made available.  And that list should be very restrictive.
>> The existence of http://www.apple.com/DTDs/PropertyList-1.0.dtd is not
>> very helpful.  It does specify the allowed types for values, but that is
>> obvious (that is a reference to the "o" in "toml").  As far as I know,
>> there does not exist a comprehensive list of allowable keys.  Apple's
>> documentation lists some keys that are allowed but also makes it clear that
>> the list is incomplete and the descriptions of the keys that are documented
>> are often extremely vague.
>>
>> So the starting point would be to (drastically) limit the scope.
>>
>> - Marc
>>
>>
>>
>> On Tue, Jun 3, 2025 at 11:05 AM Donal Fellows <
>> don...@ma...> wrote:
>>
>>> I see no reason why there shouldn't be a small macOS-specific extension
>>> (along the lines of the Windows-specific dde and registry extensions)
>>> distributed with either Tcl or Tk (I'm not sure which would be the better
>>> home, but maybe Tk as that's already set up for working with ObjC and
>>> that's much easier to use for the native APIs from what I see), as long as
>>> it's doing read-only access to the bundle data.
>>>
>>> Read-write access would be something else entirely, and have a *lot* more
>>> complex questions involved (such as around Apple's security policies).
>>>
>>> Donal.
>>>
>>> ------------------------------
>>> *From:* Kevin Walzer <kw...@co...>
>>> *Sent:* Tuesday, June 03, 2025 15:05
>>> *To:* IOhannes m zmoelnig <zmo...@ie...>
>>> *Cc:* tcl...@li... <tcl...@li...>
>>> *Subject:* Re: [TCLCORE] expose content of macOS' Info.plist
>>>
>>> I ask about tdom because I myself don’t have time to implement a
>>> built-in solution.
>>>
>>> On Jun 3, 2025, at 9:20 AM, Kevin Walzer <kw...@co...> wrote:
>>>
>>> 
>>> A property list is just XML. Are you not able to use a Tcl library like
>>> tdom to parse it?
>>>
>>> > On Jun 3, 2025, at 8:36 AM, IOhannes m zmoelnig wrote:
>>> >
>>> > hi.
>>> >
>>> > thanks for your answer, however:
>>> >
>>> >> On 6/3/25 14:22, Kevin Walzer wrote:
>>> >> The usual solution is to manually edit Info.plist before deployment.
>>> It’s not really intended for modification at runtime.
>>> >
>>> > this is not at all what i have been asking for.
>>> >
>>> > what i want is a (read-only) view of the Info.plist within Tcl, so I
>>> can use that information - rather than having to duplicate the same data in
>>> Info.plist and my Tcl scripts.
>>> >
>>> > as I tried to explain: manually *reading* the Info.plist (via `exec
>>> defaults read .../Info`) works but is so slow that we practically cannot
>>> deploy it for a real application.
>>> >
>>> > otoh, Tk already does read this information (see [1]) via macOS native
>>> ways (which I think is zillions time faster).
>>> > however
>>> > - it only reads a few select keys (e.g. "CFBundleName")
>>> > and more importantly:
>>> > - it only uses the read keys internally, but does not make them
>>> available for Tcl scripts.
>>> >
>>> >
>>> > mgfadsr
>>> > IOhannes
>>> >
>>> >
>>> > PS: please CC me in any replies, as i'm not subscribed to this
>>> mailinglist.
>>> >
>>> >
>>> >
>>> > [1]
>>> >
>>> _______________________________________________
>>> Tcl-Core mailing list
>>> Tcl...@li...
>>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>>> [lists.sourceforge.net]
>>> <https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/tcl-core__;!!PDiH4ENfjr2_Jw!EKtX6hP8ah-qjpohdCMXTJlsmBhg_F_zQmx1LkUwMweWmrxs1woHrRoR1QOhuGZKwy_OhlSnd4DsgrjtVbCNhAyCAkA$>
>>>
>>> _______________________________________________
>>> Tcl-Core mailing list
>>> Tcl...@li...
>>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>>>
>>

Re: [TCLCORE] On editing whitespace

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

<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><img width="1" height="1" src="https://fedbdhd.r.af.d.sendibt2.com/tr/op/HUJnbDipnpT-407H2dxcXAHnMetcz3p_9m9MrcPmgEbjBi_S2aymS-Ej4aFQaGpPAKohJLum6ekz3J1FCo0DVeR4LPnIHtkXU5cNU1KJTpl8csesFQVTtqUb6UwniDrtjBZCOdKFyR2TFCW0q-1izrt6DyTehFt81jU4L-pDp83hkMhBOwE0TY_5RuPvOv5FBwhYDRcEW354v-aZOWFGM-4rlIKen0r-" style="mso-hide:all"/><div dir="ltr"></div><div dir="ltr">My practice is up run my edits through Emacs C indentation before committing. I plan to continue that. &nbsp;</div><div dir="ltr"><br><blockquote type="cite">On Jun 4, 2025, at 12:41 PM, Marc Culler &lt;cul...@gm...&gt; wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div>Also, if there really is a need to mess with whitespace, it would be very helpful to produce a commit with *only* whitespace changes and to give it a helpful comment that includes words like "only changes whitespace".</div><div><br></div><div>And, if it ever comes to a decision, I would also vote for spaces.&nbsp; They make life so much simpler when people mix ASCII art with internal code documentation (as in left&nbsp;justifying comments at a certain column.)&nbsp; We can easily afford the few extra bytes of storage.</div><div><br></div><div>- Marc&nbsp;</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, Jun 4, 2025 at 11:26 AM apnmbx-public--- via Tcl-Core &lt;<a href="mailto:tcl...@li...">tcl...@li...</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg-1523586135595426665"><div lang="EN-IN" style="overflow-wrap: break-word;"><div class="m_-1523586135595426665WordSection1"><p class="MsoNormal">On more than one occasion in the past couple of months, commits have been made that include copious changes of spaces to tabs. TIP 247, which presumably is the coding standard Tcl core follows, does not have any mandate to use tabs afaict. If that is the case, can we please desist from such changes? Without getting into a tabs vs spaces war (personally, I prefer spaces) can we just respect whatever exists as long as it meets the standard (indent of 4 etc.) It has practical implications in that, when reviewing diffs or merging, one has to go unnecessarily go through each diff to see what changed.<u></u><u></u></p><p class="MsoNormal"><u></u>&nbsp;<u></u></p><p class="MsoNormal">/Ashok<u></u><u></u></p></div></div>_______________________________________________<br>
Tcl-Core mailing list<br>
<a href="mailto:Tcl...@li..." target="_blank">Tcl...@li...</a><br>
<a href="https://fedbdhd.r.af.d.sendibt2.com/tr/cl/nv2blRcPHWTHV40edr3UZiU3yvdS-IYUlMSDMvLQWh_CfPFq5HnuO9P8Wu9bqAXSkGJgMrwCfKY-I-4RUdF5RGJlsk94X_jl6nfq5KhaoJsoaUMQajUdebWrkvO6F7RkUWuM4gl9iL02BN-Mn_1gAVv9WucncIQ9dTrh70sRrkfctfkalB2iXKWpqLL3nkorjFYnMCv3TVn-ec8NdJzttzS5Cds5zwM9wzNAcUv8mo_Esgk7M_x_H-tzLyuiZ37Glt_6DayD7B16YPkeJc8yLic_I-I242MEhxApGleszV9UiS5ZGBPJYJKzNDyqSSScRA" rel="noreferrer" target="_blank">https://lists.sourceforge.net/lists/listinfo/tcl-core</a><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></body></html>

Re: [TCLCORE] expose content of macOS' Info.plist

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

I have done a bit more experimenting, after I learned of the existence of
Apple's Objective C class NSJSONSerialization.  That class can serialize a
Core Foundation object, such as the NSDictionary returned by [[NSBundle
mainBundle] infoDictionary], producing a sequence of bytes in json format.
There is a JSON parser
<https://core.tcl-lang.org/tcllib/doc/trunk/embedded/md/tcllib/files/modules/json/json.md>
written
by Andreas Kupries in the Tcllib.  It can convert a JSON-encoded byte
sequence into a Tcl dict.  (And that is **way easier** than creating an XML
parser which could convert the bytes in an Info.plist file into a Tcl dict.)

So my proposal would be to add a new command which returns a JSON encoding
of the Info.plist file.  That data could then be processed however the user
wished, but probably most easily by using:
    package require json
    set foo [::json::json2dict [<new command>]]

Below is what the resulting byte sequence would look like for Wish 9.1.

- Marc

{
  "CFBundleName" : "Wish",
  "CFBundleNumericVersion" : 152059904,
  "OSAScriptingDefinition" : "Wish.sdef",
  "CFBundleDevelopmentRegion" : "English",
  "CFBundleVersion" : "9.1a0",
  "CFBundleDocumentTypes" : [
    {
      "CFBundleTypeName" : "NSStringPboardType",
      "CFBundleTypeExtensions" : [
        "tcl",
        "TCL",
        "*"
      ],
      "CFBundleTypeMIMETypes" : [
        "application\/x-tcl",
        "text\/plain"
      ],
      "CFBundleTypeOSTypes" : [
        "TEXT",
        "****"
      ],
      "CFBundleTypeRole" : "Viewer"
    }
  ],
  "CFBundlePackageType" : "APPL",
  "CFBundleIconFile" : "Wish.icns",
  "CFBundleShortVersionString" : "9.1a0",
  "NSHighResolutionCapable" : "True",
  "CFBundleInfoDictionaryVersion" : "6.0",
  "NSAppleScriptEnabled" : true,
  "CFBundleExecutable" : "Wish",
  "CFBundleURLTypes" : [
    {
      "CFBundleTypeRole" : "Viewer",
      "CFBundleURLName" : "Get Foo",
      "CFBundleURLSchemes" : [
        "foo"
      ]
    }
  ],
  "CFBundleIdentifier" : "com.tcltk.wish",
  "CFBundleSignature" : "WiSH",
  "LSRequiresCarbon" : true,
  "LSMinimumSystemVersion" : "10.6.0",
  "CFBundleLocalizations" : [
    "cs",
    "da",
    "de",
    "el",
    "en",
    "en_gb",
    "eo",
    "es",
    "fr",
    "hu",
    "it",
    "nl",
    "pl",
    "pt",
    "ru",
    "sv"
  ],
  "CFBundleGetInfoString" : "Wish Shell 9.1a0,\n    Copyright © 1989-2025
Tcl Core Team,\n    Copyright © 1989-2025 Contributors,\n    Copyright ©
2011-2025 Kevin Walzer\/WordTech Communications LLC,\n    Copyright ©
2014-2025 Marc Culler,\n    Copyright © 2002-2025 Daniel A. Steffen,\n
 Copyright © 2001-2009 Apple Inc.,\n    Copyright © 2001-2002 Jim Ingham &
Ian Reid",
  "NSServices" : [
    {
      "NSPortName" : "Wish",
      "NSSendTypes" : [
        "NSStringPboardType",
        "NSPasteboardTypeString"
      ],
      "NSMessage" : "provideService"
    }
  ]
}

On Tue, Jun 3, 2025 at 6:13 PM Marc Culler <cul...@gm...> wrote:

> There are a few layers to this.
>
> First, a quick experiment on my computer reveals that it would be easy to
> make some parts of the Info.plist available within Tk.  There is no problem
> accessing the data.  It could be stored, in some format, in a static
> variable or in the NSApplication object.  And it would be straightforward
> to add a command which returned some of the data in some form.  I don't
> know whether ::tk::mac or ::tk::unsupported would be a better namespace for
> such a command.
>
> However, the next layer is quite a cesspool.  I guess everyone thinks it
> is trivial to design a format for something which is basically a
> dictionary with strings for keys and a limited set of value types, such as
> strings, numbers, arrays of strings, arrays of numbers, and other
> dictionaries which satisfy the same conditions.  The red flag pops up when
> you list the different schemes that exist for doing this.  Restricting to
> the most popular, we have at least the .ini format, the .json format, the
> .toml format, the .yml format and the .plist format.  If this really were
> such a simple thing, then why would people have tried so many different
> ways of doing it, and still be completely unable to declare any one of
> these to be s standard.  And one approach to doing this project would lead
> to yet another such scheme.  (yayaml?)
>
> So, while I think this is an easy thing to do at the first level, if this
> project is going to go forward, the second level needs to be addressed.
> What I think is needed is a very clear and specific list of exactly which
> data need to be made available.  And that list should be very restrictive.
> The existence of http://www.apple.com/DTDs/PropertyList-1.0.dtd is not
> very helpful.  It does specify the allowed types for values, but that is
> obvious (that is a reference to the "o" in "toml").  As far as I know,
> there does not exist a comprehensive list of allowable keys.  Apple's
> documentation lists some keys that are allowed but also makes it clear that
> the list is incomplete and the descriptions of the keys that are documented
> are often extremely vague.
>
> So the starting point would be to (drastically) limit the scope.
>
> - Marc
>
>
>
> On Tue, Jun 3, 2025 at 11:05 AM Donal Fellows <
> don...@ma...> wrote:
>
>> I see no reason why there shouldn't be a small macOS-specific extension
>> (along the lines of the Windows-specific dde and registry extensions)
>> distributed with either Tcl or Tk (I'm not sure which would be the better
>> home, but maybe Tk as that's already set up for working with ObjC and
>> that's much easier to use for the native APIs from what I see), as long as
>> it's doing read-only access to the bundle data.
>>
>> Read-write access would be something else entirely, and have a *lot* more
>> complex questions involved (such as around Apple's security policies).
>>
>> Donal.
>>
>> ------------------------------
>> *From:* Kevin Walzer <kw...@co...>
>> *Sent:* Tuesday, June 03, 2025 15:05
>> *To:* IOhannes m zmoelnig <zmo...@ie...>
>> *Cc:* tcl...@li... <tcl...@li...>
>> *Subject:* Re: [TCLCORE] expose content of macOS' Info.plist
>>
>> I ask about tdom because I myself don’t have time to implement a built-in
>> solution.
>>
>> On Jun 3, 2025, at 9:20 AM, Kevin Walzer <kw...@co...> wrote:
>>
>> 
>> A property list is just XML. Are you not able to use a Tcl library like
>> tdom to parse it?
>>
>> > On Jun 3, 2025, at 8:36 AM, IOhannes m zmoelnig wrote:
>> >
>> > hi.
>> >
>> > thanks for your answer, however:
>> >
>> >> On 6/3/25 14:22, Kevin Walzer wrote:
>> >> The usual solution is to manually edit Info.plist before deployment.
>> It’s not really intended for modification at runtime.
>> >
>> > this is not at all what i have been asking for.
>> >
>> > what i want is a (read-only) view of the Info.plist within Tcl, so I
>> can use that information - rather than having to duplicate the same data in
>> Info.plist and my Tcl scripts.
>> >
>> > as I tried to explain: manually *reading* the Info.plist (via `exec
>> defaults read .../Info`) works but is so slow that we practically cannot
>> deploy it for a real application.
>> >
>> > otoh, Tk already does read this information (see [1]) via macOS native
>> ways (which I think is zillions time faster).
>> > however
>> > - it only reads a few select keys (e.g. "CFBundleName")
>> > and more importantly:
>> > - it only uses the read keys internally, but does not make them
>> available for Tcl scripts.
>> >
>> >
>> > mgfadsr
>> > IOhannes
>> >
>> >
>> > PS: please CC me in any replies, as i'm not subscribed to this
>> mailinglist.
>> >
>> >
>> >
>> > [1]
>> >
>> _______________________________________________
>> Tcl-Core mailing list
>> Tcl...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>> [lists.sourceforge.net]
>> <https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/tcl-core__;!!PDiH4ENfjr2_Jw!EKtX6hP8ah-qjpohdCMXTJlsmBhg_F_zQmx1LkUwMweWmrxs1woHrRoR1QOhuGZKwy_OhlSnd4DsgrjtVbCNhAyCAkA$>
>>
>> _______________________________________________
>> Tcl-Core mailing list
>> Tcl...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>>
>

Re: [TCLCORE] On editing whitespace

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

Also, if there really is a need to mess with whitespace, it would be very
helpful to produce a commit with *only* whitespace changes and to give it a
helpful comment that includes words like "only changes whitespace".

And, if it ever comes to a decision, I would also vote for spaces.  They
make life so much simpler when people mix ASCII art with internal code
documentation (as in left justifying comments at a certain column.)  We can
easily afford the few extra bytes of storage.

- Marc

On Wed, Jun 4, 2025 at 11:26 AM apnmbx-public--- via Tcl-Core <
tcl...@li...> wrote:

> On more than one occasion in the past couple of months, commits have been
> made that include copious changes of spaces to tabs. TIP 247, which
> presumably is the coding standard Tcl core follows, does not have any
> mandate to use tabs afaict. If that is the case, can we please desist from
> such changes? Without getting into a tabs vs spaces war (personally, I
> prefer spaces) can we just respect whatever exists as long as it meets the
> standard (indent of 4 etc.) It has practical implications in that, when
> reviewing diffs or merging, one has to go unnecessarily go through each
> diff to see what changed.
>
>
>
> /Ashok
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

[TCLCORE] On editing whitespace

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

On more than one occasion in the past couple of months, commits have been
made that include copious changes of spaces to tabs. TIP 247, which
presumably is the coding standard Tcl core follows, does not have any
mandate to use tabs afaict. If that is the case, can we please desist from
such changes? Without getting into a tabs vs spaces war (personally, I
prefer spaces) can we just respect whatever exists as long as it meets the
standard (indent of 4 etc.) It has practical implications in that, when
reviewing diffs or merging, one has to go unnecessarily go through each diff
to see what changed.

 

/Ashok

Re: [TCLCORE] CFV: TIP #712: Add "positive" options to the subst command

[Reinhard M. <rei...@m4...>]

Am 04.06.2025 07:27, schrieb Francois Vogel:

> I particularly like the clever implementation, congratulations!

Credits for the bit-banging tricks go to Sergey!

cu
Reinhard

Re: [TCLCORE] CFV: TIP #712: Add "positive" options to the subst command

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

TIP #712 : YES

- Marc

On Mon, Jun 2, 2025 at 11:48 AM Reinhard Max <rei...@m4...> wrote:

> This is a Call For Votes for TIP 712:
> Add "positive" options to the subst command
>
> Please send your votes until Jun 15, 12:00 UTC
> [clock format 1749988800].
>
> My vote:
> TIP #712:   YES
>
> cu
> Reinhard
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>