bugGNU Octave - Bugs: bug #65518, Problems with right-click menu on...

 
 

bug #65518: Problems with right-click menu on Command Window

Submitter:  Luiz Antonio Maccari Junior <luiz>
Submitted:  Tue 26 Mar 2024 03:58:48 PM UTC
   
 
Category:  GUI Severity:  1 - Wish
Priority:  5 - Normal Item Group:  Feature Request
Status:  Fixed Assigned to:  None
Originator Name:  Luiz Antonio Maccari Jr. Open/Closed:  * Closed
Release:  * 9.1.0 Operating System:  * Any
Fixed Release:  9.2.0 (current stable) Planned Release:  9.2.0 (current stable)
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 29 Mar 2024 06:29:25 PM UTC, comment #23: 

Few times in my life I tried to get "help \" and after it failed I learned that it also called "mldivide"...
Now I am learning that "help <=" works while "help =" does not.
All in all I vote for simplicity.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Fri 29 Mar 2024 06:09:18 PM UTC, comment #22: 

I don't think most people even know to get help on operators this way, so I'm not that bothered if they have to type the actual command.  I think it is okay to optimize for the 99.99% of actions which are going to be 'help' or 'edit' on a single word.  But, that's just one opinion.

Rik <rik5>
Group administrator
Fri 29 Mar 2024 04:38:58 PM UTC, comment #21: 

It is possible to get help for operators at the command line using commands like


help <=


but with the latest changes, selecting '<=' in the GUI command window and right clicking on the selected text doesn't give the option to get help for the selection.  Maybe we shouldn't be trying to guess what it is that the user wants here and instead just pass the selected text to the help function and let it work or not?

John W. Eaton <jwe>
Group administrator
Fri 29 Mar 2024 03:19:56 PM UTC, comment #20: 

The functionality is much improved now.  Marking bug as Fixed and closing report.

Rik <rik5>
Group administrator
Fri 29 Mar 2024 01:59:34 PM UTC, comment #19: 

I pushed another change on top of Rik's:
https://hg.savannah.gnu.org/hgweb/octave/rev/65d2a1f70155

It does the following:

  • Discard any non-word characters (not just whitespace) at the start of the selected string. If a user mis-clicks and selects, e.g., "> test", it's still reasonable to assume that they'd like to get options for "test".
  • Double-quote the matched strings in the context menu. Imho, that makes it clearer what those options do.
  • Add a check whether there is actually a match before dereferencing it.


Markus Mützel <mmuetzel>
Group administrator
Thu 28 Mar 2024 07:09:04 PM UTC, comment #18: 

That sounds reasonable.

Should there be a check for `match.hasMatch ()` before accessing `match.captured(1)?` for the second pattern matching? It's probably unlikely that there won't be a match after the first pattern succeeded. But better safe than sorry...

Markus Mützel <mmuetzel>
Group administrator
Thu 28 Mar 2024 06:40:18 PM UTC, comment #17: 

I was also working on improving the menu item for documentation which can accept multi-word strings.  See the attached changeset.  I wouldn't bother to filter out strings that don't exactly match a function name.  The user selected the text, and they should get an error message that there is no help on the particular word they selected.  This will certainly be the case if the word starts with a number.

Changing the bug tracker fields to indicate that this is now a Feature Request for the remaining item.

