Activity for Scintilla
-
Joseph Betz modified a comment on ticket #2506
Open a new similar window: same text and size since GPU memory increases with window size. So, if I open a Scintilla window of size 1140@942, about 10mb of GPU memory gets allocated. If I open another with the same text and size, another 10mb gets allocated. If I then close one of those windows, and then open another similar window, another 5mb gets allocated. So, roughly half. If I open another window, it's back to allocating 10mb each time. At no point after closing a window does the GPU memory...
-
Open a new similar window: same text and size since GPU memory increases with window size. So, if I open a Scintilla window of size 1140@942, about 10mb of GPU memory gets allocated. If I open another with the same text and size, another 10mb gets allocated. If I then close one of those windows, and then open another similar window, another 5mb gets allocated. So, roughly half. If I open another window, it's back to allocating 10mb each time. At no point after closing a window does the GPU memory...
-
Neil Hodgson posted a comment on ticket #2503
WM_NCPAINT doesn't appear to occur when the Scintilla window has no border as may be caused when any borders or dividers are supplied by other windows in the hierarchy.
-
How do you reopen a window that has already been closed? Open a new similar window: same text and size since GPU memory increases with window size. The purpose is to allocate in a similar pattern to the initial sequence of window creations. That way, the allocated pool (if that is the implementation) may be re-used if the allocations were released to the pool during window destructions.
-
Neil Hodgson committed [540584] on SciTE
Use const for retrieved `passwd`.
-
Zufu Liu modified ticket #2179
Win32: ListBoxX::GetDesiredRect should use correct technology to measure width
-
Fixed in v5.5.6.
-
Neil committed [334e49] on SciTE
Make methods static where possible and suppress warnings when not.
-
Neil committed [0dab52] on SciTE
Update cppcheck command to avoid some difficult code by undefining __clang__.
-
Neil committed [95eae8] on SciTE
Add SCE_ASM_STRINGBACKQUOTE for NASM `back-quoted strings`.
-
Neil committed [04c521] on SciTE
Update suppressions for cppcheck 2.20.
-
Neil committed [fd871c] on Scintilla
Update suppressions for cppcheck 2.20.
-
Can't see anything obvious in the allocation and deallocation of Direct* resources. They are handled through WRL::ComPtr so should all be released when deleting the ScintillaWin. Thanks for looking into it. Sometimes code allocates memory pools which are retained to avoid extra work. Open multiple Scintilla windows then close them and open the same windows again. If there is a similar amount of memory used after the second openings then the use may be of this form. How do you reopen a window that...
-
Can't see anything obvious in the allocation and deallocation of Direct* resources. They are handled through WRL::ComPtr so should all be released when deleting the ScintillaWin. Thanks for looking into it. Sometimes code allocates memory pools which are retained to avoid extra work. Open multiple Scintilla windows then close them and open the same windows again. If there is a similar amount of memory used after the second openings then the use may be of this form. How do you reopen a window that...
-
Can't see anything obvious in the allocation and deallocation of Direct* resources. They are handled through WRL::ComPtr so should all be released when deleting the ScintillaWin. Thanks for looking into it. Sometimes code allocates memory pools which are retained to avoid extra work. Open multiple Scintilla windows then close them and open the same windows again. If there is a similar amount of memory used after the second openings then the use may be of this form. I don't understand. How do you...
-
Can't see anything obvious in the allocation and deallocation of Direct* resources. They are handled through WRL::ComPtr so should all be released when deleting the ScintillaWin. Thanks for looking into it. Sometimes code allocates memory pools which are retained to avoid extra work. Open multiple Scintilla windows then close them and open the same windows again. If there is a similar amount of memory used after the second openings then the use may be of this form. I don't understand. How do you...
-
Gary Wang modified a comment on ticket #2502
For example, to select the font we provided above (Judou Mono FCM), if we use QFontDialog::getFont() and select the same font but different style name, the output of the following code would be: // Button to open the font dialog QPushButton *fontButton = new QPushButton("Select Font", &window); QObject::connect(fontButton, &QPushButton::clicked, [&]() { bool ok; // Open the font dialog QFont font = QFontDialog::getFont(&ok, label->font(), &window, "Pick a font"); if (ok) { // If the user clicks OK,...
-
For example, to select the font we provided above (Judou Mono FCM), if we use QFontDialog::getFont() and select the same font but different style name, the output of the following code would be: // Button to open the font dialog QPushButton *fontButton = new QPushButton("Select Font", &window); QObject::connect(fontButton, &QPushButton::clicked, [&]() { bool ok; // Open the font dialog QFont font = QFontDialog::getFont(&ok, label->font(), &window, "Pick a font"); if (ok) { // If the user clicks OK,...
-
"Extended" here appears to be equivalent to setting the font stretch parameter to greater than the default SC_STRETCH_NORMAL=5 like SC_STRETCH_EXPANDED=7. Well, style name works like a "preset", developers does not know the actual stretch number, different font might offer different stretch value using the same style name, or even using a different style name. Actually, we cannot even know the style name is for the stretch font property since the name itself can be anything... it is less likely that...
-
Report and Fix for Spurious Error Message Checking Reload on Untitled Files
-
Committed the above code with [1c0de1]. The installer appears to have been discontinued by its author. The customizations were part of the purpose of that project.
-
Neil committed [b63845] on SciTE
Ignore new Visual Studio solution file type.
-
Neil committed [1c0de1] on SciTE
Bug [#2504]. Fix error when untitled buffer has a filter command executed on it.
-
"Extended" here appears to be equivalent to setting the font stretch parameter to greater than the default SC_STRETCH_NORMAL=5 like SC_STRETCH_EXPANDED=7. Since the effect can be achieved by setting an existing parameter, it is less likely that adding an alternative API is justified. When there are two ways to set a parameter, the interaction between these approaches can be a source of bugs and uncertainty.
-
An option doesn't appear to be worth the effort of implementation and maintenance to me.
-
Mark W. Gabby-Li posted a comment on ticket #2504
Thanks. For full clarity, I believe my Windows installs came from the old "SciTE for Windows" installers, which may have had different versions of the property files? I see the Windows installers are no longer available. I seem to remember they were provided by a third party rather than the project itself? Perhaps there was some mistake when packaging them and they included user-customized property file by accident, or perhaps they had intentional customizations.
-
That line isn't in the distributed html.properties. I have some recollection of setting up HTML Tidy to reformat HTML files so it may be in some other version of html.properties. With that cleared up, it should be OK to stop the problem for untitled files by avoiding the decrement for invalid modification times. While there may be some benefit to running a filter like HTML Tidy on an untitled buffer, there would be the hassle of creating a temporary file and making sure to remove it later. The user...
-
Can't see anything obvious in the allocation and deallocation of Direct* resources. They are handled through WRL::ComPtr so should all be released when deleting the ScintillaWin. The particular technology setting may affect behaviour with Technology::DirectWrite1 being more complex and with newer code. Sometimes code allocates memory pools which are retained to avoid extra work. Open multiple Scintilla windows then close them and open the same windows again. If there is a similar amount of memory...
-
Found it! html.properties in C:\ProgramData\SciTE\. The broken property is in a Windows platform block! This is why it was happening for me but not you, you must be on a different platform (I was also not able to replicate it on Linux, so I just booted into Windows and found the error): if PLAT_WIN [...] command.is.filter.1.*=1
-
Found it! html.properties in C:\ProgramData\SciTE\, I think this is installed by default on Windows. This is why it was happening for me but not you, you must be on a different platform (I was also not able to replicate it on Linux, so I just booted into Windows and found the error): if PLAT_WIN [...] command.is.filter.1.*=1
-
Found it! html.properties in C:\ProgramData\SciTE\, I think this is installed by default on Windows: ``` if PLAT_WIN command.is.filter.1.*=1 ```
-
Found it! html.properties in C:\ProgramData\SciTE\, I think this is installed by default on Windows: ``` if PLAT_WIN [...] command.is.filter.1.*=1 ```
-
Wasn't able to reproduce with those files. It's better to find the base cause of this bug instead of recovering in CheckReload as the bug may cause other problems. When the call is made to get the filter status of the command in the JobMode constructor, propName is command.is.filter.1., and fileNameExt is empty. The main things I'm imaging could be wrong are unexpected command properties or incorrect wildcard matching. There are other settings that include "filter" so a spurious match may be possible....
-
Digging into my properties, I don't see any filter settings at all for any commands, nor any use of command.mode. I've attached all the options files and my Lua startup script to this comment. Note that I'm on Windows and I've seen this behavior on the latest in hg as of my report. When the call is made to get the filter status of the command in the JobMode constructor, propName is command.is.filter.1., and fileNameExt is empty.
-
Dedicated GPU memory isn't cleaned up when Scintilla instances are destroyed
-
For stability, I deliberately left that alone to avoid potential for problems in applications.
-
Tom posted a comment on ticket #1583
Thank you for the reply. I understand your reasons for not implementing wrap-around by default, but maybe it would be useful as an optional feature for many users.
-
Markus Nißl created ticket #2505
Blurry text in autocompletion lists with DirectWrite in a GDI scaled application
-
Update: Yesterday, I was moving the application between monitors with the shortcut Win+Shift+Left/Right. This triggers the message WM_WINDOWPOSCHANGED. Alas, when you drag the application with the mouse between monitors, WM_WINDOWPOSCHANGED is not sent. The change in scale factor when crossing monitor boundaries does trigger WM_PAINT, but also WM_NCPAINT which is sent way less often than WM_PAINT. Hence I suggest to update ScintillaWin::WndProc() by moving the WM_NCPAINT case down to WM_WINDOWPOSCHANGED....
-
Update for endStyled += length; isn't consistent: one before the notification one after.
-
Sure, but that still means that a command that is set as a filter (not that I know what that means) will produce this spurious error message? Also perhaps the code that job mode is calling is assuming that all files have extensions, which could be what is causing some of the unpredictable behavior? I'd have to dig into that more though, ideally with a debugger. (never mind about the -1 mod time comment, I think I misunderstood.) I will look at my properties later, I don't have them on hand right...
-
Sure, but that still means that a command that is set as a filter (not that I know what that means) will produce this spurious error message? Also perhaps the code that job mode is calling is assuming that all files have extensions, which could be what is causing some of the unpredictable behavior? I'd have to dig into that more though, ideally with a debugger. And the code is absolutely setting the file mod time to -1, which based on the use of that value seems to mismatch the intent; the code that...
-
Sure, but that still means that a command that is set as a filter (not that I know what that means) will produce this spurious error message? Also perhaps the code that job mode is calling is assuming that all files have extensions, which could be what is causing some of the unpredictable behavior? I'd have to dig into that more though, ideally with a debugger. And the code is absolutely setting the file mod time to -1, which based on the use of that value seems to mismatch the intent; the code that...
-
Sure, but that still means that a command that is set as a filter (not that I know what that means) will produce this spurious error message? And the code is absolutely setting the file mod time to -1, which based on the use of that value seems to mismatch the intent; the code that is checking if it's nonzero that displays the error message seems to imply that nonzero is a valid value for the mod time and zero perhaps implies no file?
-
Check for overlapping command patterns. If there are two patterns like *.java and *.cpp specifying properties, the priority is not obvious. The standard properties only specify a few filter properties for *.sol and command.is.filter.0.$(file.patterns.cpp) which is for command 0 so shouldn't interfere with your command 1. As well as command.is.filter, command.mode may set the filter state. The filter code could be improved as the time hack to force reload isn't great.
-
Neil Hodgson committed [ffeb4e] on Scintilla
Replace use of `enum` where this produced warnings from Xcode 26.4 with `static constexpr int`.
-
I added some logs, and what's happening is command.is.filter is being read as set by JobMode::JobMode(), so isFilter is set. Is that the default? I did not set it in my tool. That causes SciTEBase::ToolsMenu() to set CurrentBuffer()->fileModTime to -1, which meets all the criteria for the conditional to hit for the error message on an Untitled buffer.
-
Neil Hodgson committed [981c4a] on SciTE
Add casts to silence warnings from Xcode 26.4.
-
Optimize `Document::SetStyles()` and `Document::SetStyleFor()`
-
Committed with [4f2ea7] and [281e29].
-
Neil committed [4f2ea7] on Scintilla
Feature [feature-requests:#1582]. Improve performance of Document::SetStyles.
-
Neil committed [281e29] on Scintilla
Feature [feature-requests:#1582]. Add tests for Document::SetStyles and
-
Here's the lines() function: function lines(str) local t = {} local i, lstr = 1, #str while i <= lstr do local x, y = string.find(str, "\r?\n", i) if x then t[#t + 1] = string.sub(str, i, x - 1) else break end i = y + 1 end if i <= lstr then t[#t + 1] = string.sub(str, i) end return t end I tested with and without my change, and it definitely made the error dialog go away. I've attached an example of the error dialog for reference.
-
This does not occur for me and the path through the code should not be possible. newModTime will be 0 because there is a check for untitled in FilePath::ModifiedTimethat returns 0. Then there must be a non-0 value in CurrentBuffer()->fileModTime which shouldn't be possible since it is for an untitled buffer. Possibly something more complex is occurring. The above example is missing a lines function.
-
Duplicate of [feature-requests:#1495].
-
Report and Fix for Spurious Error Message Checking Reload on Untitled Files
-
Invalidate render targets when detecting a changed scaling factor
-
Neil committed [fd7fca] on SciTE
Add Pascal triple quoted multiline string.
-
Make autocompletion popup list cyclable
-
Neil committed [feded8] on SciTE
Update from Lexilla for F#.
-
Neil committed [3bd0fb] on SciTE
Add section for next release.
-
Neil committed [8446d1] on SciTE
Simplify script.
-
Issue with automatic folding and SC_FOLDLEVELWHITEFLAG
-
PRIMARY selection gets filled, when search matches are marked
-
GCC 15/Qt - ScintillaTypes.h: error: ‘intptr_t’ does not name a type
-
SCI_LINEDELETE works inconsistently with SCI_LINECOPY and SCI_LINECUT
-
Change ListBoxX to using modern control subclassing
-
[Feature Request] Change History Indicators for modifications outside of current vertical scroll position
-
Update perl.properties keywords list
-
Updated support for the Hollywood programming language
-
Scite: use of deprecated API of gdk-pixbuf leads to errro message at startup
-
Document::ConvertLineEnds() does not convert all line-ends
-
Weird behavior upon click inside selected text when drag-and-drop is disabled
-
Scintilla released /SciTE/5.6.1/wscite561.zip
-
-
-
-
-
-
-
-
-
-
-
Neil committed [64e4d5] on SciTE
Added tag rel-5-6-1 for changeset 53c0a22dac69
-
Neil committed [9a25e6] on Scintilla
Added tag rel-5-6-1 for changeset 5ab4c75c3d5d
-
OK.
-
Depending on which function gets more of the code, the inliner is bouncing between inlining CopyBytes into CellBuffer::SetStyles or inlining CellBuffer::SetStyles into Document::SetStyles. It is unlikely saving one call (the potential second CopyBytes) in this context is important..
-
OK. Truncating length in SetStyles and SetStyleFor seems reasonable. Moving this and subdividing over the gap into a common SplitUpdate. When length1 is 0, SplitUpdate could move length2 to length1 similar to the length1 ? length1 : length2 logic. There's also similar splitting logic in GetRange. ChangedRange CopyBytes(char *p, const char *styles, Sci::Position length, Sci::Position offset) noexcept { for (Sci::Position start = 0; start < length; start++) { if (p[start] != styles[start]) { for (Sci::Position...
-
OK. Truncating length in SetStyles and SetStyleFor seems reasonable. Moving this and subdividing over the gap into a common SplitUpdate. When length1 is 0, SplitUpdate could move length2 to length1 similar to the length1 ? length1 : length2 logic. There's also similar splitting logic in GetRange. ChangedRange CopyBytes(char *p, const char *styles, Sci::Position length, Sci::Position offset) noexcept { for (Sci::Position start = 0; start < length; start++) { if (p[start] != styles[start]) { for (Sci::Position...
-
OK. Truncating length in SetStyles and SetStyleFor seems reasonable. Moving this and subdividing over the gap into a common SplitUpdate. When length1 is 0, SplitUpdate could move length2 to length1 similar to the length1 ? length1 : length2 logic. There's also similar splitting logic in GetRange. struct Lengths { Sci::Position length1; Sci::Position length2; }; Lengths SplitUpdate(const SplitVector<char> &style, Sci::Position position, Sci::Position length) noexcept { length = std::min(length, style.Length()...
-
Source code with your CopyBytes is shorter (msvc cl /utf-8 /W4 /c /EHsc /std:c++20 /O2 /GS- /GR- /FAcs /DNDEBUG /I../include CellBuffer.cxx not inline CopyBytes), but msvc generated asm with my SetStylesRange is shorter. Scintilla commonly builds with link time code generation which enables more inlining. That is cl /GL and link -LTCG.
-
truncation can be used to simplify lexer: StyleContext could use styler.ColourTo(currentPos - 1, state); instead of styler.ColourTo(currentPos - ((currentPos > lengthDocument) ? 2 : 1), state);. trailing word classify block (e.g. in LexHTML) could be omitted by increase end position/length like StyleContext does. for LexHTML it's only needed for PHP where ?> can be omitted and is preferred to avoid extra content.
-
(position < 0) || (length <= 0) || ((position + length) > style.Length()) assuming initial (after call Document::StartStyling()) endStyled is within document position range, this changed previously truncation behavior, though updated endStyled may larger then document length. Setting styles for positions outside the range of the buffer is safe and has no effect.
-
Source code with your CopyBytes is shorter (msvc cl /utf-8 /W4 /c /EHsc /std:c++20 /O2 /GS- /GR- /FAcs /DNDEBUG /I../include CellBuffer.cxx not inline CopyBytes), but msvc generated asm with my SetStylesRange is shorter. changes compared to SetStyles0319Range.diff. - ++length; - if (index < length) { + if (index <= length) { + ++length; template <bool segment1> void SetStyleRange(char *data, char styleValue, Sci::Position length, StyleChangeRange &range, Sci::Position position) noexcept { Sci::Position...
-
Attached my current version. The generated code seems good. struct ChangedRange { Sci::Position start = -1; Sci::Position end = -1; ChangedRange() noexcept = default; ChangedRange(Sci::Position start_, Sci::Position end_) noexcept : start(start_), end(end_) {} void Offset(Sci::Position offset) noexcept { if (start >= 0) { start += offset; end += offset; } } bool Empty() const noexcept { return start < 0; } void Merge(const ChangedRange &cr2) noexcept { if (cr2.start >= 0) { if (start < 0) { *this...
-
Neil committed [53c0a2] on SciTE
Updates for version 5.6.1.
-
Neil committed [5ab4c7] on Scintilla
Updates for version 5.6.1.
-
Neil committed [5fa9f1] on SciTE
Forth changes from Lexilla.
-
Neil committed [72a897] on SciTE
Convert all Forth keywords to lower case to match lexer.
1 >
