zsh-workers
 help / color / mirror / code / Atom feed
From: Wayne Davison <wayned@users.sourceforge.net>
To: Bart Schaefer <schaefer@candle.brasslantern.com>
Cc: Zsh Workers <zsh-workers@sunsite.auc.dk>
Subject: Re: spaceflag question; remhist() going away
Date: Mon, 17 Jul 2000 11:29:25 -0700 (PDT)	[thread overview]
Message-ID: <Pine.LNX.4.21.0007171052240.1015-100000@phong.blorf.net> (raw)
In-Reply-To: <1000717164610.ZM22230@candle.brasslantern.com>

On Mon, 17 Jul 2000, Bart Schaefer wrote:
> I like the existing aliasing solution better; under what circumstances
> would you want to match more of the command line than the command name?

The matching rule would allow more general command-name rules, plus
line-oriented rules that name-oriented support don't allow.  For
instance:  ignoring lines that are just 1 or 2 chars long; ignoring
the make command unless it had an argument or was a part of a compound
statement; ignoring the history command, but only if it is not a part
of a compound statement (such as having its output piped into a
script); ignoring lines that begin with whitespace (including tab)
without having any extra alias-checking rules done; ignoring a lynx
command that uses the -auth option; etc.

The plus side is that a line-matching rule is much more flexible.  The
down side is that a user has to understand complex patterns to be able
to use it effectively.  Some good examples would get the casual user
going, though.

> } so I don't plan to re-implement this space-starting-alias
> } functionality (at least, not right away).
> 
> I hope you change your mind.

I have been considering how to do this even while not planning to
fiddle with it right away.  I think the easiest way to get it done
would be to have the history code look up the line's first word in
the aliases, and check it for a space.  This might be slightly more
restrictive than the old code which (I believe) would ignore the
line if any command in a sequence of commands was aliased to start
with a space, but that functionality doesn't strike me as very
desirable anyway (since compound commands are often the ones you
most want to save).

Since this functionality was never documented and since nobody using
the 3.1.x codebase has (apparently) ever missed it, I'm wondering if
we should just leave it out.  It shouldn't be hard to add the check I
described above if we think we need it, though, so after I get the
pattern stuff implemented, I may just go ahead and take a look at it.

Anyone else want to add their opinion to the subject?

..wayne..


  reply	other threads:[~2000-07-17 18:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-07-17  1:54 Wayne Davison
2000-07-17  8:57 ` Peter Stephenson
2000-07-17 10:04   ` Wayne Davison
2000-07-17 16:46     ` Bart Schaefer
2000-07-17 18:29       ` Wayne Davison [this message]
2000-07-17 19:44         ` Wayne Davison
2000-07-18  5:23 Felix Rosencrantz

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=Pine.LNX.4.21.0007171052240.1015-100000@phong.blorf.net \
    --to=wayned@users.sourceforge.net \
    --cc=schaefer@candle.brasslantern.com \
    --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).