insert_file_list() limited to 60 entries in 28.0.2 hotfix 19 ?

[rowbearto]

I'm using a macro that invokes insert_file_list(): https://github.com/rbresalier/sync_project_with_scm

In one case it passes to insert_file_list() 430 file specs such as "dir1/**/*.c;dir1/**/*.cc; etc"

I found that insert_file_list() seems to only take into account the first 60 file specs then ignores the remaining ones after 60.

If instead of calling insert_file_list() with 430 file specs I call it 7 times with 60 file specs and 1 time with 10 file specs then it adds all of them to the project.

Generating the project file with a previous version of SE/hotfix (don't know which previous version it was, but I had it stored in version control) didn't seem to have this issue and insert_file_list() was able to handle 430 file specs.

So was this changed to limit to 60 in version 28.0.2/hf19 or a version previous to it?

[Clark]

It would helpful if you could post the value of "cmd"

say('list:    'cmd);

It's probably best to post a file attachment with the value.

[Clark]

say() will clip the results but that's ok. ~5k should be more than enough for me to get the idea.

[rowbearto]

Followed your suggestion Clark to add say (I added dsay as I like looking at a log file).

From here I deduced the issue is not in insert_file_list(), my macro is passing it something that is already truncated to 2000 characters.

The macro takes in a text file with information about what to add to the project and in Slick-C reads it line by line.

The problem is that when it calls get_line() the resulting line is truncated to 2000 characters while the actual line is much longer than 2000 characters.

Maybe you can offer a suggestion how I can handle this.

The particular get_line() that the macro calls can be seen in github here:

https://github.com/rbresalier/sync_project_with_scm/blob/master/sync_project_with_scm.e#L596

The .ini file with the specification of all wildcard files to add to the project is in a .ini file. This ini file is loaded into a buffer in SlickEdit. Then get_line() is executed to read it line by line. But it can only handle 2000 characters on a line.

I need to think about how to modify to handle something like this and your insight would be real useful.

Is there a way for this macro to load the buffer without this 2000 character limitation?

[rowbearto]

I think the 2000 limit is because I have this in my initial SE configuration setup:

Code: [Select]

   // See: https://community.slickedit.com/index.php/topic,15914.0.html - originally put
   // it at 8000.
   // But then see: https://community.slickedit.com/index.php/topic,16732.0.html, putting
   // back to 2000
   _default_option(VSOPTION_FORCE_WRAP_LINE_LEN, 2000);


[rowbearto]

I think file is loaded into Slickedit buffer using _create_temp_view() and get():

https://github.com/rbresalier/sync_project_with_scm/blob/master/sync_project_with_scm.e#L781

Code: [Select]

      int idOrig = _create_temp_view(idTmp);
      if(idOrig == '')
      {
         _message_box("Error creating temp view of ini file.");
         return false;
      }
      s_idIni = idTmp;
      get(iniFile);

[Clark]

get_line() will only get the current line which will only be a partial line if it got split into multiple lines.
You either need to use a larger FORCE_WRAP_LINE_LEN or check the _lineflags()&VSLF_EOL_MISSING and fetch multiple lines if necessary.

[rowbearto]

Thanks for the hint Clark! Using _lineflags()&VSLF_EOL_MISSING seems like the most robust way.

I changed it to the below. It seems to be working well. Do you see any issues with it?

Code: [Select]

      bool getNextLine = true;
      line = "";
      while ( getNextLine )
      {
         _str linePortion;
         get_line(linePortion);
         line = line linePortion;
         if ( _lineflags()&VSLF_EOL_MISSING )
         {
            getNextLine = true;
         }
         else
         {
            getNextLine = false;
         }
      }


[Clark]

That should do the trick

[rowbearto]

Thanks Clark. I tried turning this into a function, which works only if I have the 'dsay()' statement in it (after the get_line() in the below code).

When I take out the dsay() I think it is in an infinite loop as 'top' shows vs_exe using 100% CPU and SlickEdit is stuck.

But when have dsay() there it functions properly.

I'm using 28.0.2 hotfix 19 on Linux x64.

Any ideas?

Code: [Select]

// Reads a line from the current document and takes into account if the line
// is getting wrapped, it will get the full line including all the wraps.
// See: https://community.slickedit.com/index.php?topic=19548.new;topicseen#new
static _str get_full_line()
{
   bool getNextLine = true;
   _str line = "";
   while ( getNextLine )
   {
      _str linePortion;
      get_line(linePortion);
      dsay("Undo debug, linePortion: " linePortion);
      line = line linePortion;
      if ( _lineflags()&VSLF_EOL_MISSING )
      {
         getNextLine = true;
      }
      else
      {
         getNextLine = false;
      }
   }
   return line;
}

[rowbearto]

I changed the order of things in function (moving the concatenation of line and linePortion to after determining getNextLine()), commented out the dsay and now it doesn't get stuck.

But I don't have an explanation for why my first attempt got stuck?

Any ideas?

Here it is with the order changed:

Code: [Select]

// Reads a line from the current document and takes into account if the line
// is getting wrapped, it will get the full line including all the wraps.
// See: https://community.slickedit.com/index.php?topic=19548.new;topicseen#new
static _str get_full_line()
{
   bool getNextLine = true;
   _str line = "";
   while ( getNextLine )
   {
      _str linePortion;
      get_line(linePortion);
      // dsay("linePortion: " linePortion);
      if ( _lineflags()&VSLF_EOL_MISSING )
      {
         getNextLine = true;
      }
      else
      {
         getNextLine = false;
      }
      line = line linePortion;
   }
   return line;
}

[Clark]

Looks to me like both of your functions should get stuck. I'm not seeing a call to down in either of your loops. Make sure to check the status of down() and break the loop.

[rowbearto]

Thanks Clark, using down() made the difference!

Below is my function now, appreciate any comments you have on it.

It no longer gets stuck regardless of whether or not the dsay() are commented out.

Code: [Select]

// Reads a line from the current document and takes into account if the line
// is getting wrapped, it will get the full line including all the wraps.
// See: https://community.slickedit.com/index.php?topic=19548.new;topicseen#new
static _str get_full_line()
{
   _str line = "";
   while ( true )
   {
      _str linePortion;
      get_line(linePortion);
      dsay("linePortion: " linePortion);
      line = line linePortion;
      if ( !(_lineflags()&VSLF_EOL_MISSING ))
      {
         // This is the end of the line, it is no longer wrapped or truncated, so return it
         // Caller is responsible for calling down() to advance to next line.
         return line;
      }
      // Being here means that get_line() didn't read the full line, it wrapped it to
      // the next line in the editor, so we will need to read the next line.
      dsay("not end of line");
      // Call down() to go to the next line.
      if (down())
      {
         // This means we got to the end of the file
         return line;
      }
   }
   // Should never reach here.
   return line;
}

[Clark]

That looks much better