Author Topic: unhappier and unhappier with V11 :-(  (Read 29874 times)

greggman

  • Senior Community Member
  • Posts: 273
  • Hero Points: 13
unhappier and unhappier with V11 :-(
« on: September 20, 2006, 06:30:09 am »
I'm an old timer when it comes to slickedit. I've been using it since version 1 and have owned almost every version. This time it really seems like version 11 was shipped early without proper testing or quality assuance.

I really need to keep a log because I can't name all the annoying things that have come up to make v11 m worst slickedit experience but I'll try to recall a few

* command-line-prompted search is broken such that they can't be used in macros like version 1 through 10. Supposedly that's been fixed but the fix is not in 11.0.2

* I have a macro written since version 1 that takes the current line and centers it in a 1 line comment. Up through version 10 it ran instantly. I could line up 10 lines and press Alt-6 (what I have it assigned) to 10 times and in terms of speed it felt like I might have well been pressing a letter key it was so fast.  As of version 11 it now feels like it takes half a second per press! When did slickedit get so slow? What happened to the "slick" part of slickedit?

* Yesterday I had slickedit lockup in the commandline. Lockup is not the right word. The cursor was in the commandline but I couldn't get it out. Pressing ESC didn't work. Clicking somewhere else didn't work. I end up having to kill slickedit from the task manager.

* Slickedit gets slower and slower in pulling up tag info. Up through v9 things seemed quick. As of v10 and now it's even worse in v11, sometimes it seems to take 2 or 3 seconds before the tag help comes up, during which my keyboard is frozen.  It's past the point that it effects my work enough I'm going to have to turn it off which would really suck.

* the new replace preview thing doesn't work for me. Under version 11 when I do a search and replace slickedit highlights what will be replaced AND below that shows what it's going to be replaced with. I'm sure that seemed like a good idea at the time but in practice it blows because more often then not it's covering up relavent information to decide if I want to do the replace or not.  Even if the info is not relavent my code no longer looks like I remember it because of the cover up so the context of familiarty (the look of the code) is gone and it takes me noticable time to get my barrings. In other words this *feature* instead of being helpful is actually slowing me down.

* v11 added better paren highlighting. Unfortunately it's like running in a background task and shows noticibly late. While that probably seemed like a good idea especially if it's a long search to find the matching paren it sucks in normal use. It's very distracting to see the parens highlights appear or disappear a few moments AFTER the cursor has moved instead of like every other program in existance, the moment the cursor moves. I'm guessing it has to do with human eyes being tuned to movement (or change). In pretty much ALL other software and in slickedit v1 to v10 when pressing the cursor keys the only thing that changed on the screen was the cursor. Now though since the highlighted parens are also changing AT DIFFERENT TIMING then the cursor it appears as an extra movement. My eyes notice and it becomes a distraction similar to a gnat flying in front of my eyes.

On top of that the paren matching is still missing features. Emacs (which I am not a fan off) still has better paren matching because emacs shows the line that matched in the status bar with the match highlighted. That way even if the line is off the screen I can see the match.  A good version of emacs will even show the preceding line if the paren is on a line by itself so context is not lost.

I know there are more issues I've run into. I want to help fix them. Not in a hack on the slickedit macros way though. In a fix the actual distro way. And fix that requires me to customize the installed macros is not a fix IMO. I really want to continue to like slickedit. I've been using it since 1993 but since v11 I've been annoyed so often that I do actually think about giving it up. That never happened in version v1 to v9. Please help me stay a believer.

jbezem

  • Community Member
  • Posts: 80
  • Hero Points: 8
Re: unhappier and unhappier with V11 :-(
« Reply #1 on: September 20, 2006, 12:52:20 pm »
Being an oldtimer myself, sadly, I must agree with several of the observations greggman makes.

* I have a macro written since version 1 that takes the current line and centers it in a 1 line comment. Up through version 10 it ran instantly. I could line up 10 lines and press Alt-6 (what I have it assigned) to 10 times and in terms of speed it felt like I might have well been pressing a letter key it was so fast.  As of version 11 it now feels like it takes half a second per press! When did slickedit get so slow? What happened to the "slick" part of slickedit?
This is my observation also. OK, tagging wasn't as powerful, and JavaDoc-Help didn't exist, but even when I switch off all these (admittedly: cool) helpers, the software has a much more sluggish feel, on hardware more than x times as powerful than version 2 (the first 'Visual' version) ran on.

* Slickedit gets slower and slower in pulling up tag info. Up through v9 things seemed quick. As of v10 and now it's even worse in v11, sometimes it seems to take 2 or 3 seconds before the tag help comes up, during which my keyboard is frozen.  It's past the point that it effects my work enough I'm going to have to turn it off which would really suck.
I'm not a speed typist, and I need to look at my keyboard when typing, because I tend to use more than 3 different language layouts on single machines (using US for programming, but German for Documentation in Word, even when writing English). But when my screen changes without me toching the keyboard, I always assume a popup, and look up, just to be informed that SlickEdit has found some tags again. Tuning Tag-cache didn't help much in v11, but the problem has been growing through the versions.

* the new replace preview thing doesn't work for me. Under version 11 when I do a search and replace slickedit highlights what will be replaced AND below that shows what it's going to be replaced with. I'm sure that seemed like a good idea at the time but in practice it blows because more often then not it's covering up relavent information to decide if I want to do the replace or not.  Even if the info is not relavent my code no longer looks like I remember it because of the cover up so the context of familiarty (the look of the code) is gone and it takes me noticable time to get my barrings. In other words this *feature* instead of being helpful is actually slowing me down.
If you wish, set the macro variable def_disable_replace_tooltip to 1, and 'all' is as it was. I have too...

* v11 added better paren highlighting. Unfortunately it's like running in a background task and shows noticibly late. While that probably seemed like a good idea especially if it's a long search to find the matching paren it sucks in normal use. It's very distracting to see the parens highlights appear or disappear a few moments AFTER the cursor has moved instead of like every other program in existance, the moment the cursor moves. I'm guessing it has to do with human eyes being tuned to movement (or change). In pretty much ALL other software and in slickedit v1 to v10 when pressing the cursor keys the only thing that changed on the screen was the cursor. Now though since the highlighted parens are also changing AT DIFFERENT TIMING then the cursor it appears as an extra movement. My eyes notice and it becomes a distraction similar to a gnat flying in front of my eyes.
Again, I agree. Reduce the time SE waits until starting to find the matching paren by reducing the macro variable def_match_paren_idle, default seems to 50, I'd assume milliseconds, or switch it off altogether by setting macro variable def_highlight_matching_parens to '0' zero.

On top of that the paren matching is still missing features. Emacs (which I am not a fan off) still has better paren matching...
From when I used emacs, ages ago, emacs never was quick. This used to be one of the reasons I switched to SE in the beginning of the nineties.

There are more issues. The solutions I've offered here are not really solutions, since they simply switch off new functionality. Even with enhanced functionality and Windows underneath, I'd hope at least someone would be able to resist pure feature-itis (however handy that might turn out in the short run), and pay proper respect to speed. An up-to-date XP machine idling around 97% should be able to outperform a 286 using SlickEdit 1.72 on DOS 3.31, even with all the new features! But sometimes it doesn't feel like it, admittedly subjectively.

But since SlickEdit for me is without serious competition, I'd rather see the issues fixed. So keep up the good work and pay some attention to reaction speed.

Regards,

Johan

apnakon

  • Community Member
  • Posts: 27
  • Hero Points: 2
Re: unhappier and unhappier with V11 :-(
« Reply #2 on: September 20, 2006, 01:23:25 pm »
Hi All,

I can't talk as far as comparisons between the older versions of SlickEdit to v11.02 is concerned, so
in no way am I making any claims in that arena.

In relation to CodeWright (I used it from v4 to it's sad demise at v7.52), which I believe was a serious competitor to SlickEdit for a number of years, for me there is no comparision in terms of speed, responsiveness and stability.

SlickEdit wins hands down.

I don't say this lightly, since I was a great supporter of CodeWright.  I loved using it.  But it was sluggish (esp. with large files, starting up, selective display [the selective display speed in SlickEdit is awesome], etc.), and was prone to crash from time to time.  In fact, I think there was a memory leak in the last version somewhere since I could not leave the editor open for a few days without my PC getting sluggish (at which point, a restart of CodeWright would fix things).

It would be interesting to hear about experiences people have had with other commercially available editors. 
As an aside, the thought of EMACS makes me shudder with horror.  :)  I tried using it on a Solaris platform a few years ago (the 'x' version) and it was truely terrible (in my opinion, of course.  To each his/her own).

I guess that nothing is perfect, but a good thing is a development team at SlickEdit who actually respond with emails concerning suggestions.  CodeWright (Premier, Starbase) never did that.  Perhaps one of the reasons they aren't around anymore.

Cheers,

Adrian.


Lee

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 1120
  • Hero Points: 102
Re: unhappier and unhappier with V11 :-(
« Reply #3 on: September 20, 2006, 01:50:28 pm »
Quote
* command-line-prompted search is broken such that they can't be used in macros like version 1 through 10. Supposedly that's been fixed but the fix is not in 11.0.2
An issue has been discovered in 11.0.2 regarding command-line prompted searches and macro recording not functioning correctly in Brief emulation.  A hotfix is available by contacting Customer Support (support@slickedit.com).  If you are not using Brief emulation, then it's possibly another macro recording issue that needs to be addressed.  If that is the case then definitely contact support, give a full description of the problem and provide as much information and as possible (emulation, settings, recorded macros that don't work), and we can try to correct the issue with a workaround or hotfix.

Quote
* the new replace preview thing doesn't work for me. Under version 11 when I do a search and replace slickedit highlights what will be replaced AND below that shows what it's going to be replaced with. I'm sure that seemed like a good idea at the time but in practice it blows because more often then not it's covering up relavent information to decide if I want to do the replace or not.  Even if the info is not relavent my code no longer looks like I remember it because of the cover up so the context of familiarty (the look of the code) is gone and it takes me noticable time to get my barrings. In other words this *feature* instead of being helpful is actually slowing me down.
As already mentioned, set-var (or Set Macro Variable...) def_disable_replace_tooltip to 1 will disable the Replace tooltip helper.

hs2

  • Senior Community Member
  • Posts: 2728
  • Hero Points: 282
Re: unhappier and unhappier with V11 :-(
« Reply #4 on: September 20, 2006, 02:08:13 pm »
Due to the fact that almost every 'new' feauture could be disabled (somehow) the  remaining big point is the tagging speed.
@greggman: E.g. your observation related to 'slow commenting' is surely caused by the new commentwrap feature. This is also costly by nature, but could be switched off too in the file ext setup.

Tagging is a really hard job and I didn't see another tool which outperforms Slick in this field.
Used CRiSP quite a while and worked together with Codewrighters.

It's also difficult to compare the tagging performance as the tagging results were also improved over the time.
But maybe they already started a redesign to make use of the multi-core machines we all will use soon ;)

I ( have to ;) ) trust in the Slickteam and I got the impression that they think 'the same way' as I do and attach importance to similar things.
I'm sure it's not easy to find good compromises to satisfy all customer requests they get.

@Lee: So hotfixes are not provided via website as described in the v11.02 readme, right ? That's a pitty.

HS2

PS: Thanks Johan for giving these useful hints. Added to my tuning list...

ScottW, VP of Dev

  • Senior Community Member
  • Posts: 1471
  • Hero Points: 64
Re: unhappier and unhappier with V11 :-(
« Reply #5 on: September 20, 2006, 06:28:40 pm »
Great thread!  Thanks for all the feedback. I'm sorry to hear that you've had so much trouble with this release.

First, let me say that no one has a greater passion for speed and performance than our founder and CTO, Clark Maurer. His vision drives everything we build.

As software engineers, you are aware that achieving proper performance involves trade-offs. You can choose to do less and do it quickly or do more and do it more slowly. This is particularly the case with tag lookups. Codebases today are larger than ever before. We consistently have to trade-off accuracy and completeness against responsiveness (see below for some specifics on how to better tune tag lookups).

We also see conflicting demands from our customers. This thread is an excellent example. greggman posts how distracting the new brace matching is and jbezem echos that about the completion pop-up. But there is also a request from greggman to add a feature that displays the line for a matched block in the message area (if it's not visible on the screen), which would surely reduce performance and add more distraction. What's a Product Manager to do?  :-\

Seriously, I love making these trade-offs and we do our best to add meaningful features that make a big difference in your daily coding. This isn't "feature-itis" but an attempt to move programming out of the dark ages, allowing programmers to focus on what the code should do while the editor handles the tedious, clerical aspects of coding. My favorite example of this is the new Comment Wrapping feature, which I consider the greatest advancement in code editing since auto-indent was introduced. I can't tell you how much time I've wasted in my career hand-formatting my comments, making a simple change that forced me to adjust the formatting in every subsequent line in the comment. As with any advance, we sometimes make mistakes. It could be that this is the cause of greggman's macro not performing well. greggman, please post your macro so we can try it and see what's going on.

Typically, the SlickEdit answer to these trade-offs is to provide our customers with the means to adapt SlickEdit to their needs and their preferences. So, we have oodles of configuration options. Some behaviors can only be changed by setting macro variables and occasionally, you have to modify macro code. Again, this is a matter of trade-offs between having even more configuration screens and checkboxes (ease of configuration) and keeping the UI as simple as possible. We evaluate each option and try to determine how likely it is that customers may need to change it and provide those that we think will benefit the majority of users.

Tuning Tag Lookups
First, select Tools > Options > General and then select the Virtual Memory tab. Increase the value for Tagging cache size from 32 megabytes to 64 or 128. You'll have to experiment with this value to find what works for your codebase. Generally, the larger your codebase, the larger this value should be. But remember, a larger cache doesn't always result in better performance. If you are consistently editing very large files, you may want to increase the Buffer cache size as well.

Next, go to Tools > Options > Tagging Options. Here you can configure specific maximums that control tag lookup. Reduce the values in the lower-right hand corner (except for Tagging cache size) to improve the responsiveness of lookups. Remember, this could prevent SlickEdit from displaying all tags.

If you are having performance problems, be sure to turn off "Background tag files", which should be off by default.

If you find Auto-completions to be distracting select Tools > Options > File Extension setup and select the Auto-Complete tab. Uncheck "Enable auto-completion". With this off, completions will work as they did in v10 and earlier, where you have to press a key to do the completions.

greggman, if you're seeing delays of 2 to 3 seconds, something else is probably going on. Please contact product support so we can try to figure out what's up. Include the information from Help > About SlickEdit as well as some details about your code: language, number of files, where files are stored(local | network) and any info you have that could help us narrow down the search. Is this happening with a particular type of tag?

The Wrap-up
OK, I think I hit the key points. Let me just add this: please don't wait to contact us until you have a bunch of issues and you're really upset. Post questions to the forums and we'll do our best to help you. Feel free to contact Product Support if you have issues. Even if you aren't paying for support, this is the best way to log an issue. If you're not getting satisfaction any other way contact me, Scott Westfall, at swestfall@slickedit.com.


greggman

  • Senior Community Member
  • Posts: 273
  • Hero Points: 13
Re: unhappier and unhappier with V11 :-(
« Reply #6 on: September 20, 2006, 08:21:59 pm »
thank you for both the "I feel your pain" responses as well as the actual customer service responses. I will try setting some of those things.

I wanted to make one comment which is that I don't feel the trade for paren matching is a valid argument. Why? Because as of about version 6 I wrote my own paren matching function that show the line just like emacs. They worked fast. The only problem was there wasn't enough hooks in slickedit to do them correctly so I had to busy wait inside a loop for a keypress to erase the highlight.

The point is, the do-it in the background and highlight later doesn't seem like a valid feature vs performance argument. Of course maybe my test cases are not hard enough to show where the trade off was needed.

Here's the macro

Code: [Select]
#include 'slick.sh'

const barlen=73;  // Length of comment bar without the leading '/' and closing '/'

void gat_insert_line(line)
{
   typeless old_indent

   old_indent = p_indent_style;
   p_indent_style = INDENT_NONE;

   keyin line
   split_insert_line();

   p_indent_style = old_indent;
}

// ;=====================================================================
// ;**
// ;** gat_insert_commentline (string)
// ;**
// ;**
gat_insert_commentline(str1)
{
   typeless head, pst, slen, numstars, numstarsleft, numstarsright;

   head = "/*";
   pst  = "*/";

   slen = length(str1);
   numstars = (barlen - 1 - 1 - slen - 1 - 1);
   numstarsleft = numstars intdiv 2;
   numstarsright = numstars - numstarsleft;
   gat_insert_line("");
   up;
   _begin_line();
   keyin head repeat_str('*',numstarsleft) ' ' str1 ' ' repeat_str('*',numstarsright) pst;
   down;
   _begin_line();
}

// ;=====================================================================
// ;**
// ;** gat_insertcurrent_commentline
// ;**
// ;**
_command gat_insertcurrent_commentline() name_info(','MARK_ARG2|TEXT_BOX_ARG2|EDITORCTL_ARG2)
{
   typeless str1;

   _begin_line();
   get_line(str1);

   if (length(str1) < (barlen-4))
   {
      _begin_line();
      _delete_line();
      gat_insert_commentline(str1);
   }
   else
   {
      message("line too long...");
   }
}

assign gat_insertcurrent_commentline() to a key. Go to a line. Type something like "hello" and then press the key you assigned. You should get

/********************************* hello *********************************/

It will take a noticably long time. In fact I put hello on the lines then pressed the key 10 times and it took about 20 seconds. In v1 -> v10 it would have taking 0.1 seconds

ScottW, VP of Dev

  • Senior Community Member
  • Posts: 1471
  • Hero Points: 64
Re: unhappier and unhappier with V11 :-(
« Reply #7 on: September 20, 2006, 10:47:25 pm »
I think the core of the slowdown relates to the use of "keyin" to enter the text. This could be engaging the comment wrap code, which may be trying to determine whether to wrap the text. Try using "insert_line()" instead:
Code: [Select]
   insert_line(head repeat_str('*',numstarsleft) ' ' str1 ' ' repeat_str('*',numstarsright) pst);

It may be that _insert_text better suits your intent. I couldn't get your example running so I couldn't see how it's supposed to behave. Is repeat_str one of your own functions? I couldn't find it anywhere in our API documentation or by using find-proc. So I used:
Code: [Select]
   if (length(str1)%2 == 1) {
      str1 = ' ' str1;
   }
   slen = length(str1);
   insert_line( head center(center(str1,slen+2), barlen-slen+2,'*') pst );

This would have to be tweaked depending on whether you want the comment to appear at the current indent level (insert_line versus _insert_text) and what the overall length of the comment should be (barlen-slen+2 made the comment 73 characters wide.

Bypassing "keyin" for this will definitely speed up this macro. I'll pass this along to the team to see if they can figure out why keyin is so slow. It probably has to do with the comment wrapping code.

--Scott


greggman

  • Senior Community Member
  • Posts: 273
  • Hero Points: 13
Re: unhappier and unhappier with V11 :-(
« Reply #8 on: September 21, 2006, 08:24:35 am »
thank you Scott.

That fixed it that one problem. I replaced all the keyins in my macros except for one. Maybe you can help

if I do an _insert_text("\t") I want it to insert tabs or spaces based on the config settings. I believe keyin does this. Since keyin is slow, is there another method for that.

As well keyin "\n" inserts the correct line ending. Does _insert_text("\n") add the correct line endings?

Oh, here's the missing function
Code: [Select]
typeless repeat_str(str,newlen)
{
    typeless i,newstr,newstrlen,strlen,sublen;

    strlen = length(str);
    if (strlen==0 || newlen <= 0) return "";
    newstr = "";
    lenrem = newlen;
    do {
        sublen = strlen;
        if (sublen > lenrem) sublen = lenrem;
        newstr = newstr:+substr(str,1,sublen);
        lenrem -= sublen;
    } while (lenrem);

    return newstr;
}

Another problem I'm having. Any file that is not loaded in Text SBCS/DBCS mode I can't edit in hex, I can't display tabs or new lines or special characters. Is this ever going to be fixed? It makes really annoying to try to edit Unicode or Japanese or other things I use on a daily basis.

greggman

  • Senior Community Member
  • Posts: 273
  • Hero Points: 13
Re: unhappier and unhappier with V11 :-(
« Reply #9 on: September 21, 2006, 10:16:18 am »
> def_match_paren_idle

Unfortunately setting it to 0 or 1 doesn't fix the problem. There is a clear and distracting lag between the time I move the cursor and the time the parens get highlighted.

I'd like to be even more pick here. I want them highlighted *my* way :-p  Maybe you could consider this for v12. The options needed are

1) when should slickedit highlight parens.  When the cursor is before the (ie, |{  after  {| and same on closing parens.  It gets worse with lisp where ((( ))). In fact slickedit v11 FAILS to highlight in that case.



1 = my cursor
2 = my custom solution highlighting the correct paren
3 = v11 highlighting the wrong thing.

2) how should it be highlighted. In my custom solution only the matching paren is highlighted. That's the only part I need to know since my cursor and hence my focus is already at the other paren. The fact the slickedit highlights both doesn't work well for me because now I get distracted when trying to figure out which is the matching paren and which is my cursor.  In other words before with my old custom solution the highlighted paren was NEVER where my cursor is. That made it instantly recognizable. Now with both highlighted I lose my place.

hs2

  • Senior Community Member
  • Posts: 2728
  • Hero Points: 282
Re: unhappier and unhappier with V11 :-(
« Reply #10 on: September 21, 2006, 11:07:23 am »
I can only give these 2 hints...

Quote
_insert_text("\t")
- use ptab();

Quote
_insert_text("\n")
- consider split_insert_line();
  b/c 'void _insert_text(_str string,boolean binary=false,_str newlineChars="\r\n");'
  allows you to specify your line endings

HS2

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 4079
  • Hero Points: 277
Re: unhappier and unhappier with V11 :-(
« Reply #11 on: September 21, 2006, 03:49:25 pm »
I'm looking at the emacs paren matching features.  How do you get emacs to shows the line that matched in the status bar with the match highlighted?

_insert_text("\n") will do what you want.   By default, newline characters in the input string are translated into the new line characters defined by the current buffer.

For everyone out there, don't use keyin() unless you absolutely want word wrap support.  keyin was and always will be MUCH SLOWER than _insert_text().  The documentation for keyin maybe does not emphasis this enough.  The new word wrap in comment feature added a lot more overhead to this already slow function.  The performance of keyin can't be improved that much.  Worse yet, keyin will overwrite characters when in replace mode.  This is rarely what you want in any macros you write.

Note that when you record a macro you get a lot of keyin() calls.  This is the correct code generation but I recommend that you translate the keyin calls to _insert_text() if you are unhappy with the performance.


Yes, like Scott said I'm a performance nut. 

Tagging performance:  It would be great if you could continue to type while the context information was being analyzed.  This would require a thread of course.  The most common delay I (and probably most users see) is the delay which occurs when initially reading the tag file data base.  To force the problem, reboot your system (this flushes the OS file cache), open slickEdit with a .java or .cpp file, and then try some context tagging.  We can't make this operation faster, but like I said above, it would be great if you could continue typing.

greggman

  • Senior Community Member
  • Posts: 273
  • Hero Points: 13
Re: unhappier and unhappier with V11 :-(
« Reply #12 on: September 21, 2006, 04:47:44 pm »
I'm looking at the emacs paren matching features.  How do you get emacs to shows the line that matched in the status bar with the match highlighted?

Run "emacs foo.cpp"

Enter
Code: [Select]
void foo (int x)
{

... 50 blank lines so that the lines above are off the screen

}

When you type the closing "}" you should see "matches void foo(int x) ... {" in the status bar.

Note that even the emacs method can be improved IMO. 

* In emacs it only shows the matching line when typing the closing paren. My custom slickedit solution shows it always when the cursor is after a closing paren.

* In emacs and in my custom solution it just shows the matching line and the line above or below if the opening or closing paren is on a line by itself. The improvement is if I could color code the line displayed in the status bar so it highlighted the specific paren. Since I couldn't do color I tried things like "void foo(int x) ... --> { <-- " but it was hard for my mind to parse it. Color would be better.

Dennis

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 2288
  • Hero Points: 295
Re: unhappier and unhappier with V11 :-(
« Reply #13 on: September 21, 2006, 06:31:48 pm »
FYI, I am adding an option (a def-var) to disable highlighting the item under the cursor, and made slight improvements to the responsiveness when you move the cursor away from a highlighted parenthesis.  This will be in 12.0, but the option will not exposed on the GUI (you'll have to set the def-var).

The reason that highlighting updates on a timer instead of immediately is simply for performance.  While usually not a consideration for C/C++, when you have a huge Ada or XML file open, finding the matching item can involve quite a bit of parsing.  Best not to do that on every keystroke.

With respect to the before the paren vs. after the paren issues, SlickEdit is relaxed about that so that find-matching-paren works consistently, and though some editors make a distinction, it shouldn't matter if your cursor is before the brace or after the brace, if you do find-matching-paren, it should go to the other brace.  The highlighting is 100% consistent with find-matching-paren, which it should be.

With respect to ((())) in Lisp (Fundamental mode), I can't reproduce this issue, the paren pairs ARE highlighted.  But then, you just said it "fails", which doesn't exactly tell me what you expected to happen vs. what really happened.

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 4079
  • Hero Points: 277
Re: unhappier and unhappier with V11 :-(
« Reply #14 on: September 21, 2006, 07:56:31 pm »
Thanks.  I didn't realize that emacs only displayed additional text when you type the close paren.  Emacs does not thread this operation.  Emacs does a poor job of choosing what to display.  If we did this, we would do better.  An option for when to highlight would be nice.  I would like the highlight to occur when I type an open or close paren immediately instead of having to wait.  SlickEdit's searching is plenty fast to do this.  Paren matching is a bit like the Enter key.  It needs a lot of good options since users expect different things to happen.

SlickEdit also matches #if/#elseif/#else.  Paste the code below into a .cpp file and see what happens.
#if 0
#elif 1
#elif 2
#else
#endif

Even cooler, press Ctrl+] (default binding for find_matching_paren) and SlickEdit will walk through the #if/#elif/#else/#endif.