* Open bugs and questions?
@ 2000-08-01 9:00 Sven Wischnowsky
2000-08-01 9:19 ` Peter Stephenson
` (2 more replies)
0 siblings, 3 replies; 7+ messages in thread
From: Sven Wischnowsky @ 2000-08-01 9:00 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Open bugs and questions?
2000-08-01 9:00 Open bugs and questions? Sven Wischnowsky
@ 2000-08-01 9:19 ` Peter Stephenson
2000-08-01 9:46 ` Andrej Borsenkow
2000-08-01 15:09 ` Bart Schaefer
2 siblings, 0 replies; 7+ messages in thread
From: Peter Stephenson @ 2000-08-01 9:19 UTC (permalink / raw)
To: Zsh hackers list
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* RE: Open bugs and questions?
2000-08-01 9:00 Open bugs and questions? Sven Wischnowsky
2000-08-01 9:19 ` Peter Stephenson
@ 2000-08-01 9:46 ` Andrej Borsenkow
2000-08-01 15:09 ` Bart Schaefer
2 siblings, 0 replies; 7+ messages in thread
From: Andrej Borsenkow @ 2000-08-01 9:46 UTC (permalink / raw)
To: zsh-workers
>
>
> 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Open bugs and questions?
2000-08-01 9:00 Open bugs and questions? Sven Wischnowsky
2000-08-01 9:19 ` Peter Stephenson
2000-08-01 9:46 ` Andrej Borsenkow
@ 2000-08-01 15:09 ` Bart Schaefer
2 siblings, 0 replies; 7+ messages in thread
From: Bart Schaefer @ 2000-08-01 15:09 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* RE: Open bugs and questions?
@ 2000-08-01 10:58 Sven Wischnowsky
0 siblings, 0 replies; 7+ messages in thread
From: Sven Wischnowsky @ 2000-08-01 10:58 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Open bugs and questions?
@ 2000-08-02 12:08 Sven Wischnowsky
2000-08-02 16:24 ` Bart Schaefer
0 siblings, 1 reply; 7+ messages in thread
From: Sven Wischnowsky @ 2000-08-02 12:08 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2000-08-02 16:24 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-08-01 9:00 Open bugs and questions? Sven Wischnowsky
2000-08-01 9:19 ` Peter Stephenson
2000-08-01 9:46 ` Andrej Borsenkow
2000-08-01 15:09 ` Bart Schaefer
2000-08-01 10:58 Sven Wischnowsky
2000-08-02 12:08 Sven Wischnowsky
2000-08-02 16:24 ` Bart Schaefer
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).