[ZeroBrane Studio] Re: Search redesign for ZBS
- From: Paul K <paul@xxxxxxxxxxxxx>
- To: "zerobrane@xxxxxxxxxxxxx" <zerobrane@xxxxxxxxxxxxx>
- Date: Fri, 27 Mar 2015 15:35:18 -0700
Hi Derek,
> I really like it so far, I think the context display is a wonderful idea.
> I also like that it is dialog-less, I think the integration is spot on.
Thank you for the detailed feedback; great suggestions and comments!
Let me go over them one by one.
> Is there any way to preserve syntax coloring in the Search Results editor? I
> don't know if this is possible if you are searching multiple different types
> of files though. Just a thought. But if most people use it as a Lua editor,
> it might make sense to leave it with the Lua syntax as default.
Yes, there is a way to preserve the syntax coloring. Obviously the
file names and line numbers are going interfere with the syntax, which
may affect the coloring as well. You are right, files with different
extensions can't be colored properly, but if the results are all of
the same type, it may make sense to apply the same syntax highlighting
to them.
> Can there be an option to have the Search result Editor show up below near
> the 'Output' and 'Local Console' tabs? I feel like you can lose your context
> when you are searching and a new Editor pops up and replaces
> the editor you were working on.
Not sure about a tab next to Output/Console, but I can use split
screen to show search results; for example, I can split the screen
horizontally by default, which will keep the search results next to
the search panel and the original tab will be right above it.
> Live editing capabilities? If I edit a line in the Search Results editor
> could it be actively reflected in the actual source file?
Yes, I thought about it, but probably only after "saving" the results.
Right now this functionality is only enabled for "replace" preview;
the main reason being is the confusion as the users may not expect
that changing something in the search results will change their files.
Maybe I need to have a toggle that is turned off by default for that.
I envisioned this functionality to be used for different things, like
TODO/FIX comments/lists and such, where you can see them all together
in one place and edit/remove them and then save the changes. This also
requires the search working correctly with the content of files
already opened in the IDE, but this is coming as well.
> History capabilities. Like Notepad++ Find-in-files, it keeps track of all
> the searches you have done (http://i.imgur.com/DiFDwO9.png) and you
> are able to clear it with a context menu command. (oops, I just read that
> this is a work on progress, but I'll leave this here anyways)
I meant a different history (for search/replace/scope text); having
history of results looks interesting, but I think this goes against
live editing or replace updates and I'm more interested in supporting
those use cases.
> Is the number of lines displayed above and below the matched line a
> user-definable value?
yes, I thought about adding a configuration parameter for it
(search.contextlines = 2 probably).
> If you have a selected/highlighted on word in an editor, and hit
> 'Ctrl-Shift-F', it should copy the highlighted word and put in the find
> textbox for you. This makes it much smoother to find stuff in my opinion.
> This can probably can be used in the find-replace context as well.
Agree; this will be fixed/added.
> Will the location of the find dialog be user-definable? Or will it always be
> at the bottom of the editor pane?
I don't plan to make it configurable. I initially tried to make it
dockable/floatable, but there were several issues with setting focus
to the controls in a floating panel on OSX/Linux, so I dismissed that
option.
It's a panel the same as others and technically it doesn't matter
where it's docked, but I can't make it movable without making it
floating and I can't make it work while it's floating. Where else
would you want to see it?
> Can the 'Show context' button refresh the results in real-time if it is
> toggled? This could be handy if you have a lot of results and quickly want
> to remove the context without researching.
It's an interesting suggestion; I'm sure it's possible (I can
hide/show content lines), just need to figure out how to make it work
with folding (unfolding may unhide context lines).
> If you click on the expand/collapse box in the Search Results too quickly
> (like within 1 second of a previous click) it will take you to the file. If
> you do it slower, it does what you expect: expand and collapse the block. I
> feel like it is too sensitiveness at the moment.
Yes, the double click should be completely disabled over the margin.
I'll fix that.
Thanks again.
Paul.
Other related posts:
