Author Topic: how to stop truncation in search results  (Read 1018 times)

Graeme

  • Senior Community Member
  • Posts: 2716
  • Hero Points: 337
how to stop truncation in search results
« on: February 20, 2020, 05:36:45 am »
I've just started using 24.0.1 on Win 10.  How do you stop slick from truncating lines in search results?  I've tried max-length 500 and "truncated search result width" to 100  - doesn't work.  Both zero doesn't work.  Max length zero, truncated width 100 doesn't work.  An option to stop all truncation would be good and a right click option in search results to kill truncation would be good too.

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 6271
  • Hero Points: 484
Re: how to stop truncation in search results
« Reply #1 on: February 20, 2020, 01:52:08 pm »
The problem is that the options you are setting don't take effect unless the configuration is saved. Restarting SlickEdit will do the trick or "save_config".

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 6271
  • Hero Points: 484
Re: how to stop truncation in search results
« Reply #2 on: February 20, 2020, 09:41:29 pm »
Sorry. I accidentally deleted our post. Meant to hit reply. For these options, SlickEdit could just ignore when you want your configuration saved and just immediately save it anyway.

Graeme

  • Senior Community Member
  • Posts: 2716
  • Hero Points: 337
Re: how to stop truncation in search results
« Reply #3 on: February 20, 2020, 10:20:34 pm »
ok, that would be fine.  I think I'll enable auto config save anyway.

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 6271
  • Hero Points: 484
Re: how to stop truncation in search results
« Reply #4 on: February 20, 2020, 10:59:26 pm »
The easier fix is for us to simply save any configuration changes before running sgrep. SlickEdit runs a separate process (sgrep) when doing a multi-file search. That separate process reads the saved config information to determine all kinds of settings.

For v25, we improved sgrep in many ways. When used for a SlickEdit multi-file search, you will be able to specify the number of threads. The default number of threads has been increased from 4 to 8 (helps a ton on newer CPUs with 8 cores). Stand alone sgrep will support color escape output when run in the process buffer. Stand alone sgrep will support threading and specifying the number of threads. I mostly use sgrep for multi-file searching and it was too slow without the threading. Stand alone sgrep will support options for truncation and line length. Stand alone sgrep will have support for file encodings (Autounicode2 by default for all files). Stand alone sgrep will be a little faster than SlickEdit's multi-file search which is quite fast. Stand alone sgrep still will not have support for color coding like SlickEdit's multi-file search. That's because we don't want stand alone sgrep to require all the SlickEdit language configuration stuff needed for color coding, improved encoding processing, and tab settings. I typically just copy sgrep and sgrep.vsb to a "bin" location in my path.

Graeme

  • Senior Community Member
  • Posts: 2716
  • Hero Points: 337
Re: how to stop truncation in search results
« Reply #5 on: February 21, 2020, 02:28:50 am »
ok, any fix is fine.

I've been switching to a new PC due to Win 7 demise.  Yesterday I learnt from a co-worker that when you're using robocopy to copy files across a LAN, you can specify number of threads to use as say 64, it runs around 64 times faster than Windows explorer, even though the machine has only six cores.

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 6271
  • Hero Points: 484
Re: how to stop truncation in search results
« Reply #6 on: February 21, 2020, 02:39:20 am »
I'm not seeing that kind of benefit with more threads with multi-file searching performance. It probably depends on where the bottle necks are. My primary machine (Linux) has 8 cores (NVME drive) and multi-file searches are a little more than twice as fast with 8 threads vs 4. My Windows machine only has 4 cores. It only gets a descent percentage boost with 8 threads (I forgot what it was). Going higher than 8 threads on my 4 core machine helps so little that there isn't much point. 16 threads might help with my 8 core machine but I haven't tested it.