bugGNU Octave - Bugs: bug #65753, Documentation window: Function...


bug #65753: Documentation window: Function Index: Search box respects trailing spaces

Submitter:  Some Guy <a876>
Submitted:  Fri 17 May 2024 01:06:09 AM UTC
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  None Assigned to:  None
Originator Name:  a876 Open/Closed:  * Open
Release:  * 9.1.0 Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup

Jump to the original submission

Fri 17 May 2024 02:27:02 PM UTC, comment #9: 

comment #8 is using a recent stable build, 9.1.91 (hg id: 3216c01fd6a7)

Nicholas Jankowski <nrjank>
Group Member
Fri 17 May 2024 02:26:02 PM UTC, comment #8: 

> What causes the extra space to be included in the copied text?

that has been inconsistent, mostly web browser behavior for quite some time.  Right now in chrome on windows, if i double click on any word in the different comments below the word plus the trailing space is included in the highlight.  MS Word does the same. I've most often noticed it when copy/pasting one-time codes sent by email, which sometimes fail if the trailing whitespace is included.

all that said, I think almost all cases of direct searching that involve finding literal text strings should accept and match what you give it.  I don't think that applies to the doc browser search, however.  within the doc browser right now

if I search 'permission' (no quotes/spaces) within the search box, i get fuzzy matches for permission, permissive, permissible, permissions... the same results whether or not there's a space afterward.  if I do `doc permission`, the search box contains "permission" with quotes, and i still get the fuzzy matches.  if i add spaces after `doc permission` i get the same results.  if i do `doc "permission   "` i still get the same results.

i can't recreate the case the op mentions about 'double'.

Nicholas Jankowski <nrjank>
Group Member
Fri 17 May 2024 02:02:57 PM UTC, comment #7: 

I agree, we should not remove characters from search strings unconditionally.  I understand that there might be some confusion if searching for "abc " fails when the spaces are not visible in some way.  But always stripping them could also be confusing.  If the search fails, can we display a message that quotes the spaces in some way that makes them visible or otherwise points out that the search may contain unusual or non-printing characters?

"Often when I Ctrl+C copy from other apps such as a browser, the Clipboard picks up a trailing space."

What causes the extra space to be included in the copied text?  If it is just because your selection was sloppy and you included extra characters unintentionally, then how could Octave possibly know that?  It seems bad to me to always assume that we know better than the user what it is they are trying to search for.

John W. Eaton <jwe>
Group administrator
Fri 17 May 2024 09:35:52 AM UTC, comment #6: 

I also agree with comment #4. Also applies to preceding spaces.

Philip Nienhuis <philipnienhuis>
Group Member
Fri 17 May 2024 07:11:36 AM UTC, comment #5: 

I agree with @ttl's comment. For the same reasons I also do like to be able to distinguish "xxx " and "xxx". So everywhere, except when searching in the function index (where we know in advance that a trailing white space will always lead to no match) I think we should keep the distinction.

Pantxo Diribarne <pantxo>
Group Member
Fri 17 May 2024 04:53:31 AM UTC, comment #4: 

I can reproduce the issue in version 9.1.91. This should not be too complicated to fix. Bit in my opinion, only searching the function index should ignore trailing spaces. When searching in the editor, e.g., I sometimes intentionally search for "xyz " for not having matches for "xyzabc".

Removing trailing space when saving a file in the editor is a preference which can be activated in the preferences dialog, tab "Editor", and is active by default.

Torsten Lilge <ttl>
Group Member
Fri 17 May 2024 02:27:32 AM UTC, comment #3: 

The Octave IDE/editor has trimmed trailing whitespaces by default for several versions. The interpreter can't assume that an m-file was written using Octave's IDE, however. The report is about removing the interpreter determining that a \ was supposed to indicate the end of a line even when it's not at the end of the line.

Nicholas Jankowski <nrjank>
Group Member
Fri 17 May 2024 01:44:07 AM UTC, comment #2: 

    Maybe this is a trend with trailing whitespace...
    "Support for trailing whitespace after a '\' line continuation has been removed. Delete unnecessary trailing whitespace."
    -- from: https://octave.org/NEWS-9.html "GNU Octave Version 9": "Deprecated functions, properties, and operators": "Interpreter"

    (REALLY?  And so GLIB!  How about having the editor trim trailing spaces from all lines?  I have a programming product from 2011 whose feeble IDE/editor only has one level of Undo, but it trims trailing blanks.)

Some Guy <a876>
Fri 17 May 2024 01:18:31 AM UTC, comment #1: 

I think it has been fixed in the upcoming 9.2
At least I cannot reproduce that in 9.1.91 (pre-release).

You can try a nightly pre-release at
(it may take another hour or two until it finishes).


Dmitri A. Sergatskov <dasergatskov>
Fri 17 May 2024 01:06:09 AM UTC, original submission:  

    If I type or paste "double " into the Search box (without the quotes but with the trailing blank/space/0x20), it shows NO results.
    Often when I Ctrl+C copy from other apps such as a browser, the Clipboard picks up a trailing space.  Getting no results when I paste text into Search can be confusing and annoying, wondering whether I made a false request, and then realizing I have to hit Backspace to see the result(s).
    Entering "double" works. Entering "DoUbLe" works.  (Good, case-insensitive.)
    But it seems to treat a trailing space as significant. Changing "double" to "double" takes away the search results. That makes partial sense because no function in the list contains an embedded space, but it is uncomfortable.
    Changing "double" to "doublet" [also] takes away the search results.  That is more valid than letting a trailing space take away the results, but maybe extra letters also should not take away the results.
    The other search box in the Documentation window, "Search", has not problem with trailing spaces.

Some Guy <a876>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #56059:  i256.png added by a876 (10KiB - image/png)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by nrjank (Posted a comment)
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by a876 (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.


    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2024-05-17 a876 Attached File- Added i256.png, #56059

    Back to the top

    Powered by Savane 3.13-3736.
    Corresponding source code