[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/
- [Octave-bug-tracker] [bug #58372] Editor: Highlight all occurrences of word selected by double click centers text in editor window when off screen,
Dan Sebald <=