SciTE 5.2.3 released

[Neil Hodgson]

SciTE 5.2.3 is now available from the scintilla.org web site. It uses Lexilla 5.1.7 and Scintilla 5.2.3.

This is a moderate bug fix release.

On GTK with Xorg, fix partial updates and non-responsive scroll bars.

On Windows, fix hang with file on UNC share.

Lexers improved for CMake, HTML, Matlab, Raku, Ruby, and VHDL languages.

A detailed list of changes is available on the history page.
https://www.scintilla.org/SciTEHistory.html

SciTE uses Mercurial (Hg) and Git for source code control. The repositories can be cloned with
git clone https://github.com/ScintillaOrg/lexilla
hg clone http://hg.code.sf.net/p/scintilla/code
hg clone http://hg.code.sf.net/p/scintilla/scite

Downloads:
https://www.scintilla.org/SciTEDownload.html

There will be a commercial macOS release of SciTE shortly.

Thanks to the contributors of code and documentation and to the testers.

Neil

[Neil Hodgson]

Me:

> There will be a commercial macOS release of SciTE shortly.

Apple has been very slow with processing this release of SciTE. It's been over a week and hasn’t been approved yet. For the past couple of years approval time has been measured in hours, not days. Maybe this is something to do with next week's conference.

Neil

[Philippe Lhoste]

Le 22/05/2022 à 03:37, Neil Hodgson a écrit :
> SciTE 5.2.3 is now available from the scintilla.org web site. It uses Lexilla 5.1.7 and Scintilla 5.2.3.

Hello

I didn't upgrade for a long while, so I jumped from v. 4.x to this version.
If that's relevant, I have the installation folder with all settings
(direct unzip of the archive) in a Dropbox folder, path
D:\Dropbox\Applications\SciTE\.

My SciTEUser.properties file is very simple:

import PhiLho/SciTEUser

Of course, in this referenced file, I have all my personal settings,
overriding the global ones.

But it seems that SciTE doesn't understand this statement, which was
working in the v. 4 version. I looked at the manual, 'import' section,
and saw no relevant change.
SciTE loads the above SciTEUser file, so the settings path is OK (set in
the environment variable).

What I am missing?

--
Philippe Lhoste
-- (near) Paris -- France
-- http://PhiLhoSoft.github.io/about/
-- -- -- -- -- -- -- -- -- -- -- -- -- --

[Neil Hodgson]

Hi Philippe,

> I didn't upgrade for a long while, so I jumped from v. 4.x to this version.
> If that's relevant, I have the installation folder with all settings (direct unzip of the archive) in a Dropbox folder, path D:\Dropbox\Applications\SciTE\.
>
> My SciTEUser.properties file is very simple:

So this is in your USERPROFILE directory? For me that is “C:\Users\Neil\SciTEUser.properties”.

> import PhiLho/SciTEUser

This should be in a subdirectory of USERPROFILE so “C:\Users\Philippe\PhiLho\SciTEUser.properties”.

Is this a case where your profile name is also “PhiLho” and you are expecting it to be one directory up?

I recreated this situation, copying a SciTE download to "D:” (but not inside DropBox) then placing “caret.width=3” in “C:\Users\Neil\PhiLho\SciTEUser.properties” and added "import PhiLho/SciTEUser” and I’m seeing a wide caret.

> What I am missing?

Try a restart. Check for extraneous whitespace or other issues on the import statement. Check that your SciTEUser.properties is active: set caret.fore=#FF00FF immediately after the import.

Neil

[Philippe Lhoste]

Le 09/07/2022 à 04:35, 'Neil Hodgson' via scite-interest a écrit :
> Hi Philippe,
>
>> I didn't upgrade for a long while, so I jumped from v. 4.x to this version.
>> If that's relevant, I have the installation folder with all settings (direct unzip of the archive) in a Dropbox folder, path D:\Dropbox\Applications\SciTE\.
>>
>> My SciTEUser.properties file is very simple:
>
> So this is in your USERPROFILE directory? For me that is “C:\Users\Neil\SciTEUser.properties”.
>
>> import PhiLho/SciTEUser
>
> This should be in a subdirectory of USERPROFILE so “C:\Users\Philippe\PhiLho\SciTEUser.properties”.
>
> Is this a case where your profile name is also “PhiLho” and you are expecting it to be one directory up?
>
> I recreated this situation, copying a SciTE download to "D:” (but not inside DropBox) then placing “caret.width=3” in “C:\Users\Neil\PhiLho\SciTEUser.properties” and added "import PhiLho/SciTEUser” and I’m seeing a wide caret.
>

