Open bugs and questions?

Open bugs and questions?

[Sven Wischnowsky]

Semester-holiday has definitely begun now. So, does anyone have a list
of unfixed bugs and open questions? Bart?

Here are the things I know about, none of these is a real
show-stopper, I think:

12354
  Probably add C-support for _multi_parts. Very low priority.

12344, 12350, 12382
  Make `_arguments --' use the short options, too?
  And make it prefer a user-supplied description if there is one (and
  a automatically found one).
  Not too high priority, either.

12225
  The return value of _arguments with `->state' actions doesn't tell
  if options were completed. This is really only a problem if the
  states are handled in a loop after the call to _arguments. And only
  for some kinds of loops, that don't check if matches were generated.
  I'm not sure how to make this more user-friendly (_arguments-calling-
  function-friendly, that is), so that its easy to find out if
  _arguments didn't add anything or if it added options (and at least
  one of them matched what's on the line).
  Low priorit, too, because it's a very special problem that can be
  solved in the calling function using $compstate[nmatches].

12054, 12071
  There is no way to handle ^D at the beginning of the line with a
  widget, because the zle main loop deals with it directly.
  There weren't any other responses, but I still think it would be
  nice to be able to redefine this behaviour with a widget (would make 
  the behaviour more consistent). But then we would have to either
  change the widgets that are now bound to ^D to handle IGNORE_EOF
  (breaking the setup for people who have it bound to something
  different) or we have to define widgets that handle IGNORE_EOF and
  otherwise do the things the ^D-bound widgets do now (breaking the
  setup for people who have re-bound ^D or bound them to the default).
  Very ugly, does anyone see a good solution?

..., 11973
  Completion after `{a,b}'. Urgh. I don't want to think about this
  before 4.0. After 4.0, I want to think about moving more of the
  completion-setup and -finalisation code into shell code. That would
  give us a better starting point to handle this.

11399, 11400, 11413, 11428
  Context names for styles not used by the completion system
  itself. More specifically, for function that call the completion
  system, but have other styles used directly. And where to document
  them.
  As far as I can see, this is currently only of interest for
  prediction (and probably incremental completion). So maybe we should 
  just use `:predict:...' and `:incremental:...' there and add a
  section to the zle manual for widgets implemented as shell functions 
  where we can describe the contexts and styles.

11465
  Interrupting builtins. E.g. with `cmd1 | builtin ; cmd2' a ^C should 
  keep cmd2 from being run.
  I still don't have an idea how to solve this.



And, directly before 4.0: moving functions (11097, 11099, 11104,
11108), but also including the compctl stuff in Functions/Misc (and
what about the StartupFiles?).

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: Open bugs and questions?

[Peter Stephenson]

Sven wrote:
> Semester-holiday has definitely begun now. So, does anyone have a list
> of unfixed bugs and open questions? Bart?

It's a bit too open, but I'm beginning to think we need a more integrated
feature control system in time for 4.0 (rather than at some unspecified
future date).  There's a lot more in the shell now, and people upgrading
will need a better way of deciding what to keep than deciding separately
which modules and which sets of shell functions they don't need.

You can pretty much do it already, actually, by manipulating OMIT_MODULES,
mymods.conf and FUNCTIONS_INSTALL, so possibly it can be done simply with
an extra pre-configuration tool and/or some additions during the running of
configure.  But I think some addition is necessary, preferably with
fine-grained control over the functions that go into each module (whether
to include Linux functions with the completion module, for example).

I would propose (just off the top of my head) the modules
  old completion
  new completion
  zle add ons (basic zle has to be there, but there are extra builtins/fns)
  zftp
  for completeness, all the other modules in Modules even though they
    are essentially just the library code.
  prompt themes
  any other identifiable sets of functions (maybe even a misc module)

It might be necessary to rewrite some of the existing control mechanism to
facilitate this.  There are extra implications of integration, too:  if the
C code for a feature doesn't work, we don't want to install the functions,
either.

-- 
Peter Stephenson <pws@csr.com>
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

RE: Open bugs and questions?

[Andrej Borsenkow]

>
>
> Semester-holiday has definitely begun now. So, does anyone have a list
> of unfixed bugs and open questions? Bart?
>

Well, long outstanding issue that I always failed to formulate properly (and
hence never posted).

Currently tags are used for two completely different tasks:

- as names for group of generated matches
- as special configuration parameters, used by some completion functions

I never liked this; I believe, it originates in times when we did not have
strict context names. Currently it is

- confusing.
- limits configuration possibilities

What I mean under "limitations" - consider e.g. "hosts" tag. That is used for
list of hostnames. But because it is tag, I can use it just once for a given
context (a.k.a. command parameter). But I could quite sensibly wish two host
sets - "trusted-hosts" and "untrusted-hosts" and complete them differently
using two different lists. This is not (easy)possible now, unless I miss
something.

Such tags simply do not fit into context idea because they represent static
configuration parameter (valid gor completion function) rather then dynamic
(valid for a given context).

Another example is:

bor@itsrm2% gdiff
tags in context :completion::complete:gdiff::
    argument-1 options  (_arguments _diff_options _diff)
ags in context :completion::complete:gdiff:argument-1:
    all-files  (_files _arguments _diff_options _diff)

Do we ever complete using tag argument-1? What I mean, is - it may be used
internally by _arguments - but can user use it? Can it be used to set styles?
As I understand, user sees context xxx:argument-1. I.e. in the above case we
either complete tag "options" in context ":completion::complete:gdiff::" or
tag "all-files" in context ":completion::complete:gdiff:argument-1:".
What I'd like to see is

- remove all "dummy" tags that are used only to look up styles
- replace them with real per-context styles
- conssitently use "default" tag to setup default values for any context (I'd
actually call it "-default-" to stress it's specialness).
- do not list tags that may be used by completion system internally

It is probably still very messed up; sorry.

-andrej

Re: Open bugs and questions?

[Bart Schaefer]

On Aug 1, 11:00am, Sven Wischnowsky wrote:
} 
} Semester-holiday has definitely begun now. So, does anyone have a list
} of unfixed bugs and open questions? Bart?

I haven't updated the one I made just before 3.1.9, but I don't think
everything on that last list got done, either.
 
} 12344, 12350, 12382
}   Make `_arguments --' use the short options, too?

