Recent Posts

1

SlickEdit® / Re: Bash Debug

« Last post by pbrightly on Today at 02:57:14 pm »

Well, since Slick is my first love.. I want to wean myself off VSCode.  That's where I got the idea. I've recently remote-debugged bash in a plugin ("Bash Debug") that provides source-debugging like any other language, using bashdb under the covers.  No more stupid unreadable +x output.  It was...euphoric.   

2

SlickEdit® / Re: Is it possible to use WSL as my Build terminal instead of cmd.exe?

« Last post by pbrightly on Today at 02:52:10 pm »

Interesting. A little disappointing, but perhaps there are some things I could do.  For instance, you gave me an idea for running my bash scripts.  I added another custom tool to the build config called "Exec Bash".  Non of the %* vars worked to let me expand the directory properly.  But if I hardcoded the WSL path (which is identical to windows path with forward slashes), I got it to run.
Using the normal expanding variables in the config, it fails:

Code: [Select]

C:\sandbox\integration-testing> VSLICKERRORPATH="C:\sandbox\integration-testing"
wsl bash ./deploy_server_base.sh
bash: ./deploy_server_base.sh: No such file or directory
Hardcoding the path and passing it to "wsl bash":

Code: [Select]

C:\sandbox\integration-testing>set PATH=C:\Python3;C:\SlickEdit2020\win;C:\Python3\Scripts\;C:\Python3\;C:\SlickEdit2020\win\;c:\java8\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\Plantronics\Spokes3G\;C:\Program Files\Cloud Foundry;C:\Program Files\PuTTY\;C:\Program Files\IBM\Cloud\bin;C:\Program Files\Intel\WiFi\bin\;C:\Program Files\Common Files\Intel\WirelessCommon\;C:\VSCode\bin;c:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL;c:\Program Files\Intel\Intel(R) Management Engine Components\DAL;C:\Git\cmd;C:\Git\mingw64\bin;C:\Git\usr\bin;C:\Program Files (x86)\Sennheiser\SenncomSDK\;C:\Program Files\Docker\Docker\resources\bin;C:\ProgramData\DockerDesktop\version-bin;c:\cmd;c:\tools;c:\slickedit2008\win;C:\Program Files\Docker Toolbox;C:\Users\PaulBrightly\AppData\Roaming\Dashlane\6.1907.0.17833\bin\Firefox_Extension\{442718d9-475e-452a-b3e1-fb1ee16b8e9f}\components;C:\Users\PaulBrightly\AppData\Roaming\Dashlane\6.1907.0.17833\ucrt;C:\Users\PaulBrightly\AppData\Roaming\Dashlane\6.1907.0.17833\bin\Qt;C:\Users\PaulBrightly\AppData\Roaming\Dashlane\6.1907.0.17833\bin\Ssl;C:\Users\PaulBrightly\AppData\Roaming\npm;C:\Users\PaulBrightly\AppData\Local\Microsoft\WindowsApps;C:\Users\PaulBrightly\AppData\Local\Box\Box Edit\
C:\SlickEdit2020\win\vsbuild -signal 60889 -command wsl bash /sandbox/integration-testing/tools/bin/deploy_server_base.sh

C:\sandbox\integration-testing> VSLICKERRORPATH="C:\sandbox\integration-testing"
wsl bash /sandbox/integration-testing/tools/bin/deploy_server_base.sh

-------------------------------------------
--- deploy_server_base.sh
-------------------------------------------
(that banner is all the script output for now)

Windows has no problem with using forward slashes in double quoted pathnames or in api calls.  It's parsing on the windows command line that gets you in trouble.  That being the case... perhaps "some" form of support could work here. At least in the case I show above.  I'd like to explore it.

