Would 'package search arg' be worth considering?

[Dave]

As a casual Tcl programmer I often do not remember exact package names.
Is it 'what' or 'What' or 'whatIsThis'? I then have to find the
appropriate pkgIndex file in the lib/ directory.

Would this trivial extension (patch attached) to the 'package' command
be worth considering?

Main console display active (Tcl8.6.8 / Tk8.6.8)
49 % packa lkj
bad option "lkj": must be forget, ifneeded, names, prefer, present,
provide, require, search, unknown, vcompare, versions, or vsatisfies
50 % packa sea
wrong # args: should be "package search string"
51 % packa sea lkj
52 % packa sea gdt
Gdtclft


--
computerjock AT mail DOT com

[jsunth...@gmail.com]

Must be the zeitgeist. Just yesterday I pondered whether extending the [package] ensemble specifically for interactive use-cases would be appropriate. I think this is awesome; I'm really interested in the thoughts of others on your idea.

[Arjen Markus]

You could write a short TIP on this - the advantage is that it will get better visibility and a more thorough review than a posting here.

Regards,

Arjen

[stefan]

> Would this trivial extension (patch attached) to the 'package' command
> be worth considering?

You would have to mind the various restrictions of [package names], I am afraid. For instance, it is cold without a prior [package require] on an unknown pkg.

See https://wiki.tcl.tk/9883 for the combined records.

You would have to verify how to best warm up the [package] repo (incl. Tcl modules). One option might be to run an explicit:

{*}[package unknown] "" or [package require ""]

After that, [package names] will appear populated.

Beyond that point, whether a dedicated [package search] delivers anything beyond a on-liner [lsearch ...] (even in interactive mode), is a matter of taste, IMHO.

Stefan

[Dave]

On 2/8/2018 3:25 AM, stefan wrote:
>> Would this trivial extension (patch attached) to the 'package' command
>> be worth considering?
>
> You would have to mind the various restrictions of [package names], I am afraid. For instance, it is cold without a prior [package require] on an unknown pkg.
>
> See https://wiki.tcl.tk/9883 for the combined records.
>
> You would have to verify how to best warm up the [package] repo (incl. Tcl modules). One option might be to run an explicit:
>
> {*}[package unknown] "" or [package require ""]
>
> After that, [package names] will appear populated.

I'm sure I don't understand all the ramifications discussed in the above
reference.

My Tcl installation is on win7x64. I compile the latest Tcl/Tk and copy
it into my old 8.6.4 activestate installation folder with init.tcl
patched to include the activestate changes. This preserves the teapot
and the stuff it has installed.

You are correct that a "package require {}" is needed. I was testing on
windows via tkcon which somewhere along the line populated all packages.

As far as modules go, I searched the modules installed by teapot:

MSYS2 /c/program files1/tcl/lib/teapot/package/tcl/teapot/tcl8
$ fgrep package */textutil/* | fgrep provide | uniq
8.2/textutil/adjust-0.7.3.tm:package provide textutil::adjust 0.7.3
8.2/textutil/repeat-0.7.tm:package provide textutil::repeat 0.7
8.2/textutil/split-0.7.tm:package provide textutil::split 0.7
8.2/textutil/split-0.7.tm:if {[package vsatisfies [package provide
Tcl]8.3]} {
8.2/textutil/split-0.7.tm:package provide textutil::split 0.7
8.2/textutil/string-0.8.tm:package provide textutil::string 0.8
8.2/textutil/tabify-0.7.tm:package provide textutil::tabify 0.7
8.2/textutil/trim-0.7.tm:package provide textutil::trim 0.7
8.4/textutil/expander-1.3.1.tm:package provide textutil::expander 1.3.1

I then ran:

c:\users\imdave\appdata\local\temp>type t.tcl
catch {package require ""}
puts [llength [package names]]
foreach a $::argv {
puts "$a: [package search $a]"
}

c:\users\imdave\appdata\local\temp>where tclsh
C:\Program Files\Tcl\bin\tclsh.exe

c:\users\imdave\appdata\local\temp>tclsh t.tcl rim plit
630
rim: textutil::trim
plit: dtplite textutil::split

It seems to me that the packages provided via modules are included.

>
> Beyond that point, whether a dedicated [package search] delivers anything beyond a on-liner [lsearch ...] (even in interactive mode), is a matter of taste, IMHO.
>

You're right there. The line(s) required would be something like
lsearch -glob -all -nocase [package names] *what*

followed by

lindex [package names] x

where 'x' is one of the values returned by lsearch.

Not only would I invariably make a mistake while typing but I have to do
it every time I forget an exact package name.

Anyway, thanks for the feedback. I will just patch my local installation
and be happy. :-)

[stefan]

Hi Dave,

> Anyway, thanks for the feedback. I will just patch my local installation
> and be happy. :-)

That's certainly the way to go for you. Why not put your pkg search alias in your RC file? Rather than patching your installation ... See http://wiki.tcl.tk/689

Stefan

P.S.: Also check the package-listing helper on that page.

[Dave]

On 2/9/2018 6:56 AM, stefan wrote:
> Hi Dave,
>
>> Anyway, thanks for the feedback. I will just patch my local installation
>> and be happy. :-)
>
> That's certainly the way to go for you. Why not put your pkg search alias in your RC file? Rather than patching your installation ... See http://wiki.tcl.tk/689
>

I thought about that but for some reason my windows shortcut to tkcon
does not cause wish to read wishrc.tcl. If I start wish explicitly then
it does.

> Stefan
>
> P.S.: Also check the package-listing helper on that page.
>