Recent Posts

Pages: [1] 2 3 ... 10
1
SlickEdit® / Re: Window grays out and is unresponsive for many seconds
« Last post by patrick on May 20, 2019, 09:33:03 pm »
Had you just done a references search before it grayed out, or you were just moving through the file when it happened?

At first glance, it's largely tagging lookups. The large amount of time and the fact that it's blocking the gui thread are strange.  I think we've already gotten the usual information we'd usually collect for something like this.  You have a few files that are local to your system and not on a network drive.  It happens in just one of the files, and you said the file isn't that large. 
 
I still have some things to look at here.  We may be able to use the linux "perf" command to get a profile of what's going on at a lower, native level when it hangs up like that.  I'll update the thread with instructions if it comes to that.



2
SlickEdit® / Re: C++17 inline variables defeat goto definition
« Last post by Dennis on May 20, 2019, 08:30:50 pm »
Fixed for the next release.  This sort of parsing bug is not hot-fixable.  Thanks for pointing this one out.
3
SlickEdit® / Re: Window grays out and is unresponsive for many seconds
« Last post by lahughes on May 20, 2019, 07:35:00 pm »
Here you go. It ran for about 5 minutes before graying out. It was unusable for about 5 minutes before coming back. I've attached the output from the macro as well as the vrestore.slk file.
4
SlickEdit® / Re: Window grays out and is unresponsive for many seconds
« Last post by patrick on May 20, 2019, 07:27:59 pm »
Actually, one more thing.  Can you post the vrestore.slk file from your configuration directory?  (Unless you're overriding it at the command line, that would be  $HOME/.slickedit/23.0.1/vrestore.slk).
5
SlickEdit® / Re: Window grays out and is unresponsive for many seconds
« Last post by patrick on May 20, 2019, 07:05:49 pm »
If you think you can capture the profile in a relatively short amount of time, then go ahead.  If you get it to happen with the profiling, post it and let me know roughly how long it was running.

The Qt thing with the messages is something I need to look at, but I think is separate from the pausing, since turning off the system menu integration doesn't change the delays you're seeing.
6
SlickEdit® / Re: Window grays out and is unresponsive for many seconds
« Last post by lahughes on May 20, 2019, 05:27:08 pm »
Should I try to get the macro going again? Today seems to be day when it is graying out frequently.

I looked up QT (I am unfamiliar with it) and it is supported on Ubuntu 16.04.
7
SlickEdit® / Re: C++17 inline variables defeat goto definition
« Last post by Dennis on May 20, 2019, 02:20:45 pm »
Will try to patch this up for the next build.  I have to say, this is a really asinine syntax for what it is trying to accomplish.
8
SlickEdit® / Re: Keywords Missing after added
« Last post by SlickEdit Support on May 20, 2019, 01:28:38 pm »
The easiest way to virtually guarantee this won't again, even though he's always hitting Apply and OK in that dialog is to exit SlickEdit. This will save all of the settings to the user configuration directory.

Alternatively, if you don't want to exit you can simply run the command "save-config" (no quotes) from the SlickEdit command line (the command line can be accessed by hitting Escape in most emulations or simply clicking on the message area in the bottom left corner of the main SlickEdit application window).

And lastly, you can always contact us via www.slickedit.com/supportcase

Best,
SlickEdit Support
9
SlickEdit® / C++17 inline variables defeat goto definition
« Last post by Graeme on May 18, 2019, 11:20:14 pm »
C++17 supports inline variables which allows you to put the definition of a variable in a header file without violating the one definition rule.  I have the code below in a header file.  When I use Ctrl-dot for the word mui_table_info in a C++ file, slick is unable to find the definition.
Using v23.0.1.2 64-bit no hotfixes.

Code: [Select]
inline const struct
{
   int      offset;      // byte offset into zone_image struct
   int      len;         // fixed length in bytes if positive, else enum type_e
   int      source;      // identifies where the data is to be copied *from*
   uchar    data_type;
}
mui_table_info[] =
{ {1,2,3,4}};
10
Features and/or Improvements / Custom colours
« Last post by dunkers on May 18, 2019, 09:07:19 pm »
I know this has been kind of asked for before, but not quite like this...

Currently I am colouring build output using ANSI escape characters and, of course, the build window doesn't show these. I have set up the 'process' language to see the ANSI sequences as tokens, and now the stuff between the sequences is coloured. Yay!

But... they're the wrong colours. I want OK to be green and ERROR to be red, and the only way I've found to do this so far is to define [32;1m as a comment, and [31;1m as a number (I am using the light watercolours profile). Works,  but...

Obviously, if I change my colour scheme the colouring of the build window will change too. So, how about additional colour tags for specific colours? That is, instead of using the attribute 'comment' to get green, there is a specific attribute called 'green' that can be defined as green. Easy peasy, no? Takes no work for you SE folks (other than to add the primary colour names, or maybe just 'color1', etc., and the user can make them show what they want to show. Changing colour profile would then keep absolute colours the same with no effort.

[After this, just need a simple way to consume the ANSI sequences so they disappear from the window but still get to trigger the colours.]

Edit: Sorry! Moved here from the general topic.
Pages: [1] 2 3 ... 10