GNU bug report logs - #36196
HyRolo String Searches Produce Unexpected Behavior

Previous Next

Package: hyperbole;

Reported by: Eric Bemiller <d40547914 <at> dvuadmin.net>

Date: Thu, 13 Jun 2019 16:41:02 UTC

Severity: normal

Done: rswgnu <at> gmail.com

Bug is archived. No further changes may be made.

Full log


Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eric Bemiller <d40547914 <at> dvuadmin.net>
To: "bug-hyperbole <at> gnu.org" <bug-hyperbole <at> gnu.org>
Subject: HyRolo String Searches Produce Unexpected Behavior
Date: Thu, 13 Jun 2019 16:40:15 +0000
I use:  Editor:      GNU Emacs 26.2 (build 1, x86_64-w64-mingw32)
        Hyperbole:   7.0.3
        Sys Type:    x86_64-w64-mingw32
        OS Type:     windows-nt
        Window Sys:  w32
        News Reader: Gnus v5.13

I have another bug, I think -- but it may just be related to the weirdness
around getting Hyperbole 7.0.3 working, which was discussed previously. Or it
could be me misunderstanding the expected result

Steps to reproduce:

1. Set `hyrolo-file-list` to only include the `DEMO-ROLO.otl` file
   included with Hyperbole.

2. Attempt to search by logcal string, as described in the manual:

   > (and Industries (and Dunn))

3. Unexpected Behavior #1: The results buffer shows the entire Demo Rolo, not
   just the matching entry. The matching entry dooesn't have the highlight face
   applied, either.

4. Unexpected Behavior #2: Pressing <tab> to jump to next match returns error: 

   > (hyrolo-next-match): No following matches for "[previous Word search string]"

I don't know whether the two are related -- and, like I said, I don't know what
the intended behavior is.

In the latter case, it seems that `hyrolo-next-match` isn't being passed what I
enter into the String search, and continues to use whatever the last successful
Word search was.

So, if I do a Word search for `Smith` and then a string search for `(and
Industries (and Dunn))`, `hyrolo-next-match` is still looking for `Smith`.

In the former case, the documentation suggests that the results buffer should
show only show entries that match, and not ones that don't -- and it seems like
it should highlight the match the way the Word or Regex searches do. Neither
seems to be the case, currently.

As always, thanks for any help!

etb


This bug report was last modified 2 years and 194 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.