convert tabs to spaces not working in comments

[LBCEi]

When I run the convert-tabs2spaces command (either with the toolbar button or via the command line), SE seems to ignore tabs that are in comments. 

I am running SlickEdit Pro 2018 (v23.0.1.2 64-bit) with hotfixes 1 and 2 installed.

Any idea what is going on and how to remedy this?

Thanks

[Lee]

I just tested with a clean config, and I don't see anything obviously wrong in any samples.  Is there a sample you could submit where it is failing?  May need to get a copy of your configuration directory, or at the very least your user.cfg.xml from your configuration to help with this.

[LBCEi]

Probably relevant:

This is a simple text file that we use to configure one of our products.  I've set the document mode to Makefile as that allows coloring lines that start with # as comments.  That is what we decided to use as a comment character for this custom file format.  Of course, Makefiles normally need to have actual tabs instead of spaces and that is why I keep using the convert-tabs2spaces command as our file parser doesn't like tabs.  We probably should choose an extension other than .txt so that I can define settings for that specific extension.

Nevertheless, it still seems odd that the convert-tabs2spaces command doesn't do it's job within comments.

Regards,
Les

BTW: is there any way to change my user name in the forum without losing my history (previous posts, etc.)

[Graeme]

Looks like a forum admin could do it for you
https://wiki.simplemachines.org/smf/How_to_change_your_username

[LBCEi]

I think this is related to another odd behavior where the tab size changes to one in really long lines.
Steps to reproduce:

• Create a new document and set the document mode to Makefile
• Type a # in column one.
• Repeatedly press tab.  At around column 250 the tab size will change to one.  Press tab several more times and then type any character to end the line.
• Select the line you just created and issue the convert-tabs2spaces command.

The normal width tabs will be converted to spaces but the 1 space tabs will not (at least not all of them).

This reproduces with a clean config.

[Lee]

There is a limit on tab expansion, and the default starts at 256 columns. I thought it had been documented somewhere, but I can't find it in any obvious places in the help.  There is not a direct way to configure this through Tools > Options, but it can be overridden via macro.  For example, to change the expansion limit to column 512

Code: [Select]

#pragma option(pedantic,on)
#include "slick.sh"

defload() {
   _default_option('G', 512);
}

Save and load the above macro code, and then restart SlickEdit.

[LBCEi]

Lee

I tried the macro and, after restarting SE, it seems to take care of both issues.

Thanks,
Les

[LBCEi]

I'm still concerned about why there would be a limit on either inserting tabs using the current tab length or replacing them with spaces beyond a certain column position.  The first seems, to me, to be the most concerning.  The tab width should be the tab width, period, full stop. Nothing should change that.  Switching to a tab width of one at some hard to discover column position makes no sense whatsoever (as far as I can tell).  If I am mistaken, please explain.

Thanks
Les

[Lee]

Definitely understand your concerns. I will have to look into the convert tabs to spaces to make sure it working correctly for long lines.  The max tab expansion limit does affect how we compute the virtual column position for long lines. There are historical reasons, mostly for performance and memory limitations from an earlier computing era.  SlickEdit now supports larger files and larger line sizes than those early releases, so this is something that needs to be re-evaluated. The existing default is probably too conservative for modern use, and we need to make sure this is something that is documented better and at the very least better configurable.