I have a patch for this first part, but:

}   And make it prefer a user-supplied description if there is one (and
}   a automatically found one).

I don't have a patch for that second part.

} 12225
}   The return value of _arguments with `->state' actions doesn't tell
}   if options were completed.

I meant to reply to that message.  I've never been happy with using the
exit status to indicate that an ->state action was taken.  The only
simple test on exit status is true/false; for anything else, you have
to compare against $? -- which means you might as well be testing some
other parameter instead, e.g. [[ -n "$state" ]] which is what most of
the functions that use ->state already do anyway.

So I suggest simply dumping the 300 exit status; zero means that matches
were added, anything else means that no matches were added, and if you
want to use states you test the $state array directly.

} 12054, 12071
}   There is no way to handle ^D at the beginning of the line with a
}   widget, because the zle main loop deals with it directly.

It *is* possible to handle ^D at beginning of line:  stty eof undef
permits it.  This is equivalent to having to turn off flow control in
order to use ^S and ^Q in keybindings.

So maybe the right answer is that `setopt ignoreeof' should affect ZLE
the same way that `setopt noflowcontrol' does.  An actual zero-byte
read would still be handled as it currently is; only ^D in column zero
would be different (actually invoke the ^D binding rather than print
"zsh: use 'logout' to logout.").

THEN we could change delete-char-or-list to print that warning when there
are no characters in the editor buffer, et voila: the default behavior is
exactly as now.
 
} ..., 11973
}   Completion after `{a,b}'. Urgh. I don't want to think about this

Then don't.

} 11399, 11400, 11413, 11428
}   Context names for styles not used by the completion system
}   itself. More specifically, for function that call the completion
}   system, but have other styles used directly. And where to document
}   them.

I've been toying with the idea of adding a "user contributions" chapter
to the manual and throwing into it: incremental-complete-word, zed, the
prompt themes, predict-on, zrecompile, nslookup, etc.  With appropriate
sections, of course.

} 11465
}   Interrupting builtins. E.g. with `cmd1 | builtin ; cmd2' a ^C should 
}   keep cmd2 from being run.

There's also 11468.  I wish I had a suggestion.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Open bugs and questions?

[Bart Schaefer]

On Aug 2,  2:08pm, Sven Wischnowsky wrote:
} Subject: Re: Open bugs and questions?
}
} The `use 'exit' to exit' message is displayed slightly differently:
} below the prompt without displaying a new prompt. Is that ok?

Perhaps it should respect "alwayslastprompt", or something?  Nah, that's
overkill.  But how does your change work when ZLE is disabled?
 
} Hm, because of that and the shell-function widget thing, I'll wait
} before committing it.

I think the shell-function-widget-thing is fine.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Open bugs and questions?

[Sven Wischnowsky]