Note that I didn't change any setting yet.
My settings files are in the path I have set in SciTE_HOME
(D:\Dropbox\Applications\SciTE).
I checked the doc, it should still work as before, for global and user
settings.

SciTE.properties and SciTEUser.properties are on the same folder (in the
dropbox, as said earlier), the latter having only the line indicated
below, to redirect to the real SciTEUser file, one folder below.
When I load the user properties files (using the dedicated menu), it
loads the one with the import statement, so it should be OK.

But to be sure, I set the SciTE_USERHOME as well, pointing to
D:\Dropbox\Applications\SciTE\PhiLho.

And… it worked!

And it is more logical, eliminating a file and a redirection. But
needing an extra settings. Not a big problem.

But it seems there is a regression somewhere, with regard to what is
written in the doc, no?

Anyway, thanks for the help.

[Neil Hodgson]

Philippe Lhoste:

> Note that I didn't change any setting yet.
> My settings files are in the path I have set in SciTE_HOME (D:\Dropbox\Applications\SciTE).
> I checked the doc, it should still work as before, for global and user settings.

Trying it out for myself.
Put Sc524.exe in D:\usr along with a SciTEUser.properties that included “import PhiLho/SciTEUser”
Put “caret.fore=#00A090” in D:\usr\PhiLho\SciTEUser.properties
Set SciTE_HOME=D:\usr using Settings | Type env | Edit the system environment variables.
Double click on Sc524.exe and there is a cyan caret.
The Options menu contains a last item: Open PhiLho/SciTEUser.properties

> SciTE.properties and SciTEUser.properties are on the same folder (in the dropbox, as said earlier), the latter having only the line indicated below, to redirect to the real SciTEUser file, one folder below.
> When I load the user properties files (using the dedicated menu), it loads the one with the import statement, so it should be OK.
>
> But to be sure, I set the SciTE_USERHOME as well, pointing to D:\Dropbox\Applications\SciTE\PhiLho.

SciTE_USERHOME takes priority.

FilePath SciTEWin::GetSciteUserHome() {
// First looking for environment variable $SciTE_USERHOME
// to set SciteUserHome. If not present we look for $SciTE_HOME
// then defaulting to $USERPROFILE
GUI::gui_char *home = _wgetenv(GUI_TEXT("SciTE_USERHOME"));
if (!home) {
home = _wgetenv(GUI_TEXT("SciTE_HOME"));
if (!home) {
home = _wgetenv(GUI_TEXT("USERPROFILE"));
}
}
return GetSciTEPath(home);
}

This code, and GetSciTEPath don’t appear to have changed since 2016.

Is your D:\Dropbox a normal on-disk directory or is it under control of a file system driver to give the illusion of files being present before they are actually downloaded?

There can be issues about when you set SciTE_HOME and having running programs (like Command Prompt) that don’t pick up the new value until they are restarted.

Reading user properties actually occurs twice at startup (in ReadGlobalPropFiles) to allow setting “imports.include” or “imports.exclude” in user properties and have those settings effect global and user properties.

There could be a regression somewhere but its not obvious on my setup.

Neil

[Philippe Lhoste]

OK.
If I am the only one with this issue, and since I solved it with a
workaround (or the proper solution!), you can close the case… 🙂

But for the record, this setup worked in v. 4, and was broken in v. 5,
on both my home computer and the work computer, which share the config
via the dropbox (different path on the work computer).

Thank you for your time.

[Neil Hodgson]

Philippe:

If I am the only one with this issue, and since I solved it with a workaround (or the proper solution!), you can close the case… 🙂

   Its worthwhile reporting it - maybe there is some aspect of our setups that cause a divergence.

   There was a problem with network shares reported at https://sourceforge.net/p/scintilla/bugs/2326/ which became a problem when the RelativePath property was implemented. Your problem could also be due to a similar file system / path issue.

   Neil

[Philippe Lhoste]

Actually, it isn't totally solved.

All my imports inside the SciTEUser file are broken.

