Author Topic: C# - Where Slickedit Falls Short  (Read 3426 times)

vivitron

  • Senior Community Member
  • Posts: 162
  • Hero Points: 10
C# - Where Slickedit Falls Short
« on: March 22, 2010, 02:13:45 pm »
I've been using Slickedit as my primary development editor simply because I cannot stand the fact that VS wants to do everything for me. 

I just want a simple editor that supports:
  • Supports multiple languages - I program in Perl, VBScript, Javascript, C#, and many other odd languages
  • Doesn't do everything for me... But allows me to setup shortcuts to common tasks
  • Is super fast... Some files are over a thousand lines... Some projects are over a thousand files...
  • Has a class outline view

With that, I'm been overall happy with C# support... There are a few annoying things:
  • Class/Function attributes are not handled correctly when commenting.  If I use the comment editor, it will apply the comment to the function and separate the function and attribute... i.e.
Code: [Select]
[DataMember]
public string DoSomething() {}

Becomes

Code: [Select]
[DataMember]
/// <summary> Do Something returns xyz </summary>
public string DoSomething() {}

Whereas it should be

Code: [Select]
/// <summary> Do Something returns xyz </summary>
[DataMember]
public string DoSomething() {}
  • Region support! With large files, I need to be able to visually divide the class up... It would be nice if the Defs panel supported regions.
  • Symbols coloring looks nice, but it performs horribly on my machine... I've read many forum articles and things help, but I need the editor to be fast
  • It would be nice to add dependencies other than projects... I end up maintaining a custom tag file for each project

Things I'm really happy with:

  • The fact that commenting is built in
  • The tagging system... It's not perfect, but often it is enough.  I do find it is slow with large projects, so I have set it up to only suggest properties, etc when I request it with ctrl+space.
  • Custom compiler support / output parsing ... Integrating with MSBuild was a snap

Hope this helps!

vivitron

  • Senior Community Member
  • Posts: 162
  • Hero Points: 10
Re: C# - Where Slickedit Falls Short
« Reply #1 on: March 22, 2010, 03:15:32 pm »
One last thing:  Beautify fails on a C# Buffer with inline property initializers:

Code: [Select]
            SomeType newObject = new SomeType()
            {
                ListOne = new List<string>(),
                ListTwo = new HashSet<int>(),
                FirstName = "John",
                LastName = "Doe"
            };

This fails with "unmatched right brace at line xx"


vivitron

  • Senior Community Member
  • Posts: 162
  • Hero Points: 10
Re: C# - Where Slickedit Falls Short
« Reply #2 on: March 22, 2010, 05:58:04 pm »
Feel like I'm a sounding board here...

Anyhow, the C# parser does not understand the word "base."
Code: [Select]
public override bool CanWriteProperty(string propertyName)
        {
            if (! propertyName == "CommentId")
            {
                 return false;
            }

            return base.CanWriteProperty(propertyName);
        }

Would be nice in tagging and go to definition... Since C# classes can only inherit from one class, this seems pretty easy.


Matthew

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 990
  • Hero Points: 44
Re: C# - Where Slickedit Falls Short
« Reply #3 on: March 22, 2010, 07:58:30 pm »
Thanks for this very useful feedback. I don't know if we'll be able to address any of these issues for the forthcoming SlickEdit 2010 release, since we're so late in the Beta cycle. But this level of detail makes it much easier for us to log bugs and feature requests, especially for our point releases.

rod_gomz

  • Community Member
  • Posts: 80
  • Hero Points: 1
Re: C# - Where Slickedit Falls Short
« Reply #4 on: March 22, 2010, 08:04:51 pm »
Slick's virtue is the editor, and second multi language. If you want a better C# idea, try IDEA's resharper. I hear it is really good.

I've been using SE for years and will continue to do so, but for Java I use IDEA. IDea however is a memory hog, but the language support is superb.

vivitron

  • Senior Community Member
  • Posts: 162
  • Hero Points: 10
Re: C# - Where Slickedit Falls Short
« Reply #5 on: March 22, 2010, 08:07:33 pm »
I've tried resharper and cannot stand the performance drain.  I already prefer Slickedit to resharper.

I was just letting everyone know of issues that Slickedit has with C# since I've spent hours testing it.

Also, I found someone else who mentioned the attribute / comments issue:

http://community.slickedit.com/index.php?topic=4181.0

Sorry for the duplicate issue.

rod_gomz

  • Community Member
  • Posts: 80
  • Hero Points: 1
Re: C# - Where Slickedit Falls Short
« Reply #6 on: March 22, 2010, 08:09:51 pm »
I have the same issues with PL/SQL but is unlikely that the SE team will have a rollout for any particular language, other than Java, and even then, Java lacks abit.

vivitron

  • Senior Community Member
  • Posts: 162
  • Hero Points: 10
Re: C# - Where Slickedit Falls Short
« Reply #7 on: March 22, 2010, 08:16:41 pm »
Probably not... but I think it helps if they know what the issues are.  Also saves other users from searching for solutions.

rod_gomz

  • Community Member
  • Posts: 80
  • Hero Points: 1
Re: C# - Where Slickedit Falls Short
« Reply #8 on: March 22, 2010, 08:21:45 pm »
What would help the SE team is if the language like PL/SQL, C#, etc had their parsers open source, then the SE team can integrate them easier. I doubt Oracle will give out their PL/SQL parser implementation out for free.