1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Beeps in popup windows

Discussion in 'Support' started by Howard Goldstein, Oct 19, 2011.

  1. Howard Goldstein

    Joined:
    Jun 1, 2008
    Messages:
    111
    Likes Received:
    1
    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
     
  2. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,785
    Likes Received:
    29
    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.
     
  3. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,730
    Likes Received:
    80
    WAD -- you seem to be assuming that there will always be an implied trailing
    * (there won't!).
     
  4. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,785
    Likes Received:
    29
    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).
     
  5. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,730
    Likes Received:
    80
    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.
     
  6. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,785
    Likes Received:
    29
    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.
     
  7. JohnQSmith

    Joined:
    Jan 19, 2011
    Messages:
    560
    Likes Received:
    8
    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.
     
  8. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,523
    Likes Received:
    4
    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
     
  9. David Marcus

    Joined:
    Jun 4, 2008
    Messages:
    646
    Likes Received:
    1
    Me too.
     
  10. Jay Sage

    Joined:
    Jun 2, 2008
    Messages:
    284
    Likes Received:
    1
    ---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
     
  11. yakir

    Joined:
    May 29, 2008
    Messages:
    61
    Likes Received:
    0
    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
     
  12. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,785
    Likes Received:
    29
    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.
     
  13. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,785
    Likes Received:
    29
    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?
     
  14. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,730
    Likes Received:
    80
    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.
     
  15. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,785
    Likes Received:
    29
    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.
     
  16. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,730
    Likes Received:
    80
    This is *exactly* the same as it's always been; the only difference is that
    you now have a visible edit control.


    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.


    (let

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

    Joined:
    May 20, 2008
    Messages:
    7,785
    Likes Received:
    29
    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.
     
  18. Jay Sage

    Joined:
    Jun 2, 2008
    Messages:
    284
    Likes Received:
    1
    On 10/29/2011 3:41 PM, rconn wrote:

    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
     

Share This Page