[done] search function

Request Features and Feature Changes

[done] search function

Postby diep » Wed Aug 22, 2007 6:18 pm

hello Cody!

With respect to searching, it is real cool for programmers when there is option to search default through all documents loaded in editor.

I do not know about other programmers, but usually i do remember the variable name, just not which file it is, or i am simply too lazy to mouse click the other file, and as i have to 'search' for it anyway, it's faster to directly search through all windows.

of course this option must be able to get turned off.

it is also very useful to know whether a variable name you declare already didn't exist yet, or simply in source code of others see *where else* it exists.

Interesting idea?

It's so default in windows source code editors that i'm amazed this is not so easy to do in other editors. it is how i *default* search.

Oh dear, i really fear i'm giving you too much work!

Let's make something cool out of this product!
Thanks for the great work,

Vincent
diep
User
 
Posts: 27
Joined: Fri Aug 17, 2007 9:10 pm
Location: The Netherlands

Postby cody » Wed Aug 22, 2007 11:11 pm

I am planning to revisit some to the search code in the next iteration, so I will look into adding some hooks to make implementing this an easier task at that time.

I have been thinking about writing a plugin to enumerate all search matches in a docked subwindow, that would show some preview text, line number, file, ect.. and allow jumping to the match by clicking on the item in the list. Would something like this fulfill the functionality you are looking for?

cody
User avatar
cody
Site Admin
 
Posts: 1315
Joined: Mon Oct 09, 2006 2:49 am
Location: United States

Postby diep » Sun Aug 26, 2007 3:16 pm

cody wrote:I am planning to revisit some to the search code in the next iteration, so I will look into adding some hooks to make implementing this an easier task at that time.

I have been thinking about writing a plugin to enumerate all search matches in a docked subwindow, that would show some preview text, line number, file, ect.. and allow jumping to the match by clicking on the item in the list. Would something like this fulfill the functionality you are looking for?

cody


Sorry for waiting so long to reply to this. I've been thinking about it.

In itself this is a great idea. A little like visual studio is doing it.

What is by far best is that when people press apple-f, is show a popup with all kind of options (modal dialog box actually). Right now it's occupying a useless line in the window for nothing. Yes i can click it away, but that's not interesting at all, as that means an extra mouseclick. We really want a modal dialog box for this.

If you put things in a different buffer that's great, as long as that buffer isn't full screen, so NOT pushing away the window that was currently the active buffer. I assume this was exactly your description.

With an editor for source code we should take into account that this isn't word. Programmers are lazy, but not beginners. They are advanced computer users and make software for others.

So where for the average user the MDI idea is outdated and the SDI design with dockable windows is the superior thought, that's quite hard to realize in the long term as the best editting solution from programmers viewpoint.

Yet for the search it IS a very great thought.

In combination with allowing to start more instances of editra in OS/X that is the key to a succesful solution IMHO avoiding MDI design.

So the functional specs would be from user viewpoint:

User hits apple-f (or in windows control-f) a modal dialog box pops up, with choice to display all hits in a dockable window. Default this choice turned on of course. User types in his string and if he hits enter, it finds first hit, whatever file it is, and editor goes default to this file where first hit has been found, meanwhile opening a dockable window which is NOT the active window, showing all hits. this dockable window, keep it default tiny (unless users have modified size of course) showing at most a hit or 5.

Now apple-g default goes to the next hit (this is default OS/X behaviour and should be therefore followed as i feel standardization in a way user is used to work with the OS is important, and if you keep the apple down and just keep hitting 'g' then user goes from hit to hit).

Thanks,
Vincent
diep
User
 
Posts: 27
Joined: Fri Aug 17, 2007 9:10 pm
Location: The Netherlands

Postby cody » Tue Aug 28, 2007 5:27 am

I will keep this in consideration for a future enhancement.


For reference the current controls for searching text are as follows:

Cmd + F : 'Quick Find' opens interactive find as you type search bar
Cmd + Shift + F : 'Find' opens a native system non modal find dialog
Cmd + R : 'Find Replace' opens a Find and Replace non modal dialog

All support the use of regular expressions for searching and only search in the currently selected text buffer. Find preferences (Match Case, Whole Word) are remembered during a session but not saved for future sessions (this may change soon)). I will probably also add bi-directional searching in the release after the next one.
User avatar
cody
Site Admin
 
Posts: 1315
Joined: Mon Oct 09, 2006 2:49 am
Location: United States

Postby cody » Sat Aug 30, 2008 6:20 pm

The next release will have the following features that I believe fulfill this request:

Find All in Open Documents
Find All in Files (specified directory of files to search)


cody
User avatar
cody
Site Admin
 
Posts: 1315
Joined: Mon Oct 09, 2006 2:49 am
Location: United States


Return to Feature Requests

Who is online

Users browsing this forum: No registered users and 1 guest

cron