(file #55894)

Rik <rik5>
Group administrator
Thu 28 Mar 2024 04:26:58 PM UTC, comment #16: 

`help "axes properties"` doesn't work for me. But `doc "axes properties"` does.

The attached patch allows multiple words for right-click menu option that opens the documentation.

Additionally, it doesn't accept strings that don't start with a letter or underscore as the input for `help` or `edit` (because functions names must start with either a letter or underscore in Octave).


(file #55893)

Markus Mützel <mmuetzel>
Group administrator
Thu 28 Mar 2024 03:29:04 PM UTC, comment #15: 

I went ahead and pushed the change that I proposed in comment #3 to the stable branch because that restore the behavior that we had in previous versions:
https://hg.savannah.gnu.org/hgweb/octave/rev/7cef76b2d1da

The other changes (like matching only strings that are valid function identifiers or matching more than one word for "Help") should probably go on the default branch.

Markus Mützel <mmuetzel>
Group administrator
Thu 28 Mar 2024 05:51:37 AM UTC, comment #14: 

I agree, for searching the documentation, a selection of multiple words would make sense (not for the context menu entries "run" and "edit").

Torsten Lilge <ttl>
Group Member
Thu 28 Mar 2024 12:00:34 AM UTC, comment #13: 

Yes, that's correct.  We could eliminate the word boundary checking and get the same result.

What do we really want to have happen here?  It doesn't seem necessary to restrict the user to selecting one word.  For example, if the user highlights "axes properties", then they should be able to get documentation on that search term, rather than just "axes" which will return something different.  I suppose trimming leading and trailing whitespace would be useful because help() expects just a keyword.

This regexp trims whitespace and allows multiple word selections


        QRegularExpression expr {"^\\s*(\\w.*)\\s*$"};


Rik <rik5>
Group administrator
Wed 27 Mar 2024 07:23:19 AM UTC, comment #12: 

Word boundary (i.e., "\\b") makes a bit more sense than a backspace character (i.e., "\b").
However, I don't understand why we'd need to match a word boundary. Wouldn't the following (simpler) regular expression match the same?

        QRegularExpression expr {"(\\w+)"};


If we'd like to make sure that the matched function name starts with a letter or underscore (not a digit), we could maybe use the following expression:

        QRegularExpression expr {"\\b([A-Za-z_]\\w*)\\b"};


In that case, matching word boundaries would make sense (to make sure it wouldn't match "test" in "4test").


Markus Mützel <mmuetzel>
Group administrator
Tue 26 Mar 2024 10:10:06 PM UTC, comment #11: 

Changeset attached which works for me.  Marking as Patch Submitted.

(file #55889)

Rik <rik5>
Group administrator
Tue 26 Mar 2024 10:01:36 PM UTC, comment #10: 

This regular expression works for me


        QRegularExpression expr {"\\b(\\w+)\\b"};


If you select a region which has "<whitespace><word><whitespace>" then this regexp will properly pick out just the word.

If you select multiple words with the mouse then this regexp picks out just the first one.  For example, with the highlighted string "abc def" then just "abc" will be returned.

This seems okay to me, but if someone wants a different behavior we could code that instead.

Rik <rik5>
Group administrator
Tue 26 Mar 2024 09:50:50 PM UTC, comment #9: 

Just looking at the regular expression, there seems to be an issue.  In Perl regexp '\b' is not backspace but word boundary.  However, it is a zero-width assertion, and shouldn't be followed by an asterisk.  I'm taking a look right now.

Rik <rik5>
Group administrator
Tue 26 Mar 2024 08:17:45 PM UTC, comment #8: 

Just exchanging \b by \\b dies not help. But ".*\\b(\\w+)\\b.*" works for me.

Torsten Lilge <ttl>
Group Member
Tue 26 Mar 2024 07:38:57 PM UTC, comment #7: 

I can't remember exactly the intention behind the regular expression. My guess is that I missed the double slashes which made a backspaces from word boundaries. I am wondering if there was a version that still interpreted \b as word boundary. Otherwise there is no explanation why this was working.

Torsten Lilge <ttl>
Group Member
Tue 26 Mar 2024 05:53:50 PM UTC, comment #6: 

I'm guessing an incorrect attempt at limiting the match to a word?

John W. Eaton <jwe>
Group administrator
Tue 26 Mar 2024 05:51:35 PM UTC, comment #5: 


> Maybe the way matching works changed when we updated to using QRegularExpression instead of QRegExp


I was thinking the same. Maybe, the previous engine was "less greedy".
I tried with different engines on regex101.com. But I couldn't figure out what the backspaces were matching before. Basically all engines matched only the last character of a word with that regular expression.

Markus Mützel <mmuetzel>
Group administrator
Tue 26 Mar 2024 05:28:06 PM UTC, comment #4: 

The regular expression appears to have been the same since it was added in https://hg.savannah.gnu.org/hgweb/octave/rev/0a2e5c808709

Maybe the way matching works changed when we updated to using QRegularExpression instead of QRegExp in https://hg.savannah.gnu.org/hgweb/octave/rev/20bf7bf8c95d

John W. Eaton <jwe>
Group administrator
Tue 26 Mar 2024 04:45:11 PM UTC, comment #3: 

Replacing the regular expression with a simple `QRegularExpression expr {"(\\w+)"};` fixes it for me.
But like I wrote earlier, I don't understand the reason behind the backspace characters in the regular expression. So, this might break something else.

Markus Mützel <mmuetzel>
Group administrator
Tue 26 Mar 2024 04:28:46 PM UTC, comment #2: 

I can also confirm on Windows.

That is probably due to the following regular expression in QTerminal.cc (QTerminal::handleCustomContextMenuRequested):

       QRegularExpression expr {".*\b*(\\w+)\b*.*"};
        QRegularExpressionMatch match = expr.match (selected_text);


Tbh, I don't know what the original intension was for that expression (especially the backspace characters).

CC'ing Torsten hoping that he might remember why that expression was added here:
https://hg.savannah.gnu.org/hgweb/octave/rev/0a2e5c808709

Markus Mützel <mmuetzel>
Group administrator
Tue 26 Mar 2024 04:11:52 PM UTC, comment #1: 

Confirm with both (61c69bdd1ed6 (stable)) and (a42aa7e5dd29 @)

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Tue 26 Mar 2024 03:58:48 PM UTC, original submission:  

Hi,

When I select a word on command window and press the right click menu the options: Edit, help and documentation only recognize the last character of the word.

For example, selecting the word "care" the menu shows "Edit e", "Help on e" and "Documentation on e".

The same not occurs in the editor.

Best Regards.


Luiz Antonio Maccari Junior <luiz>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #55894:  bug65518.2.cset added by rik5 (2KiB - application/octet-stream)
file #55889:  bug65518.cset added by rik5 (947B - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by mmuetzel
  • -email is unavailable- added by jwe (Updated the item)
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by luiz (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.

     

    Follow 25 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2024-03-29 rik5 StatusPatch Submitted Fixed
        Open/ClosedOpen Closed
    2024-03-28 rik5 Attached File- Added bug65518.2.cset, #55894
        Severity4 - Important 1 - Wish
        Priority7 - High 5 - Normal
        Item GroupRegression Feature Request
        Fixed ReleaseNone 9.2.0 (current stable)
    2024-03-28 mmuetzel Attached File- Added bug65518-command-window-right-click-menu.patch, #55893
    2024-03-26 rik5 Attached File- Added bug65518.cset, #55889
        StatusConfirmed Patch Submitted
    2024-03-26 mmuetzel CategoryInterpreter GUI
        StatusNone Confirmed
        Operating SystemGNU/Linux Any
    2024-03-26 jwe CategoryGUI Interpreter
        StatusConfirmed None
        Operating SystemAny GNU/Linux
    2024-03-26 mmuetzel CategoryInterpreter GUI
        StatusNone Confirmed
        Operating SystemGNU/Linux Any
        SummaryProblems with righ click menu on Command Window Problems with right-click menu on Command Window
        Carbon-Copy- Added ttl
    2024-03-26 jwe Planned ReleaseNone 9.2.0 (current stable)
    2024-03-26 jwe Severity3 - Normal 4 - Important
        Priority5 - Normal 7 - High
        Item GroupOther Regression

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code