Make `BLI_path_contains()` case-insensitive on Windows. This behaviour
is dependent on the platform Blender is running on, like the rest of
BLI_path, and not on the style of paths (Windows-style paths will be
treated case-sensitively when Blender is running on Linux/macOS).
Add function `BLI_path_contains(container, containee)` that returns true
if and only `container` contains `containee`.
Paths are normalised and converted to native path separators before
comparing. Relative paths are *not* made absolute, to simplify the
function call; if this is necessary the caller has to do this conversion
first.
This patch fixes many minor spelling mistakes, all in comments or
console output. Mostly contractions like can't, won't, don't, its/it's,
etc.
Differential Revision: https://developer.blender.org/D11663
Reviewed by Harley Acheson
BLI_getenv has always incorrectly returned ascii rather
than UTF-8. This change corrects this behaviour.
This resolves issues when the `BLENDER_USER_CONFIG`
environment variable contains a path with Unicode characters
on windows as reported in T74510 (but unlikely the root
cause for the issue at hand there)
Differential Revision: https://developer.blender.org/D9831
Reviewed by: brecht
Caused problems in the Asset Browser branch when passing an empty path. The
function shouldn't blindly add a slash but sanity-check the input parameters
first.
We have our own assert implementation, `BLI_assert()` that is prefered over the
C standard library one. Its output is more consistent across compilers and
makes termination on assert failure optional (through `WITH_ASSERT_ABORT`).
In many places we'd include the C library header without ever accessing it.
This addresses warnings from Clang-Tidy's `readability-else-after-return`
rule in the `source/blender/blenlib` module. Not all warnings are
addressed in this commit.
No functional changes.
Comparing the drive letter was case sensitive,
causing 'BLI_path_rel' to fail in common cases
(manually entering a lower case drive letter for example).
Surprisingly this issue dates back to 2005 and wasn't reported.
The most common use of the text editor seems to be for scripting. Having
line numbers and syntax highlighting enabled by default seems sensible.
Syntax highlighting is now enabled by default, but is automatically
disabled when the datablock has a non-highlighted extension.
Highlighting is enabled for filenames like:
- Text
- Text.001
- somefile.py
and is automatically disabled when the datablock has an extension for
which Blender has no syntax highlighter registered.
Reviewers: billreynish, campbellbarton
Subscribers: brecht, billreynish
Differential Revision: https://developer.blender.org/D5472
The declaration and implementation of BLI_path_name_at_index were
out of sync leading to build warning
C4028: formal parameter 1/3/4 different from declaration
