zsh-workers
 help / color / mirror / code / Atom feed
From: Peter Stephenson <pws@ibmth.df.unipi.it>
To: zsh-workers@sunsite.auc.dk
Subject: Re: PATCH: collist v2.0
Date: Tue, 22 Jun 1999 10:51:43 +0200	[thread overview]
Message-ID: <9906220851.AA23188@ibmth.df.unipi.it> (raw)
In-Reply-To: "Sven Wischnowsky"'s message of "Tue, 22 Jun 1999 10:25:34 DFT." <199906220825.KAA23802@beta.informatik.hu-berlin.de>

Sven Wischnowsky wrote:
> Here is an improved version:

Magic

> - There is now another hook which is caught by the module which allows 
>   one to replace menu-completion with selection by setting the
>   parameter `ZLS_SELECT'. If it is set, you get into menu-selection
>   whenever menucompletion would be used.
>   This is ugly, it should be an option...

It's hard to know what to do.  You don't expect to be able to set an option
only when a module is loaded, so I don't think we can have module-dependent
options.  But zle related options are in the main shell even if zle isn't
loaded.  Maybe we just have to make it an option (menuselect, obviously)
anyway and make a bigger effort to load complist when necessary, so you
would get an error from completion the first time if it's not available.

Also, we should definitely change zmodload to be able to list builtin
modules, which means adding a reduced version of zmodload even for shells
without dynamic linking.  It's getting too inconvenient not to have the
information available in functions.  Two possibilities are

- zmodload lists all modules, whether builtin or not, but marks the builtin
  one differently -- this makes it harder if you want to check $(zmodload)
- some new options will list all modules or builtin modules.  This is
  probably better but the problem is that with a non-dynamically-linked
  shell you always get no output from running `zmodload' on its own which
  is a little Zen-like.  Maybe it should return status 1 in that case as a
  test for dynamic loading, but status 0 when the list includes builtin
  modules.

And I still think the zle command needs the ability to list builtin
widgets, too.

One other thing:  I'm still a bit worried about the way undo works, where
the first time nothing happens if there isn't a suffix to undo.  It's fine
if there is a suffix which you can undo separately, but I'd be tempted to
make it skip over that if it does nothing.  That would make it harder if
you used undo in programming, however, but I don't think people do.

> - If you read the manual or the collist.c file you'll notice that I've 
>   changed `collist' to `complist' because the more interesting part
>   doesn't have anything to do with colouring lists. But of course I
>   can't build a patch that renames your files.
>   Peter, could you rename collist.{c,mdd}, mod_collist.yo, and change
>   the xmods.conf entry? (Including changing the names of the
>   setup/cleanup-functions in collist.c?) Should I send you a patch for 
>   as much as I can?

I've done this and I'll try and get pws-$((N+1)) out at the end of the
week, particularly since I'm busy next week.  There were some other minor
changes:  a tt(no) in the manual was missing a close parenthesis, some
dependencies for mod_complist.yo needed adding in the Makefile, a nodref
referred to `The complist module' instead of `The complist Module'.  These
are appended below, but it assmues the name changes.

--- Doc/Makefile.in~	Thu Jun 10 17:28:45 1999
+++ Doc/Makefile.in	Tue Jun 22 10:16:22 1999
@@ -56,9 +56,9 @@
 Zsh/filelist.yo Zsh/files.yo Zsh/func.yo Zsh/grammar.yo Zsh/guide.yo \
 Zsh/index.yo Zsh/intro.yo Zsh/invoke.yo Zsh/jobs.yo Zsh/metafaq.yo \
 Zsh/modules.yo Zsh/mod_cap.yo Zsh/compwid.yo Zsh/compsys.yo \
