Closed pintassilgo closed 2 months ago
This is hard work. currently no time for this. maybe later. (hard to add the caret in ATBinHex.)
closing as 'wont fix' because it is hard work and I don't plan it.
OK. It's unfortunate because it would be a gigantic improvement when searching in very big files when they are sorted or when you have a hint of where is the content you are looking for.
Currently, search starts from the beginning of the file or from the previous match. In a giant file, this can waste a lot of processing and time if you know, for instance, that search should skip the first half of the document.
The main purpose of this issue is to be able to set starting point or custom range for search. If it were possible to use "search in selection" when reading big file, it would be enough.
it will be easier for me if 'caret' here can be changed only by mouse, and keyboard arrows/pageup/pagedown will work like before (scroll the file). i want to paint 'caret' w/o blinking too. maybe like a red triangle marker in the editor to make it more visible. is it ok?
Sounds OK to me.
Still following what I said, is enabling "Search in selection" undoable when using "Viewer" for big files?
imo, 'in selection' is bad UI for viewer. viewer is for big files. so to make search in 2nd half, user will need to make huge selection by mouse? very bad! i want it to search from 'caret' until the EOF, ok?
imo, 'in selection' is bad UI for viewer
I disagree, I don't see why this is an issue, to remove a useful feature for no reason. It's not that search in selection is enabled by default, those who use it knows what they are doing.
so to make search in 2nd half, user will need to make huge selection by mouse?
No! No one makes big selection by dragging the mouse. The proper way is first to place caret at where will be the start of the selection, without holding click or anything, or to make a small selection. Then you scroll to anywhere (using scrollbar, "go to" command or any other way you want), only then you hold Shift and make a simple left-click in where will be the end of the selection. Don't you know about that? It's universal, work with any app.
i want it to search from 'caret' until the EOF, ok?
It's already an improvement compared to current, but it would be good to be able to set a range, which is the "search in selection". Let's say you aren't sure if there is a match, but you know that if it exists it's in the first third of the document. There should be a way to skip wasting time searching in where you know there's no match, or maybe there can be a match there but you simply aren't interested.
Demo on how to easily and quickly make big selection without needing to drag the mouse across the text. You just need to use Shift + click when clicking at the end of the selection.
https://github.com/Alexey-T/CudaText/assets/5483864/c1828f21-1a64-4112-9779-6c160c914b5c
yes I know about Shift_click. I will try to add 'in selection' for viewer. it is maybe not so hard as I thought.
first beta, linux-qt5: cudatext.xz.zip
'in selection' opt is enabled for viewer. let's test.
It's not working for me. First, the ...
button to display menu with "Search in selection" is disabled. Luckily, I have the [...]
button visible in find toolbar which does the same. But still, enabling it has no effect. Search is not being restricted to selected text, Cuda is removing the selection and navigating to matches off the range.
enabling of '...' menu items will be fixed in next beta. why it's not working? try this
[..]
optI tried again a few times here. It worked once, finding the string within the selection in short time as expected because the selection is small enough for the search to run fast. But other times doing the same tests the progress bar was slow just as if it were looking the entire file. There's something inconsistent.
Also, what you described only work if I disable Im
. [..]
and Im
are incompatible with each other because you confirmed old selection is removed after first find. By the way, this breaks the possible need to find not-the-first match within the selection, like the third one, the fifth or whatever. For what you described, [..]
is find-first only, then you need to manually create the selection again to re-run.
I must select the srch-result in different way when 'in selection' is checked. e.g. with a red underline. like Cud does for editor when 'in selection' is used. todo.
new beta linux-x64-qt5 cudatext.xz.zip
test it pls.
Thanks.
I did a search in selection, then clicked on editor, then pressed Ctrl+F. Result: [..]
is suddenly disabled (the button is deselected). It should remain enabled until user manually disables it.
If you press enter after last match, marks are unexpectedly removed. It would be great to have wrapped search (to restart from first occurrence), but if you think it's too hard to implement, at least it should keep the marks.
It's missing scroll to occurrence. Try it yourself, select something, scroll until it's out of view, then do search in selection. It will find but will not scroll to it.
I keep saying this search is not reliable. In the first tests with this new build, I selected a few thousands lines, searched for something I know there's only one match within the selection. Cuda should be able to process this search instantly and show the match. Instead, it took 1 minute processing it and at the end returned no match. So I did some other tests with small selections (the points 1, 2 and 3 I wrote above), then tried again with this big selection and now it worked as expected, processed instantly and found the match, only missed to scroll to the match.
1: fixed. 3: fixed.
I keep saying this search is not reliable
let's post it to a new issue, with example file and steps, which selection do you make (for which app cannot find the match).
I'll do it when I have STR. For now it looks random to me.
2: fixed.
but if you think it's too hard to implement, at least it should keep the marks.
now kept the marker.
last beta (fixed 3 points of 4). cudatext.xz.zip
Thanks!
[..]
and search for something.Result: [..]
is disabled. Saying it again, [..]
should only be disabled by user, not automatically.
bug:
I found smthing about unreliable result. when sel is changed, app did not reset some var related to prev-search-pos. now I fixed it, it seems.
last reported bug with reset of [..]
opt is fixed.
let's test more:
Thanks.
file: open file, in text viewer
, open the file you saved.[..]
, type teste
and press Enter multiple times.You'll notice find is matching not only the teste
word in line 5, which is the only selected line, but also the word in first line which is off the selection. Cuda shouldn't match anything off selection, as [..]
is enabled. So there should be only one match, not two.
did you enable Hi option? if so, HiAll feature is ignoring the sel-range.
Yes, but I'm not talking about HiAll highlighting, I can see the search mark in the word off the selection.
Ok, now I reproduced this.
Is this better? I am doing big rework in viewer's finder. bugs present.
Thanks.
Find marks seems fine, but HiAll looks very bad.
reworked this now. seems ok now?
beta cudatext.xz.zip
It looks good, thanks. Should I close this one?
What is the color item of the mark? I need to change it, it's not easy to see it in my theme.
yes, we can close this one in 1-2 days. open new issues for more bugs.
color of HiAll marks: 'line state added'.
color of HiAll marks: 'line state added'.
Not HiAll, I'm asking about the underline mark in current match.
underline mark color -- 'editor, markers'.
Edit: original title: "Enable caret for read-only viewer"
I suggest to enable caret on read-only mode, for instance when viewing a giant file.
Making a selection with mouse works, so it should be possible to have caret to make selection using keyboard.
Another advantage of the caret would be to be able to set a start position for find, to avoid searching the entire file. Example: I need to find a word that I know it's at the bottom half of the giant file. I should be able to place caret at the center of the document, then "find next" would start from that position, making find faster by skipping all the upper half.