On running the linux version "in WSL".. I'm not a big fan of running X when I've got a nifty windows app. I'd do it for a superior debug experience, but I'm on a shared license for both Win & MacOS, so... I can't in any case.
(assuming the windows license doesn't work for linux in WSL on same box??)

3

SlickEdit® / Re: Bash Debug

« Last post by patrick on Today at 02:31:20 pm »

AFAIK, we haven't.  Bashdb was definitely under my radar.  I'll go ahead open a feature request for it.

Unfortunately, I don't think its use of gdb command syntax gives us a leg up given that we already support gdb.  For our gdb debugging support, we use the -mi machine interface commands, whose syntax is different, and not made for interactive use by people.

4

SlickEdit® / Re: Is it possible to use WSL as my Build terminal instead of cmd.exe?

« Last post by patrick on Today at 02:14:10 pm »

It looks like on windows the build shell is constrained to be cmd.exe.

SlickEdit doesn't have built in logic to deal the logical boundary between the Windows environment and WSL. (or any other type of hosted VM). So while you can slightly cheese it by doing something like "wsl.exe python3 /some/py.file" to run python under WSL, when SlickEdit needs to expand paths for project tools, set the working directory, etc..., they're going to be windows format paths, and not unix paths that reference the mount layout of your WSL setup.   So that will break a lot of things. 

As a short example: you run a python program with that wsl.exe command, and there's a syntax error.   You hit your keybinding to go to next-error, and at best you get prompted for the source file location, because it will try to interpret the source file in the error message as a windows path.

As far as debugging python goes, I think the path issues would make it so you can't start debugging the program by hitting F5.   If you can make TCP connections from the windows side into the WSL side, then you could treat it as the remote debugging case which is described in the manual.

While it's possible to go from the other direction and run SlickEdit on the WSL side (if you have an XServer running in windows), it's not a configuration we test with.  We know some customers have done it, and reported some windows not giving focus to the right control when it comes up.  (not super surprising, we have seen similar with less common window managers on Linux).   Microsoft is going to be providing a XWindows server for WSL that can support graphics acceleration, it's in preview now.  I am interested in seeing how we work with that, but I can't predict if it's a configuration we'll test with or not.

5

SlickEdit® / Is it possible to use WSL as my Build terminal instead of cmd.exe?

« Last post by pbrightly on Today at 01:40:58 am »

I've been on Windows since they ditched OS/2.  Ironically, most of my work is on linux hosts using mostly bash and python.  When MS created WSL, I became a very happy man.  I can't tell I'm not on native Ubuntu.  So I (mostly) ditched cmd.exe as well.

My development environment shares a filesystem between Windows and WSL-Ubuntu.  I run all my GUI apps, including Slick on the Windows apps.  I do all command line work in Ubuntu (a significant amount).

I'd MUCH prefer to debug my python & bash within Slick.  Is there a way to configure the Build window to use WSL instead of bash?  Can I setup my project tools to call things installed in WSL?  That's where I work.

If I can't do that....can I setup remote debug against localhost to get at WSL?

Again..I've been editing with SlickEdit for years, on the windows side.  The filesystem is shared, so I can run (and edit) things in WSL fine. They work well together.

PS. I'm new to SE2020. I'd been using 2008 since it was new.  Very happy to see a python debugger.

6

SlickEdit® / Python configuration not intuitive

« Last post by pbrightly on Today at 01:28:14 am »

This may simply be because I haven't been using projects in Slick for years, but I'll give the feedback anyway.
Setting up a python project, I noticed a bad default for my interpreter was set.. I'd uninstalled it to get a newer version.  I couldn't for the life of me find where to correct the interpreter pathname for a while. I found it in my project, but it would be very nice if (for something so common as primary system tools), I could find that setting when I look at Tools->options and search on "python".  There's a whole subtree for python stuff -- no binaries.  It'd be nice if pyenv versions were detected as well and perhaps I could be offered a list to choose from.

PS. It's buried in project properties->Tools->Execute->Options, then at the bottom of the dialog.  I kept missing it because all settings are near the top, while the interpreter is down by the OK button.  Eyes are drawn away from it.

PPS. Before I found it in the GUI, I followed the bunny trail of seeing SLICKEDIT_PYTHON_EXE in project setup.  In the help system, I found the actual variable, so I I fixed it with:
set-var def_python_exe_path

7

SlickEdit® / Bash Debug

« Last post by pbrightly on Today at 01:14:11 am »

Has anyone looked at how one would debug bash scripts in SlickEdit?  I think there's wrappers to bashdb and it would be awesome to see source-level debug for bash, like we have for other languages like python.

8

Features and/or Improvements / Find-and-Replace with Preview All highlights

« Last post by jporkkahtc on May 06, 2021, 10:23:59 pm »

When previewing F&R changes I'd like the Diff window to highlight the entire match and replace string.
Currently, it only shows the actual difference.


A simple example:  Replace "Anything" with "Anyone"
(Real world examples in code are often more confusing).
The highlights:
sample text Anything  more stuff  ---->   sample text Anyone  more stuff

But, I would like:
sample text Anything more stuff   ---->   sample text Anyone more stuff

9

SlickEdit® / Edited menu reverts to default

« Last post by jnairb on May 06, 2021, 10:19:23 pm »

I have edited the _mdi_menu to change the hotkey for the Tools menu to 'o' (changed Caption from &Tools to T&ools). My normal SlickEdit session does let me use Alt, O to open this menu. I just noticed when I open a new SlickEdit instance from the Organize All Workspaces/New Instance button, the Tools menu reverts to the default 't' hotkey.

I tried to reproduce this behavior starting from the default config, but when I start with a default config and edit the _mdi_menu to change &Tools to T&ools, the menu does not change. The change is saved to the userMenus.xml file though. Perhaps both of these issues are the same?

I'm running SlickEdit 25.0.1 (with hotfix_se2501_6...) on Windows 10.

10

SlickEdit® / Re: Options in Linux VM, Apply button off-screen

« Last post by Clark on May 05, 2021, 08:50:32 pm »

1920x1080 is usually plenty big enough. However, Linux seems to have problems with DPI. SlickEdit may be scaling due to the DPI which we've found on Linux can be way off. Reducing the dialog font is a good work around.