-Zsh/mod_clone.yo Zsh/mod_comp1.yo Zsh/mod_compctl.yo Zsh/mod_deltochar.yo \
-Zsh/mod_example.yo Zsh/mod_files.yo Zsh/mod_mapfile.yo Zsh/mod_stat.yo \
-Zsh/mod_zle.yo Zsh/options.yo \
+Zsh/mod_clone.yo Zsh/mod_comp1.yo Zsh/mod_compctl.yo Zsh/mod_complist.yo \
+Zsh/mod_deltochar.yo Zsh/mod_example.yo Zsh/mod_files.yo \
+Zsh/mod_mapfile.yo Zsh/mod_stat.yo Zsh/mod_zle.yo Zsh/options.yo \
 Zsh/params.yo Zsh/prompt.yo Zsh/redirect.yo Zsh/restricted.yo \
 Zsh/seealso.yo Zsh/zftpsys.yo Zsh/zle.yo
 
@@ -131,9 +131,10 @@
            Zsh/prompt.yo Zsh/restricted.yo
 
 zshmodules.1: Zsh/modules.yo Zsh/mod_cap.yo Zsh/mod_clone.yo \
-              Zsh/mod_comp1.yo Zsh/mod_compctl.yo Zsh/mod_deltochar.yo \
-              Zsh/mod_example.yo Zsh/mod_files.yo Zsh/mod_mapfile.yo \
-              Zsh/mod_sched.yo Zsh/mod_stat.yo Zsh/mod_zftp.yo Zsh/mod_zle.yo
+              Zsh/mod_comp1.yo Zsh/mod_complist.yo Zsh/mod_compctl.yo \
+              Zsh/mod_deltochar.yo Zsh/mod_example.yo Zsh/mod_files.yo \
+              Zsh/mod_mapfile.yo Zsh/mod_sched.yo Zsh/mod_stat.yo \
+              Zsh/mod_zftp.yo Zsh/mod_zle.yo
 
 zshoptions.1: Zsh/options.yo
 
--- Doc/Zsh/compsys.yo~	Tue Jun 22 10:02:48 1999
+++ Doc/Zsh/compsys.yo	Tue Jun 22 10:18:24 1999
@@ -168,7 +168,7 @@
 tt(menu-expand-or-complete), or tt(reverse-menu-complete). If the
 tt(complist) module is loaded (see
 ifzman(zmanref(zshmodules))\
-ifnzman(noderef(The complist module))\
+ifnzman(noderef(The complist Module))\
 ), the tt(menu-select) widget can be used, too.
 
 The widget is then bound to all the var(key-sequences) given, if any: when
--- Doc/Zsh/mod_complist.yo~	Tue Jun 22 10:02:48 1999
+++ Doc/Zsh/mod_complist.yo	Tue Jun 22 10:14:05 1999
@@ -65,7 +65,7 @@
 for the file-type or the last matching specification with a `tt(*)',
 the value of tt(rc), the string to display for the match itself, and
 then the value of tt(ec) if that is defined or the values of tt(lc),
-tt(no, and tt(rc) if tt(ec) is not defined.
+tt(no), and tt(rc) if tt(ec) is not defined.
 
 The default values are ISO 6429 (ANSI) compliant and can be used on
 vt100 compatible terminals such as tt(xterm)s. On monochrome terminals


-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy


  reply	other threads:[~1999-06-22  9:20 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-06-22  8:25 Sven Wischnowsky
1999-06-22  8:51 ` Peter Stephenson [this message]
1999-06-22 17:06   ` Bart Schaefer
1999-06-22  9:04 ` Peter Stephenson
1999-06-22 11:52 ` Andrej Borsenkow
1999-06-22  8:49 Sven Wischnowsky
1999-06-22  9:56 Sven Wischnowsky
1999-06-22 10:35 Sven Wischnowsky
1999-06-22 12:36 Sven Wischnowsky
1999-06-23  8:43 Sven Wischnowsky
1999-06-23  8:59 ` Andrej Borsenkow

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9906220851.AA23188@ibmth.df.unipi.it \
    --to=pws@ibmth.df.unipi.it \
    --cc=zsh-workers@sunsite.auc.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).