Bart Schaefer wrote:

> ...
> 
> } 12054, 12071
> }   There is no way to handle ^D at the beginning of the line with a
> }   widget, because the zle main loop deals with it directly.
> 
> It *is* possible to handle ^D at beginning of line:  stty eof undef
> permits it.  This is equivalent to having to turn off flow control in
> order to use ^S and ^Q in keybindings.
> 
> So maybe the right answer is that `setopt ignoreeof' should affect ZLE
> the same way that `setopt noflowcontrol' does.  An actual zero-byte
> read would still be handled as it currently is; only ^D in column zero
> would be different (actually invoke the ^D binding rather than print
> "zsh: use 'logout' to logout.").
> 
> THEN we could change delete-char-or-list to print that warning when there
> are no characters in the editor buffer, et voila: the default behavior is
> exactly as now.

I didn't even needed to mess with the tty settings, changing the test
for eofchar was enough.

I've put the message-display into the zle main loop, invoked for every 
widget that calls an internally implemented widget. Note that this
includes completion widgets (which call the widget mentioned in the
`zle -C' call). This should make it really independent of the widget
bound to ^D for everyone who hasn't bound a shell-function widget to
it.

But now we can do:

  my-eof() {
  if [[ -n "$PREBUFFER$BUFFER" ]]; then
    zle delete-char-or-list
  else
    (( ++exit_count == 5 )) && exit
    zle -M "$exit_count. time"
  fi
  }
  zle -N my-eof
  bindkey '^D' my-eof

Except that there should be a history-write before the exit. And the
counter should probably be reset in precmd or something.


The `use 'exit' to exit' message is displayed slightly differently:
below the prompt without displaying a new prompt. Is that ok?

Hm, because of that and the shell-function widget thing, I'll wait
before committing it.

Bye
 Sven

Index: Doc/Zsh/options.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/options.yo,v
retrieving revision 1.10
diff -u -r1.10 options.yo
--- Doc/Zsh/options.yo	2000/07/19 21:37:18	1.10
+++ Doc/Zsh/options.yo	2000/08/02 12:01:30
@@ -573,6 +573,11 @@
 of tt(exit) or tt(logout) instead.
 However, ten consecutive EOFs will cause the shell to exit anyway,
 to avoid the shell hanging if its tty goes away.
+
+Also, if this option is set and the Zsh Line Editor is used, widgets
+implemented by shell functions can be bound to EOF (normally
+Control-D) without printing the normal warning message.  This works
+only for normal widgets, not for completion widgets.
 )
 pindex(INC_APPEND_HISTORY)
 cindex(history, incremental appending to a file)
Index: Src/Zle/zle_main.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/zle_main.c,v
retrieving revision 1.8
diff -u -r1.8 zle_main.c
--- Src/Zle/zle_main.c	2000/07/27 17:48:48	1.8
+++ Src/Zle/zle_main.c	2000/08/02 12:01:31
@@ -76,7 +76,10 @@
 /**/
 int insmode;
 
-static int eofchar, eofsent;
+/**/
+mod_export int eofchar;
+
+static int eofsent;
 static long keytimeout;
 
 #ifdef HAVE_SELECT
@@ -556,7 +559,7 @@
 	reselectkeymap();
 	selectlocalmap(NULL);
 	bindk = getkeycmd();
