Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

Beeps in popup windows

I'm using TCC 13.0.26.

I want to use the new feature that lets you type a search string in a popup window to remove non-matching entries. I'm finding that I'm hearing anoying beeps as I type if the search string contains wildcards. For example, I bring up the history window and then type *zip* to eliminate all lines that don't have "zip" somewhere in them. I hear beep as I type the z and the i. Can these beeps be eliminated?

--
Howard
 
On Wed, 19 Oct 2011 21:33:37 -0400, Howard Goldstein <>
wrote:

|I'm using TCC 13.0.26.
|
|I want to use the new feature that lets you type a search string in a popup window to remove non-matching entries. I'm finding that I'm hearing anoying beeps as I type if the search string contains wildcards. For example, I bring up the history window and then type *zip* to eliminate all lines that don't have "zip" somewhere in them. I hear beep as I type the z and the i. Can these beeps be eliminated?

The only beeps I'd welcome would be no-match beeps (and I could do without
them).

There's something else strange about those searches ...

Command history popup ... type '*' ... still see all commands ... add 'z' ... no
sound ... see (only)

Code:
ungzip /v test.gz
ungzip test.gz
dir s:\ /w /z
dir s:\ /4 /z
set bar=zz
echo %zz

... add 'i' ... now I get a beep and nothing is shown BUT SOMETHING SHOULD BE
SHOWN

... now add 'p' and I see (only)

Code:
which unzip

Why no "which unzip" after I had typed "*z"?
Why nothing at all after I had typed "*zi"?
Why ONLY "which unzip" after I had typed "*zip"?

It doesn't seem to be working correctly.
 
On Wed, 19 Oct 2011 22:13:38 -0400, rconn <> wrote:

