This is a multi-part message in MIME format.
--nextPart30413437.cxEhPILabk
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
On Freitag, 14. Januar 2022 22:55:38 CET Christoph Cullmann (cullmann.io) wrote:
> On 2022-01-14 22:52, Alexander Neundorf wrote:
> > Hi,
> >
> > (I know we had similar discussion a few years ago already).
> > I'd like to split the "Search in current file" into a separate
> > plugin/tab.
> >
> > For "in current file", less options would be required.
> > All the "advanced" options are not necessary, so also the button to
> > toggle
> > between options and results is not necessary, and always the results
> > would be
> > visible.
> > The "Search" buttin, the "Use current documents folder" button, the
> > mode
> > combobox, the "Expand results" button, the "add new search tab" button
> > would
> > all not be necessary.
> > I would suggest that this would always search automatically when the
> > search
> > text is modified, without maximum file size.
> > I would also suggest that it searches automatically when switching to a
> > different file, i.e. always the search results for the current search
> > string
> > in the current file would be visible.
> >
> > Together with this, I would suggest to remove the "In current file"
> > search
> > mode from the normal "Search and Replace", and also disable the
> > automatic
> > search in the current file when typing. To me, this would actually be
> > better
> > than it is now, since the automatic searching quite often dismissed my
> > search
> > results, while I actually wanted to keep them.
> >
> > What do you think ?
>
> I am not sure about this.
> This would make the "standard" in document search even more duplicated
> with the plugin.
> But perhaps others see this differently.
>
> My normal working pattern is:
>
> 1) for in document searches just using the search/replace of KTextEditor
> view
> 2) use the Kate level search plugin only for project wide searches
>
> Perhaps others use it more like you, for both use cases.
I also use both.
What I don't like about Ctrl+F, is that it immediately jumps to the first match as soon as I
start typing, i.e. I loose "focus". Also it doesn't show me how many matches there are in
the document.
Actually I use Ctrl+F more as a "go to"-function, not to "learn" something about a file.
If I want to see how often/where/how some text appears in the document, the in-current-
file search of Search&Replace is more convenient. My cursor stays where it is in the file
and it gives my an overview over the matches in this file.
Alex
--nextPart30413437.cxEhPILabk
Content-Transfer-Encoding: 7Bit
Content-Type: text/html; charset="us-ascii"
On Freitag, 14. Januar 2022 22:55:38 CET Christoph Cullmann (cullmann.io) wrote:
> On 2022-01-14 22:52, Alexander Neundorf wrote:
> > Hi,
> >
> > (I know we had similar discussion a few years ago already).
> > I'd like to split the "Search in current file" into a separate
> > plugin/tab.
> >
> > For "in current file", less options would be required.
> > All the "advanced" options are not necessary, so also the button to
> > toggle
> > between options and results is not necessary, and always the results
> > would be
> > visible.
> > The "Search" buttin, the "Use current documents folder" button, the
> > mode
> > combobox, the "Expand results" button, the "add new search tab" button
> > would
> > all not be necessary.
> > I would suggest that this would always search automatically when the
> > search
> > text is modified, without maximum file size.
> > I would also suggest that it searches automatically when switching to a
> > different file, i.e. always the search results for the current search
> > string
> > in the current file would be visible.
> >
> > Together with this, I would suggest to remove the "In current file"
> > search
> > mode from the normal "Search and Replace", and also disable the
> > automatic
> > search in the current file when typing. To me, this would actually be
> > better
> > than it is now, since the automatic searching quite often dismissed my
> > search
> > results, while I actually wanted to keep them.
> >
> > What do you think ?
>
> I am not sure about this.
> This would make the "standard" in document search even more duplicated
> with the plugin.
> But perhaps others see this differently.
>
> My normal working pattern is:
>
> 1) for in document searches just using the search/replace of KTextEditor
> view
> 2) use the Kate level search plugin only for project wide searches
>
> Perhaps others use it more like you, for both use cases.
I also use both.
What I don't like about Ctrl+F, is that it immediately jumps to the first match as soon as I start typing, i.e. I loose "focus". Also it doesn't show me how many matches there are in the document.
Actually I use Ctrl+F more as a "go to"-function, not to "learn" something about a file.
If I want to see how often/where/how some text appears in the document, the in-current-file search of Search&Replace is more convenient. My cursor stays where it is in the file and it gives my an overview over the matches in this file.
Alex
--nextPart30413437.cxEhPILabk--