zsh-workers
 help / color / mirror / code / Atom feed
From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
To: zsh-workers@sunsite.dk
Subject: About the new long/short options changes
Date: Fri, 20 Jul 2001 05:01:15 +0000	[thread overview]
Message-ID: <1010720050115.ZM6144@candle.brasslantern.com> (raw)

Just now had a chance to compile this up and try it.

I mostly like the way it looks in listings, though I wish it would line up
the single-letter options in a column (or else always list the short form
first when there is one, though that might look odd when some of the long
forms have no short form).

However, I strongly *dis*like the way it works in menu-selection.  So much
so that I'd rather just turn it off entirely if it can't be made to work
better.  In particular I don't want selection to consume twice as many
lines (half of which are largely blank) as listing consumes.  I find it
better to have listing consume more lines in the first place than to have
the display change so radically when switching from listing to selection.

Sven wrote:
} Adding a style so that menu selection allows to select only one of the
} options would be a lot easier to write.  Making it display only one of
} the options per line (instead of a duplicated `-H, --help') is something
} I thought about, too, but that would require that we are able to tell in
} _describe if we are going to enter menu selection.  And that isn't
} always possible because it might depend on the number of matches
} generated.  If people would be satisfied with an approximation, i.e.
} simplifying the strings if it thinks it will enter menu selection, but
} probably sometimes entering menu selection with duplicated `-H, --help',
} I could probably implement that without much work.

I would not be happy with an approximation (if that's what gets done, so
be it, I'll just turn it all off).  Offering only one of the choices when
menu-selecting would be much better than what's happening now.  Best would
be if both could be selected right where they first appear, from the same
single line with the explanation string (which is, in part, why I ask for
the short forms to appear in a column).

} And about using `"' instead of the `|': [...]
} 
}   % foo -<TAB>
}   -H  --help    -- print help
}       "         --     "

This would, IMO, serve no purpose other than to emphasize the amount of
screen real estate that we're wasting on useless white space.

} Anyone else want to draw some pictures? ;-)

What I'd like to see, I think, is something like the following (where `['
and `]' delimit the menu-selection highlight).  For purposes of drawing
a more interesting picure, suppose that the -X option doesn't exist.

  Completing option
 [--binary                ] -b -- Unix line endings LF
  --change-cygdrive-prefix  -c -- cygdrive prefix
  --cygwin-executable          -- all files under mountpoint are cygwin e
  --executable              -x -- all files under mountpoint are executab
  --force                   -f -- be silent
  --import-old-mounts       -i -- import old mounts
  --show-cygdrive-prefix    -p -- show cygdrive prefix
  --system                  -s -- system-wide mount point
  --text                    -t -- (default) DOS line endings CR-LF
  --user                    -u -- (default)user private mount point

TAB to the next selection (list now truncated for brevity):

  Completing option
  --binary                 [-b -- Unix line endings LF                   ]
  --change-cygdrive-prefix  -c -- cygdrive prefix
  --cygwin-executable          -- all files under mountpoint are cygwin e
  --executable              -x -- all files under mountpoint are executab
  --force                   -f -- be silent

After three more TABs:

  Completing option
  --binary                  -b -- Unix line endings LF
  --change-cygdrive-prefix  -c -- cygdrive prefix
 [--cygwin-executable          -- all files under mountpoint are cygwin e]
  --executable              -x -- all files under mountpoint are executab
  --force                   -f -- be silent

See where this is going?

I recognize that this is probably quite difficult to pull off, especially
in cases where there might be more than two options that have the same
description.  So I'd settle for only being able to select one of the
choices on each line (provided that ordinary menu completion can at least
optionally still cycle through all possibilities).

-- 
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   


             reply	other threads:[~2001-07-20  5:03 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-20  5:01 Bart Schaefer [this message]
2001-07-20  7:38 ` Sven Wischnowsky
2001-07-20  9:26   ` Bart Schaefer
2001-07-20  9:43     ` Andrej Borsenkow
2001-07-25  8:49     ` Sven Wischnowsky
2001-07-25  9:15       ` Borsenkow Andrej
2001-07-25  9:20         ` Sven Wischnowsky
2001-07-25  9:24           ` Borsenkow Andrej
2001-07-25 10:13         ` Peter Stephenson
2001-07-25 10:43           ` Sven Wischnowsky
2001-07-25 11:36             ` Borsenkow Andrej
2001-07-25 12:16               ` Sven Wischnowsky
2001-07-25 12:35                 ` Sven Wischnowsky
2001-07-25 17:49             ` Bart Schaefer
2001-07-27 12:53               ` Sven Wischnowsky
2001-07-30  8:22                 ` Sven Wischnowsky
2001-07-30  8:38                   ` Sven Wischnowsky

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=1010720050115.ZM6144@candle.brasslantern.com \
    --to=schaefer@candle.brasslantern.com \
    --cc=zsh-workers@sunsite.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).