|---Quote---
|> Why no "which unzip" after I had typed "*z"?
|> Why nothing at all after I had typed "*zi"?
|> Why ONLY "which unzip" after I had typed "*zip"?
|>
|> It doesn't seem to be working correctly.
|---End Quote---
|WAD -- you seem to be assuming that there will always be an implied trailing
|* (there won't!).

Why not? There usually is one. Can't you always put it there? I doubt anyone
wants matching to happen at the end of the line.

If I were looking for lines containing foobar (or more realistically, some
filename), I might never find it if I gave "* ... f ... o ... o ... b ... a ...
r". If you put the '*' at the end automatically I might find it very quickly,
with, perhaps, just "*foob" (or less).
 
On Wed, 19 Oct 2011 23:15:57 -0400, rconn <> wrote:

|---Quote---
|> Why not? There usually is one. Can't you always put it there?
|---End Quote---
|Nope.
|
|When you inserted a * at the beginning, you told TCC that you wanted to
|match to the end of the line. With your approach, it would be impossible to
|exactly match trailing characters. If you want to match somewhere in the
|middle, you need leading & trailing wildcards.

I'd have to type the entire end-of-line string I was looking for.

When I put '*' at the beginning I only want to skip characters up to the ones I
type.

I can't imagine wanting to match characters at the end of the line.

Do you have an example?

IMO it's much more useful the other way.
 
IMO it's much more useful the other way.
I totally agree. If I'm narrowing down a list, I want what I'm typing to be found ANYWHERE in the line, not just at the beginning or the end of a line.
 
From: JohnQSmith
| Originally Posted by vefatica
|| IMO it's much more useful the other way.
|
| I totally agree. If I'm narrowing down a list, I want what I'm typing
| to be found ANYWHERE in the line, not just at the beginning or the
| end of a line.

I agree. In dirhist it may occasionally be useful to anchor at EOL, but generally the search is for "midstring" match. What makes this operation more confusing is that the display mode of SET, ALIAS and FUNCTION behave as desired here, even though for those the popup window behavior would probably be a more desirable default. SWAP THEM, PLEASE!
--
Steve
 
---Quote (Originally by JohnQSmith)---
I totally agree.
---End Quote---

Me too. I find the current implementation quite annoying. Rex, please at least add an option to have implicit leading and trailing asterisks.

-- Jay
 
I would support matching anywhere in the entry, i.e. assume leading and trailing *'s
e.g. in a directory popup I would like to find MyDir, there will always be a leading string (C:\, C:\ParentDir\ etc.) and typing myd should be enough. Always having to add leading and trailing *'s seems to defeat the purpose somewhat
 
Nope.

When you inserted a * at the beginning, you told TCC that you wanted to
match to the end of the line. With your approach, it would be impossible to
exactly match trailing characters. If you want to match somewhere in the
middle, you need leading & trailing wildcards.

That's not how I see it. When I put a * at the beginning I'm telling TCC I want to match anywhere in the line. About a half dozen have expressed the desire to have it work that way and none have endorsed the status quo.

Do you have an example of wanting/taking advantage of the current behavior?

Matching at the end of the line just seems silly. You'd have to enter *all* the characters of the string you were looking for (or enter them in backwards order, left-arrowing after each; i.e., build the tail of the line from right to left).

Again, do you have an example of the benefit of the way it is now?

Please consider changing the behavior.
 
And if the user wants to use regular expressions to search in a pop-up he must tolerate a beep when he enters the first colon of "::". It would seem unlikely to search for a line beginning with a colon. Could you get rid of the beep when the first character typed is a colon?
 
> Do you have an example of wanting/taking advantage of the
> current behavior?

The current behavior is the way wildcards work in every other place in TCC.
Your approach would not only require new wildcard matching routines, but
would make it impossible to match on the end of a line without requiring all
wildcard tests to be regular expressions.
 
On Sat, 29 Oct 2011 14:26:30 -0400, rconn <> wrote:

|---Quote---
|> Do you have an example of wanting/taking advantage of the
|> current behavior?
|---End Quote---
|The current behavior is the way wildcards work in every other place in TCC.
|Your approach would not only require new wildcard matching routines, but
|would make it impossible to match on the end of a line without requiring all
|wildcard tests to be regular expressions.

But in no other place are we matching as we type.

You could put the trailing * in place before wildcard matching.

I have yet to see an example of wanting to match at the end of the line (let
alone one which couldn't be done more easily).

I can't imagine wanting to match at the end of the line (example?). If the need
ever arose (doubtful here) I wouldn't mind using REs.
 
> But in no other place are we matching as we type.

This is *exactly* the same as it's always been; the only difference is that
you now have a visible edit control.


> You could put the trailing * in place before wildcard matching.

You had several months to comment on this during the private and public
beta; I'm not going to change it in the release version. If you want to
request a new / changed / additional option, please submit it to the
Feedback forum so that others can comment on it.


> I have yet to see an example of wanting to match at the end of the line
(let

> alone one which couldn't be done more easily).

I have yet to have a need to match in the middle of the line. I always
either want the beginning or the end.
 
On Sat, 29 Oct 2011 15:41:29 -0400, rconn <> wrote:

|I have yet to have a need to match in the middle of the line. I always
|either want the beginning or the end.

Please give an example of where/why you want to match at the end and how you go
about doing it.
 
On 10/29/2011 3:41 PM, rconn wrote:

> I have yet to have a need to match in the middle of the line. I always
> either want the beginning or the end.

That is certainly NOT the case for me. In the directory history popup,
especially, I'm almost always searching for something in the middle of
the path expression.

PLEASE give us an option to default to an automatic leading and trailing
asterisk to what we type (preferably a separate option for each popup).
I'd rather have some false matches than have to keep typing the
asterisks and listening to those annoying beeps until I finish my
typing. An ideal implementation of my proposed configuration option
would be to literally initialize the popup filter to "**" with the
cursor between the two asterisks. Then one could always search at the
beginning or end or exactly by deleting asterisks.

-- Jay
 

Similar threads

Back
Top