Author Topic: v19  (Read 11733 times)

asandler

  • Senior Community Member
  • Posts: 303
  • Hero Points: 27
v19
« 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.

xj97

  • Community Member
  • Posts: 21
  • Hero Points: 1
Re: v19
« Reply #1 on: April 23, 2014, 05:45:30 PM »
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

Jeremy

  • Community Member
  • Posts: 9
  • Hero Points: 0
Re: v19
« Reply #2 on: April 23, 2014, 06:07:34 PM »
I'm surprised it isn't in beta already.  Maybe it has to do with the Mac version taking up some extra time.

hs2

  • Senior Community Member
  • Posts: 2761
  • Hero Points: 292
Re: v19
« Reply #3 on: April 23, 2014, 08:08:52 PM »
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/

mwb1100

  • Senior Community Member
  • Posts: 156
  • Hero Points: 13
Re: v19
« Reply #4 on: April 24, 2014, 02:52:32 AM »
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.


asandler

  • Senior Community Member
  • Posts: 303
  • Hero Points: 27
Re: v19
« Reply #5 on: April 25, 2014, 06:03:18 PM »
Can anyone from SE team to comment on that?

Matthew

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 990
  • Hero Points: 44
Re: v19
« Reply #6 on: April 25, 2014, 07:54:47 PM »
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.


ehab

  • Senior Community Member
  • Posts: 285
  • Hero Points: 15
  • coding with SE is like playing music
Re: v19
« Reply #7 on: May 07, 2014, 05:12:33 PM »
sniff sniff Where is V19
i want my 19
 ::)

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 6864
  • Hero Points: 528
Re: v19
« Reply #8 on: May 09, 2014, 01:04:29 AM »
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.

jporkkahtc

  • Senior Community Member
  • Posts: 2620
  • Hero Points: 210
  • Text
Re: v19
« Reply #9 on: May 09, 2014, 06:43:12 PM »
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.

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 6864
  • Hero Points: 528
Re: v19
« Reply #10 on: May 09, 2014, 09:56:24 PM »
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.

jporkkahtc

  • Senior Community Member
  • Posts: 2620
  • Hero Points: 210
  • Text
Re: v19
« Reply #11 on: May 09, 2014, 11:18:48 PM »
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.

jaymmartin

  • Community Member
  • Posts: 57
  • Hero Points: 8
No New Features Needed Just Performance Improvements Re: v19
« Reply #12 on: May 10, 2014, 01:29:43 AM »
Or is not locking up 10,20,30 seconds after pushing a "list-symbols" key (lookup definition via tagging) a feature?


Graeme

  • Senior Community Member
  • Posts: 2796
  • Hero Points: 347
Re: No New Features Needed Just Performance Improvements Re: v19
« Reply #13 on: May 11, 2014, 11:30:53 AM »
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

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?




jaymmartin

  • Community Member
  • Posts: 57
  • Hero Points: 8
Re: No New Features .. v19
« Reply #14 on: May 12, 2014, 08:43:31 PM »
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.