zsh-workers
 help / color / mirror / code / Atom feed
From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
To: zsh-workers@sunsite.auc.dk
Subject: Re: PATCH: expansion (was: Re: PATCH: Re: blah*[TAB] (difference between 3.1.6 and 3.1.9))
Date: Wed, 7 Jun 2000 15:28:08 +0000	[thread overview]
Message-ID: <1000607152808.ZM8074@candle.brasslantern.com> (raw)
In-Reply-To: <200006070646.IAA11684@beta.informatik.hu-berlin.de>
In-Reply-To: <200006070707.JAA11585@beta.informatik.hu-berlin.de>

On Jun 7,  8:46am, Sven Wischnowsky wrote:
} Subject: PATCH: expansion (was: Re: PATCH: Re: blah*[TAB] (difference betw
}
} 
} Bart Schaefer wrote:
} 
} > It was 11777.  Confusion about a double-negative, or something like that.

I'm going to stop responding to articles with numbers ending in three 7s.

} > Sven changed a test to be:
} > 
} > 	if ! zstyle -T ":completion:${curcontext}:" add-space; then
} 
} I know all that.

Of course YOU know all that.  Wayne might not.

} And I still insist, that the current behaviour is
} correct; from the docs:
} 
}   This style is used by the tt(_expand) completer.  If it is `true' (the
}   default), a space will be inserted after all words resulting from the 
}   expansion (except for directory names which get a slash).
} 
} So, it appends a space to the generated expansion.
} 
} What you folks really want is a more sophisticated add-space

Actually what I want is some way to know without looking at the docs
whether a style defaults to `true' when not set or to `false' when not
set.  Back in the mists of time we used to have options whose names
started with `no' so that you'd know that setting it turned something
off, rather than on, and there was no non-`no' (I sound like a backup
singer for a '50s rock group) option to unset instead, so looking at
the output of `setopt' was enough to tell you what the heck was going
on:  The default behavior changed only when something became true, and
"not set" always meant false.

Pardon me, I just go off on that from time to time.  I'm not really
suggesting that we redo it all again at this point.

Anyway, I assumed without looking that add-space was supposed to default
to false when not set, since that had been the previous behavior.

} namely (I'm guessing ;-): if add-space if false, never add
} a space; if it is true, add a space if the generated word is the name
} of an existing file.

I just speculated exactly this in my reply to the expand-or-complete
thread, but I don't think it makes as much sense as does appending a
space only when multiple words result.

} But then I would insist, that we change add-space to:
} 
}   - true: always add a space (after all, one might want to use it to
}            generate names of non-existing files)
}   - false: never add a space
}   - exisiting: add a space only if the word is the name of an
}            exisiting file
} 
} Ok?

Whether that is "ok" depends more on what the behavior is when it is not
set at all than on what the possible settings are.

-- 
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:[~2000-06-07 15:28 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-06-07  6:46 Sven Wischnowsky
2000-06-07  7:07 ` Sven Wischnowsky
2000-06-07 15:28   ` Bart Schaefer [this message]
2000-06-07 15:31   ` Bart Schaefer
2000-06-07 22:21 ` PATCH: expansion Wayne Davison
2000-06-08 10:03   ` Oliver Kiddle

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=1000607152808.ZM8074@candle.brasslantern.com \
    --to=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).