octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #58372] Editor: Highlight all occurrences of w


From: Dan Sebald
Subject: [Octave-bug-tracker] [bug #58372] Editor: Highlight all occurrences of word selected by double click centers text in editor window when off screen
Date: Fri, 15 May 2020 00:27:43 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/80.0.3987.87 Chrome/80.0.3987.87 Safari/537.36

URL:
  <https://savannah.gnu.org/bugs/?58372>

                 Summary: Editor: Highlight all occurrences of word selected
by double click centers text in editor window when off screen
                 Project: GNU Octave
            Submitted by: sebald
            Submitted on: Fri 15 May 2020 04:27:41 AM UTC
                Category: GUI
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Other
                  Status: None
             Assigned to: None
         Originator Name: sebald
        Originator Email: 
             Open/Closed: Open
                 Release: 5.1.0
         Discussion Lock: Any
        Operating System: Any

    _______________________________________________________

Details:

I came across the following subtle behavior of the "Highlight all occurrences
of word selected by double click" which is quite annoying pretty much
obviating an otherwise useful feature.

When there are multiple occurrences of a comment word, variable name, function
name in a file *and* one of the occurrences extends past the end of the
visible area, double clicking the word in the visible part of the area will
center the text on screen.  That is not only annoying, but it also has the
side effect of selecting *more* text because of the repositioning of the text
area.

Here is some sample text to copy into the editor:

for i=1:50
  input1 = sqrt(pi);
  x =
do_not_make_your_function_names_too_long_because_otherwise_they_go_off_the_end_of_the_editor_screen(input1,
input2);
  input2 = x / input1;
endfor

Make sure that the editor is narrow enough so that the first "input1" and
"input2" go outside the visible area.  Now double-click "input2".

Attached is what I'm seeing.  Notice how what I clicked on "input2" has
shifted off the screen and with that shift the " = x " is additionally
highlighted.  Basically, with "Highlight all occurrences" turned on, one can't
double click a word and paste with what is copied in the clipboard.

This seems like one of those "seemed like a good idea at the time" sorts of
things, but with an unexpected consequence.

The code where the action is happening is in file-editor-tab.cc:

        if (m_highlight_all_occurrences)
          {
            // Clear any previous selection.
            m_edit_area->set_word_selection ();

            // highlighting of all occurrences of the clicked word is enabled

            // get the resulting cursor position
            // (required if click was beyond a line ending)
            int line, col;
            m_edit_area->getCursorPosition (&line, &col);

            // get the word at the cursor (if any)
            QString word = m_edit_area->wordAtLineIndex (line, col);
            word = word.trimmed ();

            if (! word.isEmpty ())
              {
                // word is not empty, so find all occurrences of the word

                // remember first visible line for restoring the view
afterwards
                int first_line = m_edit_area->firstVisibleLine ();

                // search for first occurrence of the detected word
                bool find_result_available
                  = m_edit_area->findFirst (word,
                                            false,   // no regexp
                                            true,    // case sensitive
                                            true,    // whole words only
                                            false,   // do not wrap
                                            true,    // forward
                                            0,0,     // from the beginning
                                            false
#if defined (HAVE_QSCI_VERSION_2_6_0)
                                            , true
#endif
                                           );

                // loop over all occurrences and set the related indicator
                int oline, ocol;
                int wlen = word.length ();

                while (find_result_available)
                  {
                    // get cursor position after having found an occurrence
                    m_edit_area->getCursorPosition (&oline, &ocol);
                    // mark the selection
                    m_edit_area->show_selection_markers (oline, ocol-wlen,
oline, ocol);

                    // find next occurrence
                    find_result_available = m_edit_area->findNext ();
                  }

                // restore the visible area of the file, the cursor position,
                // and the selection
                m_edit_area->setFirstVisibleLine (first_line);
                m_edit_area->setCursorPosition (line, col);
                m_edit_area->setSelection (line, col - wlen, line, col);
                m_edit_area->set_word_selection (word);
              }
          }


I'm not sure, but looking at those last few lines, it might be the action of
looping through all the finds of the word highlighting them might be what's
inherently moving the text area.  Then the visible area is restored the way
things were before the highlight all was run.  It looks as though there needs
to be another area modification which is to return to the first visible column
before the search, something analogous to the 

m_edit_area->setFirstVisibleLine (first_line);

Here is the Scintilla documentation:

SCI_SETFIRSTVISIBLELINE(line displayLine)
SCI_GETFIRSTVISIBLELINE → line
These messages retrieve and set the line number of the first visible line in
the Scintilla view. The first line in the document is numbered 0. The value is
a visible line rather than a document line.

SCI_SETXOFFSET(int xOffset)
SCI_GETXOFFSET → int
The xOffset is the horizontal scroll position in pixels of the start of the
text view. A value of 0 is the normal position with the first text column
visible at the left of the view.

It is probably getXOffset() and setXOffset() that we need to record and
restore.



    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Fri 15 May 2020 04:27:41 AM UTC  Name:
Screenshot@from@2020-05-15@00-01-19_editor_after_double_click_input2_CROPPED.png
 Size: 60KiB   By: sebald

<http://savannah.gnu.org/bugs/download.php?file_id=49068>

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?58372>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]