SlickEdit Community
SlickEdit Product Discussion => SlickEdit® => Features and/or Improvements => Topic started by: dunkers on July 22, 2009, 08:30:21 PM
-
Dockable (and, hence, undockable) edit windows.
Mostly, as mentioned previously elsewhere, I have two edit windows - one to do the actual edits and t'other to browse code. Sometimes I really need to look at two lots of code but my setup doesn't lend itself to 3 windows. What I'd like is to create a new edit window and then drag that out of the SE main window and drop it somewhere else on my desktop, as if it were a tool window.
So, thinking about that, why can't the normal edit windows be dragged hither and yon? SE Main would then end up as a kind of control panel, much like the old Delphi and C++Builder IDEs.
-
Mostly, as mentioned previously elsewhere, I have two edit windows - one to do the actual edits and t'other to browse code. Sometimes I really need to look at two lots of code but my setup doesn't lend itself to 3 windows. What I'd like is to create a new edit window and then drag that out of the SE main window and drop it somewhere else on my desktop, as if it were a tool window.
This is similar to something I'd like to see.
I think of the Preview window as really more of a Browser window: I'm trying to understand how code fits together, and sometimes I want to refer to the definition/implementation of an arbitrary class or function while I'm working on my code. It's nice that the Preview window shows previews, but it is too transitory -- sometimes I want to "pin" something in the Preview window so that I can refer to it for an extended period of time. I'm not really previewing stuff, I'm browsing a bigger picture and sometimes my attention needs to stay focused on a specific thing for a while even when the cursor moves. The Preview window is aggressive about trying to find things to preview in an effort to help me, but sometimes I really want to override it focus my attention on a specific thing.
While something is pinned, I would expect that things like References or Search Results (etc) would override the pin and update the Preview window, but that when they are finished then the Preview window would go back to showing the pinned thing.
I've tried to examine my workflow patterns looking for a clever trigger for auto-pinning, but I haven't found one. The next best thing might be to have a simple Pin/Unpin button and command to pin a given symbol/whatever in the Preview window.
-
sometimes I want to "pin" something in the Preview window
Sometimes lots of somethings :)
But, yes, that's the sort of thing. I'd go as far as to say that the dragable edit window could be read only and not even an edit window (so long as it displays the code as if it were, with the appropriate colour scheme, etc).
-
sometimes I want to "pin" something in the Preview window
Sometimes lots of somethings :)
True! Although here's a compromise (going on the assumption that compromises are usually cheaper to implement), still residing in the Preview window: Pinning in the Preview window could show a second editor control pane. One would show the pinned thing, the other would continue to preview additional things as per usual. Pinning in the second pane would also be allowed. If both panes are pinned, then normal previewing ceases. If neither pane is pinned, they coalesce back into a single pane. If the Preview window is "wide" and/or docked at the bottom or top, then the two panes would be side by side. If the Preview window is "tall" and/or docked at the left or right, then the two panes would be arranged vertically one above the other.
Which reminds me, SE really needs to build in Ding/HS2's "preview at bottom" patch. The vertical real estate taken by the default Preview window layout is unusable when docked at the bottom. Even better, SE should have two layouts for the Preview window: one for a "wide" layout and/or docked at the bottom or top, and another for a "tall" layout and/or docked at the left or right.
-
Ummm... well I'm very protective of my preview pane and wouldn't want it to be more than a few lines as it is now. Whilst I often want to pin stuff I see in it, I never want to pin that stuff in the pane - I always double-click it into the other editor window (hence the fuss with the non-working delay a while ago). So I'm afraid to say that talk of making the pane large or small or several of them or moving them about... well, it scares me :)
But a big vote for the preview pane fix here too. I can't see the point of the comment field wasting space (the real comments will likely be the same or previous line, but more likely missing altogether). I miss being able to enter a symbol manually, as we could with the old pane. Or pop up the list of previous preview hits to go recheck something I saw a couple of mins ago (like we still have with the references pane).
-
...and sometimes I want to refer to the definition/implementation of an arbitrary class or function while I'm working on my code. It's nice that the Preview window shows previews, but it is too transitory -- sometimes I want to "pin" something in the Preview window so that I can refer to it for an extended period of time.
Don't remember where I got it, but you might find notepad.e useful.
Select some text (a class definition, for example), run 'notepad' on the SlickEdit command line, and your class def is copied to a floating window.
-
Along the lines of "two or more instances of SE" as suggested by asandler, I would like to have the ability to create a new SE instance by dragging a tab out of the current instance. I would also like to have the ability to drag tabs between instances.
Google's Chrome browser has this capability for web pages, BTW.
-
Along the lines of "two or more instances of SE" as suggested by asandler, I would like to have the ability to create a new SE instance by dragging a tab out of the current instance. I would also like to have the ability to drag tabs between instances.
Google's Chrome browser has this capability for web pages, BTW.
FWIW with Chrome each tab is already a separate instance. The analog in SE would be if each edit window in SE were a separate instance of VS.EXE (which would come at a performance penalty). SE could spawn a new instance of VS.EXE when you drag, but since it wasn't already a separate instance, there would be a rather noticeable delay in starting up the new instance. It's a cool idea -- I'm just tossing out some of the technical hurdles that make me suspect it is unlikely to happen.
-
* Performance - no pauses while typing for symbol lookup, quicker symbol reference lookups
* Support for dual monitors - dockable windows would work
* Version control settings - remember version control settings for a given project re-open them when switching projects
-
Multiple monitor support. Ability to separate a code window from the main visual slick window.
Visual Studio 2010 will have this feature:
http://weblogs.asp.net/scottgu/archive/2009/08/31/multi-monitor-support-vs-2010-and-net-4-series.aspx
-
Multiple monitor support. Ability to separate a code window from the main visual slick window.
Visual Studio 2010 will have this feature:
http://weblogs.asp.net/scottgu/archive/2009/08/31/multi-monitor-support-vs-2010-and-net-4-series.aspx
+100
The hack of starting 2 instances of SE just doesn't work properly for me, if I remember to do it at all.
-
External SE windows, say on another monitor, with tabs and other docked windows.
Now, if I drag a window (say, the Preview window) off the main SE window, it can't have other windows docked or tabbed.
I use multiple monitors and I'd like to have a window on my main monitor with multiple tabs and docked windows, and another window on the other monitor, also with multiple tabs and docked windows.
Thanks,
Ken
-
Instead of MDI, I'd like a tab interface similar to web browers (e.g. Opera), so I can open new top-level windows, reorder tabs within a window, move tabs between windows, switch between tabs with a Ctrl+Tab 'cool switch' (like Alt+Tab for top-level windows), etc.
-
Most slickedit windows maybe "floated" independently of the vs doc window, e.g., the references tool window may be placed on the X root window.
It would be useful to be able to also float the edit windows.
-
Multiple tab rows option so that if there are too many tabs, it will display extra rows instead of scroll arrows.
Or, an added feature would be to be able to define multiple tab bars and have the ability to drag a tab from one bar to another (copy a tab by Ctrl dragging). That way I could be working on two or three things at once (very common for me) and each "subproject" would have its own tab bar. New editor windows would open in the currently selected tab bar (different coloring or shading?). Maybe even an option to show only those windows in the currently selected tab bar.
-
I would like to have possibility to open separate window off SE main dock windows. I use dual - monitor and want to have two files from one project open simultaneously.
-
I second the last post. Being able to move an editor window outside of docking in SlickEdit for multiple monitors would be very useful - so two different files of the same project could be open in 2 monitors.
-
A "Tile Vertical" option under the Window menu. Also, the ability to re-arrange the window tabs by just dragging the tabs to the desired location.
It would also be nice to be able to drag and dock a file window with any side.
For examples of this concept, the NetBeans IDE has this ability.
-
A buffer window in SDI style to take advantage of multiple monitors.
-
A buffer window in SDI style to take advantage of multiple monitors.
Dragging edit windows outside the mdi frame is currently planned for v18.
-
* Support for nested C comments
* Dual monitor support:
1) When using right-screen editor, code complete mini-window spans through both screens, so part of it is not visible. I consider it as bug. Hint window should be entirely only on one screen.
2) ability to open windows on separate screens, there could be possibility to open single file twice (one should be read only, and second to write to), each on separate screen.
-
Coming back to SE after working over a year with other IDEs, here is what I still miss most:
1. A keyboard shortcut for the "Auto Hide" option of tools windows. Since there can be more than one group of tools, it would be great if each could have an individual shortcut. Currently as a workaround I move some tools onto the 2nd monitor, which unfortunately I cannot group there (see next topic) and I use the fullscreen option to "hide" the tools windows on the 1st monitor (which unfortunately unnecessarily also hides the tools on the 2nd monitor, *sigh*). There is a nice quote from SE's user manual: "Keep your hands on the keyboard - Time is wasted each time you reach for the mouse"...
2. Proper multi-monitor support:
- Grouping of tools on secondary monitors is not possible currently.
- The single biggest weakness of SE (strictly subjective, of course) still is missing support for moving editor windows on a 2nd monitor. (I know of the +new command line workaround, but it's neither convenient, nor does it work very well when working within the same project.) How about an SDI/MDI option? Having read about the improvements in SE2012 ("Much of our energy this year has been spent on reengineering SlickEdit to use a new user interface architecture. This will allow us to more quickly implement new user interface features in forthcoming versions.") I finally have new hope for this feature to be implemented finally :-)
3. A little preview window which shows what buffers you will switch to when you go to the next/prev window (usually Ctrl+Tab / Ctrl+Shift+Tab), so you can tab to the window you are looking for instead of stepping through multiple windows before you finally find the one you want to go to. (Seems to be a "standard" now in other IDEs, like Eclipse, NetBeans, VS, etc. and I got used to it pretty quickly.)
4. Support for ActionScript3/Flex (MXML) would be great. But I know this is not such a general feature as 1-3, so this is strictly an optional wish to not have to switch IDE for mobile App development.
Several other features I would have requested magically appeared in the new versions while I had my foreign affair with other IDEs, most notably Maven and Git support. Thank you!
-
Yes, we read them ;D We've been looking at Clang. Nothing planned for the next release though. The next release will allow MDI child edit windows to be dragged outside the MDI area for better multi-monitor support. A ctrl-tab preview would be nice.
-
Please return to the pre-2013 editor windows on the windows version. At least make it a configurable option. I really hate the Visual Studio look and feel. If you aren't going to offer an alternative, I might as well use Visual Studio and save a lot of money. Being able to float the windows outside the main window frame would be a nice option, but I don't like that mode for all of my windows and the way they behave when they are docked just sucks.
-
I sometimes do a Window->Duplicate to create a second window so that I can work in the top and bottom of the same file at the same time. I also have 4 monitors so sometimes things get a little misplaced (okay, downright lost). Right now I'm looking at the CFile.c:2 window and I can't find CFile:1. It would be nice if I could click on the file in the File Tabs and it would cycle through the various :1 ... :n windows and bring them to the front.
I know about Window->Windows.. and then scroll down to the window I need to find but considering I have an average of 3 duplicated windows open at once in a list of up to 50 files, it's a little tedious.
-
I run three tab groups in the SE main window. Occasionally I'll close a file that's the only file in a tab group so the tab group also closes leaving me with two on the screen.
I would like an option that would leave the tab groups open even if they have no files in them. Yes, I know that I can create a tab group with either the Window menu or by dragging a file over to the edge of a group. I just don't like getting a surprise when my tab group disappears.
-
My Wish List:
1. Custom "segregable" (color/grouping/separate-lines/etc) file/buffer tab displays
I often find myself working with similar-named files from multiple projects at once, often comparing differences between the same-named files. Recent VisualStudio (V13 onwards, IIRC) offers different "types" of tab groups (grouped by end, grouped as separate lines, etc.) and it would be nice if users could segregate open files in a similar manner in SE. Clarifying, I am not asking here for multiple projects at once (that's a different ask), this is strictly about supporting new means of grouping/segregating file tabs in the file tab display(s).
Ideally, I'd like a system where I could run a set of arbitrary user-set ordered rules against a newly-opened file (or buffer) in order to assign it to different filetab "groups" (or assign different attributes, like color). Attributes/grouping options would include {left, middle, right} in tab line, tab color, tab text attributes, separate tab lines, and so forth. Conceptually similar to where Visual Studio is going with tab handling, or where VisualStudio third-party extension "VisualDocs" (https://visualdocs.net/) allows with their custom tab display.
As a stretch goal, allow users to open multiple "file collection" windows/panes across multiple monitors (with distinct sets of filetabs), and allow them to use rules to segregate both window to use and how to configure filetab.
2. Support for "Peek"-type view displaying definition/declaration/etc.
VisualStudio 2015 (V14) has provision now when user wants to see associated definition/declaration, instead of having to open distinct file buffer, it can temporarily pop up an overlay which shows the file containing the relevant definition/declaration, in a scrollable view, but which disappears upon next editing action into main view. This allows quick perusal of references without causing overpopulation of open files (nor disruption of filetab schema). Doing so is much more real-estate effective, IMO, than the "open ref file as normal tab, but on right end of tab line, and close on next lookup action used with VisualStudio2013 (IIRC).
3. Elastic Tabstops
See Nick Gravgaard's article and discussion of them here (http://nickgravgaard.com/elastic-tabstops/). This would be _very, very_ useful, esp. if it could properly interoperate with other implementations.
4. Allow multiple open projects/workspaces at once
This was always kind of inevitable, wasn't it? Unless/until #1 is implemented, perhaps give different projects'/workspaces' files their own tab lines. Once #1 exists, allow rules to use "project"/"workspace" as differentiator in rule generation.
That's all for now, thanks as always for all the hard work!!
-
My Wish List:
1. Custom "segregable" (color/grouping/separate-lines/etc) file/buffer tab displays
I often find myself working with similar-named files from multiple projects at once, often comparing differences between the same-named files. Recent VisualStudio (V13 onwards, IIRC) offers different "types" of tab groups (grouped by end, grouped as separate lines, etc.) and it would be nice if users could segregate open files in a similar manner in SE. Clarifying, I am not asking here for multiple projects at once (that's a different ask), this is strictly about supporting new means of grouping/segregating file tabs in the file tab display(s).
Ideally, I'd like a system where I could run a set of arbitrary user-set ordered rules against a newly-opened file (or buffer) in order to assign it to different filetab "groups" (or assign different attributes, like color). Attributes/grouping options would include {left, middle, right} in tab line, tab color, tab text attributes, separate tab lines, and so forth. Conceptually similar to where Visual Studio is going with tab handling, or where VisualStudio third-party extension "VisualDocs" (https://visualdocs.net/) allows with their custom tab display.
As a stretch goal, allow users to open multiple "file collection" windows/panes across multiple monitors (with distinct sets of filetabs), and allow them to use rules to segregate both window to use and how to configure filetab.
2. Support for "Peek"-type view displaying definition/declaration/etc.
VisualStudio 2015 (V14) has provision now when user wants to see associated definition/declaration, instead of having to open distinct file buffer, it can temporarily pop up an overlay which shows the file containing the relevant definition/declaration, in a scrollable view, but which disappears upon next editing action into main view. This allows quick perusal of references without causing overpopulation of open files (nor disruption of filetab schema). Doing so is much more real-estate effective, IMO, than the "open ref file as normal tab, but on right end of tab line, and close on next lookup action used with VisualStudio2013 (IIRC).
3. Elastic Tabstops
See Nick Gravgaard's article and discussion of them here (http://nickgravgaard.com/elastic-tabstops/). This would be _very, very_ useful, esp. if it could properly interoperate with other implementations.
4. Allow multiple open projects/workspaces at once
This was always kind of inevitable, wasn't it? Unless/until #1 is implemented, perhaps give different projects'/workspaces' files their own tab lines. Once #1 exists, allow rules to use "project"/"workspace" as differentiator in rule generation.
That's all for now, thanks as always for all the hard work!!
Any hope for #2 or #3 coming in V22?
-
Not planned for v22. #2 neat that you can edit but there's a problems with overloading. After you add a parameter, then you won't get the right symbol in the insert edit window. SlickEdit's preview tool window is read-only. Maybe the preview tool window should be changed to be read/write. Navigating to a symbol can solve any overloading issues. SlickEdit is more forgiving in the simple overload case.
-
Not planned for v22. #2 neat that you can edit but there's a problems with overloading. After you add a parameter, then you won't get the right symbol in the insert edit window. SlickEdit's preview tool window is read-only. Maybe the preview tool window should be changed to be read/write. Navigating to a symbol can solve any overloading issues. SlickEdit is more forgiving in the simple overload case.
W.r.t. #2, I'm actually okay if the peek view doesn't allow editing in-view, as in if the pop-up view is read-only. Would that make a difference whether doable in v22?
Any reason why no #3 in v22? Can we at least get some vertical alignment options for styling (a la Code Alignment (http://www.codealignment.com/))?