For example, I had an import PhiLho/SciTEUser_window line which doesn't
work.
(It just sets position.xxx properties, it was supposed to vary with
computer, I planned to use it as import $(USERPROFILE)/SciTEUser_window
but it didn't work.)

I changed it to:
import SciTEUser_window
import $(SciteDefaultHome)/PhiLho/SciTEUser_window
import $(SciteUserHome)/SciTEUser_window
import $(SciteDefaultHome)/SciTEUser_window
import $(SciteUserHome)/PhiLho/SciTEUser_window
without success (some combinations being illogical, but I tried
everything out of spite; also tried backslashes).

Of course, one at a time, and restarting SciTE each time.

Note that the SciTEXxHome paths are OK, I can see them in the custom
statusbar.text I have set.

This isn't really a network path, but a regular path (on disk) managed
by Dropbox. Not sure if there is a difference.

Actually, I copied all the properties files to D:\Temp\SciTE, and
changed the environment variables, and I had the same issue. So Dropbox
doesn't seem involved.
Moved this to C:\Temp\SciTE, no improvement… (these are physical disks,
BTW).

I don't get why it doesn't work on my computers… 🤔
Maybe I should reinstall a C++ development environment and debug… (but I
haven't done that in years, I am more into Web dev these days…)

[Philippe Lhoste]

Well, I tested older versions, including the one I upgraded from, and I
found out that this import problem isn't new!
And it looks more like a system problem than one with SciTE: even a v. 3
doesn't work.
I didn't see the issue as more settings I used daily are in the main
SciTEUser, and these days, I use SciTE more as a buffer for small tasks
(without syntax highlighting) rather than as my main editor.

I still don't get why I am the only one with the issue. I will find
workarounds, I suppose.

Thanks.

[Neil Hodgson]

[Note, any ” in this mail should be " but Mail.app tries to correct quotes]

Philippe Lhoste:

> And it looks more like a system problem than one with SciTE: even a v. 3
> doesn't work.

OK. Let’s try to narrow down the possibilities.

First check the values used for default and user by typing in the output pane:

echo Default="$(SciteDefaultHome)" User="$(SciteUserHome)"

The quotes are to try to detect extra spaces. The result on my just-now test (after setting SciTE_HOME=D:\usr\wscite) were:

>echo Default="D:\usr\wscite" User="D:\usr\wscite"
Default="D:\usr\wscite" User="D:\usr\wscite"

Then open User Options from the Options menu and show the path:

echo "$(FilePath)"

With the result

"D:\usr\wscite\SciTEUser.properties"

Now this file contains the "import PhiLho/SciTEUser" and that file exists. Now at the end of the Options menu is "Open PhiLho/SciTEUser". Is that entry present? If selected does it open the correct file?

With "PhiLho/SciTEUser" open, what does 'echo "$(FilePath)"' produce:

"D:\usr\wscite\PhiLho\SciTEUser.properties"

Ah! Just realized that setting "imports.include" may filter it out unless it includes "PhiLho/SciTEUser".

Neil

[Philippe Lhoste]

After setting SciTE_UserHome, I could load the main user properties
files, but the imports didn't work. But at least, I had all these
variables in the statusbar, so I could examine them.

> Ah! Just realized that setting "imports.include" may filter it out unless it includes "PhiLho/SciTEUser".

That's it!
I had imports.exclude of most languages I don't use (or event know…),
and an imports.include=markdowwn (it was excluded in the previous one),
probably an experiment made a long time ago…
After I commented out the latter, my include loading the position of
SciTE worked, but not my language properties files.
I removed the last line in imports.include, which excluded these too.
I wanted to remove them from being imported in the main properties
files, to take in account only the properties I set. The idea was to
avoid defining properties I didn't want to have and didn't want to disable.

To be clearer, previous settings were:

imports.exclude=\
abaqus asciidoc asl [... more ...] markdown verilog vhdl visualprolog \
\
abbrev cpp css html lua others pov sql vb

imports.include=markdown

# Properties I customized
import abbrev
import cpp
import css
import html
import lua
import others
import pov
import sql
import vb

I am pretty sure this worked at some time… (except perhaps for the
imports.include ? Not sure anymore). Ie. perhaps at some time, it worked
in a linear way, the import statements overriding the imports.exclude,
no longer now?

I removed markdown from imports.exclude, removed the imports.include,
and now it works!

Anyway, thanks for pushing me in the right direction!

Regards.

[Neil Hodgson]

Philippe Lhoste:

> I removed the last line in imports.include, which excluded these too.
> I wanted to remove them from being imported in the main properties
> files, to take in account only the properties I set. The idea was to
> avoid defining properties I didn't want to have and didn't want to disable.

The scope of the "imports.include" setting is unclear and it may make sense to change it. Perhaps it should only affects "import *" and be ignored for any explicit (non-wildcard) import.

Neil