-	if (!ll && isfirstln && c == eofchar) {
+	if (!ll && isfirstln && unset(IGNOREEOF) && c == eofchar) {
 	    eofsent = 1;
 	    break;
 	}
@@ -630,26 +633,32 @@
     } else if((w = func->widget)->flags & (WIDGET_INT|WIDGET_NCOMP)) {
 	int wflags = w->flags;
 
-	if(!(wflags & ZLE_KEEPSUFFIX))
-	    removesuffix();
-	if(!(wflags & ZLE_MENUCMP)) {
-	    fixsuffix();
-	    invalidatelist();
+	if (keybuf[0] == eofchar && !keybuf[1] &&
+	    !ll && isfirstln && isset(IGNOREEOF)) {
+	    showmsg((!islogin) ? "use 'exit' to exit." : "use 'logout' to logout.");
+	    ret = 1;
+	} else {
+	    if(!(wflags & ZLE_KEEPSUFFIX))
+		removesuffix();
+	    if(!(wflags & ZLE_MENUCMP)) {
+		fixsuffix();
+		invalidatelist();
+	    }
+	    if (wflags & ZLE_LINEMOVE)
+		vilinerange = 1;
+	    if(!(wflags & ZLE_LASTCOL))
+		lastcol = -1;
+	    if (wflags & WIDGET_NCOMP) {
+		int atcurhist = histline == curhist;
+		compwidget = w;
+		ret = completecall(args);
+		if (atcurhist)
+		    histline = curhist;
+	    } else
+		ret = w->u.fn(args);
+	    if (!(wflags & ZLE_NOTCOMMAND))
+		lastcmd = wflags;
 	}
-	if (wflags & ZLE_LINEMOVE)
-	    vilinerange = 1;
-	if(!(wflags & ZLE_LASTCOL))
-	    lastcol = -1;
-	if (wflags & WIDGET_NCOMP) {
-	  int atcurhist = histline == curhist;
-	    compwidget = w;
-	    ret = completecall(args);
-	    if (atcurhist)
-		histline = curhist;
-	} else
-	    ret = w->u.fn(args);
-	if (!(wflags & ZLE_NOTCOMMAND))
-	    lastcmd = wflags;
 	r = 1;
     } else {
 	Eprog prog = getshfunc(w->u.fnnam);

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

RE: Open bugs and questions?

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> Currently tags are used for two completely different tasks:
> 
> - as names for group of generated matches

I guess you mean `type' (at least that's what we called it in the docs ;-)

They are not used as `names for' what we call `groups'. Group names
are set with the group-name style. It's just that we offer a very
convenient way to name groups after the tags, so that all possible
groups have different names.

> - as special configuration parameters, used by some completion functions

Used to disambiguate between different meanings/uses of a style or to
simplify forming sensible context strings when defining styles.

I agree that this isn't very clean, but I don't have much problems
with it, actually. And it's documented (above the tag list).

> I never liked this; I believe, it originates in times when we did not have
> strict context names. Currently it is
> 
> - confusing.
> - limits configuration possibilities
> 
> What I mean under "limitations" - consider e.g. "hosts" tag. That is used for
> list of hostnames. But because it is tag, I can use it just once for a given
> context (a.k.a. command parameter). But I could quite sensibly wish two host
> sets - "trusted-hosts" and "untrusted-hosts" and complete them differently
> using two different lists. This is not (easy)possible now, unless I miss
> something.

If you can distinguish the elements of the two sets (and with a
complete list this is always possible), use tag labels.

Otherwise you want a way to influence how *often* the completion
functions generate matches and *which* matches on each try. Even that
is possible (either with tag labels or with completer-labels). But
styles weren't really thought to offer the possibilty to re-programme
completion functions. So, if you feel that you have to (or more)
completely different *types* of hosts (or whatever) -- copy and modify 
the functions completing hosts (or whatever). That's what they are for.

> Such tags simply do not fit into context idea because they represent static
> configuration parameter (valid gor completion function) rather then dynamic
> (valid for a given context).
> 
> Another example is:
> 
> bor@itsrm2% gdiff
> tags in context :completion::complete:gdiff::
>     argument-1 options  (_arguments _diff_options _diff)
> ags in context :completion::complete:gdiff:argument-1:
>     all-files  (_files _arguments _diff_options _diff)
> 
> Do we ever complete using tag argument-1? What I mean, is - it may be used
> internally by _arguments - but can user use it? Can it be used to set styles?
> As I understand, user sees context xxx:argument-1. I.e. in the above case we
> either complete tag "options" in context ":completion::complete:gdiff::" or
> tag "all-files" in context ":completion::complete:gdiff:argument-1:".

I agree that his isn't that nice and I wasn't too happy with it. But,
yes, they *are* used. And you can set styles for it and they will be
used, for example when the completion function uses an action of the
form `(a b c)'. In that case we don't have another way to get at a tag 
than by using the automatically created one.

> What I'd like to see is
> 
> - remove all "dummy" tags that are used only to look up styles

Eh? If they are used to look up styles, they are obviously used.

> - replace them with real per-context styles

I don't understand that, I think. Or do you mean that we should get
rid of the tags and rename the styles so that the style name itself is 
enough to disambiguate? And if you mean that: we already renamed
styles (twice, I think) to make this possible. So, if you know of any
styles we missed, tell us about them.

> - conssitently use "default" tag to setup default values for any context (I'd
> actually call it "-default-" to stress it's specialness).

Again: could you give us examples where you would want to set default
values for styles where you can't use `:completion:*' as the context
pattern?

> - do not list tags that may be used by completion system internally

Agreed, and I actually thought about this, too. By the fact that I
didn't send a patch you can see that I don't really know how to do
this (I haven't thought that much about it, though, having been busy
with a lot of other things at the time).

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de