SlickEdit Community
SlickEdit Product Discussion => SlickEdit® => Topic started by: asandler on April 17, 2014, 07:35:23 PM
-
I am wondering when v19 is coming out and what is planned for the version.
Thanks,
Alex.
-
The oldest comment in last years beta section is April 24, so I hope it will be soon. I'd love to see a feature list as well.
Baker
-
I'm surprised it isn't in beta already. Maybe it has to do with the Mac version taking up some extra time.
-
I afraid this caused a lot of trouble and resource drain :( HS2
http://blog.slickedit.com/2014/03/slickedit-defeats-patent-troll-uniloc-in-patent-lawsuit/
-
Also, some comments on this "Core for Kepler Beta" thread, http://community.slickedit.com/index.php/topic,9681.0.html, makes me believe that the situation with that product was consuming scarce resources.
-
Can anyone from SE team to comment on that?
-
We had a "what's coming up next" request back in February: http://community.slickedit.com/index.php/topic,9760.0.html
In addition to what was discussed there, we are adding support for multiple cursors. That's a pretty big feature with a lot of "should we do A or B" behaviors to sort out. Clark will have more details on how multiple cursors behave once we have the first beta ready.
The Core for Eclipse issues have mostly been resolved (Core for Eclipse 4.3 Kepler went Beta today), but we are still working through problems with Qt on Mac OS X Mavericks, which has been a bit of a hassle. But neither of those issues have monopolized the entire team's efforts. We are still hoping to have a beta of SE2014 sometime in mid-to-late May.
-
sniff sniff Where is V19
i want my 19
::)
-
We are still working on some v19 features.
Here's some info on multiple cursors/selections:
To add a cursor, use Ctrl+LButtonDown. To add a selection, use Ctrl+LButtonDown and drag the mouse. Ctrl+DoubleClick will also add a selection. Use Shift+RButtonDown and drag to create multiple character (stream) selections.
When you use Shift+RButtonDown and drag, you will see what looks like a typical column selection being created. However, after you release the mouse a character selection will be created for each partial line selected by the column selection. Virtual space past the end of the line is not selected.
If you make a mistake (really easy to do) while adding a cursor/selection, you can use undo to remove it!
Most cursor movement commands (i.e. cursor left, cursor right, next word, prev word) will operate on all cursors/selections.
Most selection operation commands (i.e. upcase-selection, lowcase-selection, fill-selection) operate on all cursors/selections. Search and replace commands don't support searching within multiple selections and will only operate on the active selection.
Simple typing operations are supported by multiple cursors and selections. Syntax expansion, alias expansion, and basic word complete commands are supported (complete-next, complete-prev, and
complete-more). Context tagging completions are not yet supported.
In VI emulation, almost all insert mode, command mode, and visual mode commands are supported. The VI ex command line commands do not support multiple cursors/selections.
Esc in all emulations removes the multiple cursors/selections. Press undo if you accidentally remove them and want to bring them back.
NOTE: It is not always obvious what a particular command should do when there are multiple cursors. For example, what should top-of-buffer do? Currently it only operates on the active cursor/selection. It could easily be changed to move all cursors/selections but since overlapping cursors/selections are merged, this would essentially remove all but one cursor/selection.
Cut/Paste and Multiple Cursors
When SlickEdit creates a clipboard, it stores a count of the number of cursors there were when the clipboard was created. Then when you paste into a file with the same number of cursors as the clipboard, SlickEdit will attempt to paste segments of the clipboard at each cursor location.
If the number of lines in the clipboard is not divisible by the number of cursors or the number of cursors don't match, the entire clipboard is pasted at each cursor location.
When Should I use Multiple Cursors
The best use of multiple cursors is for creating source code from a list of identifiers. If the identifiers are on separate lines, you can create the multiple selections very quickly using Shift+RbuttonDown. Once you have the multiple selections, you can make simultaneous edits for example, to create source code for case statements (case <CONSTANT>: ) for a switch. Alternately, you can quickly create a quoted list of identifiers for a table.
Some Related Changes added for Better Multiple Selection Support
By default, when there is a selection and you type one of the characters " ' ` ( ) [ ] { }, the selection is surrounded by quotes, parens, brackets, or braces. This is very handy when used in conjunction with multiple selections for say quoting a list of words selected using Shift+RButtonDown.
-
Sounds very interesting.
Does this feature work well when you have multiple views of the same buffer?
Sometimes I will split a window so I can see two different sections of the same file, sometimes making changes in both. Its annoying that there is just one selection, one undo path, etc - too much linking between the views.
A model that would often work better: Imagine how something like CollabEdit/google docs that lets multiple people work on the same doc - it keeps them in sync even though both editors are independent.
-
The multiple cursors/selections are stored in the buffer and not in the window/view.
I seriously looked into seeing if I could have selections per window but it would have been a bad idea. This would have been very complicated to implement, harder to use, not had good macro compatibility, and undo would have been very tricky. The cons definitely out weighed the pros.
If SlickEdit only supported "One file per window", this would be a MUCH simpler problem to solve. There are still many customers (like me) which don't use "One file per window" mode.
If you have multiple selections/cursors in one buffer and make a selection in another buffer, the multiple selections/cursors are cancelled. You can use undo to bring the selections/cursors back. If you split the buffer, switch to the other window and move the cursor, the multiple selections/cursors are cancelled. Again you can use undo to bring the selections/cursors back.
I split windows ALL the time so I would personally benefit from being able to create selections per window/view. Like I said, the cons substantially out weighed the pros especially when the current design supports undo for adding and removing cursors/selections.
What I don't like is the fact that if I split the window, create a selection, and switch the other window, then the selection is extended to the cursor in the other window and disappears when I move the cursor. I don't really need selections per window but it would fix this issue. This occurs when I want to browse another part of the same file before I complete the operation on the selection.
-
Makes sense.
Maybe an extended highlight system - that works sorta like selections.
I often select a block of text just to highlight it while working in a different window and referring back to the highlighted text.
(Recent versions of Office are really annoying because they hide the selection highlight when the window doesn't have cursor focus - a horrible anti-feature).
I use one of the highlighting macros (quickHighlight.e) that is in the macros forum. Its great, but it could really use a UI to let me quickly toggle each individual highlight on or off, as well as a more flexible way to define the highlights.
Highlight a word, highlight a regex, highlight a selection with smart anchor points that move with the text, etc.
-
Or is not locking up 10,20,30 seconds after pushing a "list-symbols" key (lookup definition via tagging) a feature?
-
Or is not locking up 10,20,30 seconds after pushing a "list-symbols" key (lookup definition via tagging) a feature?
I'm not sure what you're saying here but I'll take a guess that you're referring to this problem you complained about.
http://community.slickedit.com/index.php/topic,9531.msg40652.html#msg40652 (http://community.slickedit.com/index.php/topic,9531.msg40652.html#msg40652)
I've never given any thought to what slick has to do to handle lookup of a templated name.
What does it do for a non templated name - with background tagging turned off, does it parse any header files that are included by the current file. Let's say it doesn't - so lookup goes straight to the tag file and should be quick. So why would templates be slow? I guess it must be that slick has to find the correct instantiation / specialization.
e.g.
vector<int> abc;
... abc.push_back(23);
How does it find the correct push_back? Does it already know where the source code for vector<int> is? If so, looking up push_back should be fast. Is it fast for you? Can you give an example of something that's fast and something that's slow?
-
No, its not just templates only (though they may be what is messing things up (complex parsing)). For example, I tried to look up a simple C++ enumeration type declared a few lines above, and it took 20+ seconds according to the profiler with 1/2 of time in one call to "tag_context_match_tags" and 1/2 in 5 calls to "tag_list_symbols_in_context". It does get to the declaration eventually. Note I have background tagging disabled and no-preview window (defensive measures). Also I have latest the Slickedit version. I believe these problems have been going on for years... and I realize parsing a large C++ project is a very complex task and C++ is rapidly changing right now. Also I know threading for parallelism a historically single threaded app is difficult.
-
If you look a symbol up using the find symbol toolbar and select "lookin => specific tag file" does it still take a long time? If the enumeration is in another source file instead of the current source file does it take a long time? You probably know that "context" refers to the fact that if the current file is not part of the project/ workspace tag file, slick still "tags" it - but it doesn't take 20 seconds to tag one source file so why would the lookup take 20 seconds? Is it slow on all lookups? If this was happening for everyone I think there would be a few more complaints.
-
There are tons of complaints in this forum going back at least 5 years related to tagging performance problems. I suspect some of us have just given up complaining about it and there also have been promises that it is on the "performance enhancement road map". That is why I prefer they work on performance problems and not on useless features that I will likely have to figure out how to disable....
-
It also effects Symbol Coloring. One source file I edit has a 'black spot' around midway down. When scrolling in this area SlickEdit will get very busy for about 10 seconds and then crash out with :
/opt/slickedit/bin/vs: line 38: 30545 Segmentation fault (core dumped)
I've not managed to make a simple repo case :(
-
It also effects Symbol Coloring. One source file I edit has a 'black spot' around midway down. When scrolling in this area SlickEdit will get very busy for about 10 seconds and then crash out with :
/opt/slickedit/bin/vs: line 38: 30545 Segmentation fault (core dumped)
I've not managed to make a simple repo case :(
A complicated repro case will do. If you have one, SlickEdit will probably be interested, even if you don't have maintenance and support. You need to register though.
https://customer.slickedit.com/support/opencase (https://customer.slickedit.com/support/opencase)
-
There are tons of complaints in this forum going back at least 5 years related to tagging performance problems. I suspect some of us have just given up complaining about it and there also have been promises that it is on the "performance enhancement road map". That is why I prefer they work on performance problems and not on useless features that I will likely have to figure out how to disable....
There's plenty of posts relating to tagging performance but I couldn't find any at all that seem to be the same problems that you have. There is this post but he's complaining about push_ref
http://community.slickedit.com/index.php?topic=9083.0 (http://community.slickedit.com/index.php?topic=9083.0)
I guess you've seen the suggestions to turn off symbol coloring and auto completion.
For example, I tried to look up a simple C++ enumeration type declared a few lines above, and it took 20+ seconds according to the profiler with 1/2 of time in one call to "tag_context_match_tags" and 1/2 in 5 calls to "tag_list_symbols_in_context".
Is your source file #including all of the boost header files or lots of STL header files? Try hiding some of them from slick and see if the lookup gets faster.
Unless you're sure that SlickEdit are aware of the problems you're having, you should try and report them directly to SlickEdit.
-
is there a date set for first beat? it has been quite or i am not finding anything about next version,,, best summer wishes for the se.dev.team.