29 views
Skip to first unread message

Neil Hodgson

unread,
Sep 24, 2026, 7:28:41 AM (13 days ago) Sep 24
to scintilla...@googlegroups.com, scite-i...@googlegroups.com
New versions of Lexilla (5.5.4), Scintilla (5.6.7), and SciTE (5.6.7)
will be released soon, likely on September 28.

Changes:

SciTE 5.6.7

• Fix Find in Files bug where matching final line in file without
final new line showed a NUL in the output pane. Ensure text found
after a NUL on a line in binary mode.

Lexilla 5.5.4

• JavaScript: Option lexer.cpp.continuation.only.in.strings to
choose JavaScript behaviour where line continuation only occurs inside
string literals. Issue #55.
• YAML: Fix empty lines terminating text blocks. Issue #326.

Scintilla 5.6.7

• Reduce memory used by line layouts by storing positions as 32-bit
floats instead of 64-bit.
• Reduce temporary memory use during layout of wide lines with many
control characters.
• Fix style ending inside character after deleting last character
of document. Bug #2471.
• Fix SCI_VERTICALCENTRECARET to not scroll past end. Bug #2518.
• For SCI_GETCOLUMN and SCI_FINDCOLUMN treat Unicode line ends
similar to ASCII line ends. Bug #2516.

The committed changes can be examined either in the repositories

git clone https://github.com/ScintillaOrg/lexilla
hg clone http://hg.code.sf.net/p/scintilla/code scintilla
hg clone http://hg.code.sf.net/p/scintilla/scite

or from

https://www.scintilla.org/scite.zip Source
https://www.scintilla.org/wscite.zip Windows executable (64-bit)

Neil

Neil Hodgson

unread,
Sep 25, 2026, 5:01:07 AM (12 days ago) Sep 25
to scintilla...@googlegroups.com, scite-i...@googlegroups.com
A new bug was spotted with the current code so another commit tries to
fix that and there are refreshed downloads.

The problem was that text would jiggle around while editing on Win32
using GDI (technology=0).

This was due to the use of lower-precision 32-bit floats with a
compensating calculation instead of 64-bit doubles. Unfortunately,
this can produce small inaccuracies such as a position of 10.0 being
stored as 9.999999. The Win32 GDI platform layer code then truncated
this to 9. The 9.999999 value appears OK with most platform layers
which use floating point coordinate spaces.

The Win32 platform layer could round for GDI coordinates but this
wouldn't help any other independent platform layers using integer
coordinates. Therefore, positions just below an integer are forced up
to that integer. This was committed with this change set.
https://sourceforge.net/p/scintilla/code/ci/967909317010991a346f13ec8b9ccd4207da347a/

This change occurs at retrieval and performs more calculations so will
be slower. This may change after the release to moving problematic
values up by a minimal amount when storing which occurs much less
frequently.

The committed change can be examined either in the repository
Reply all
Reply to author
Forward
0 new messages