Activity for Scintilla
-
notepadfreak modified a comment on ticket #1578
The problem is when you have edited something in the current vertical scroll and also outside of it, so because you get both reddened change markers and the asterisk, you have no means to know if there are any edits outside the current vertical scroll. And neither do you have a means to check it outside of scrolling until coming across one of those edits. Which is inefficient. With some indicator of edits that are outside the current vertical scroll I would suddenly have some guidance on how to explore...
-
The problem is when you have edited something in the current vertical scroll and also outside of it, so because you get both reddened change markers and the asterisk, you have no means to know if there are any edits outside the current vertical scroll. And neither do you have a means to check it outside of scrolling until coming across one of those edits. Which is inefficient. With some indicator of edits that reside outside the current vertical scroll I would suddenly have some guidance on how to...
-
The problem is when you have edited something in the current vertical scroll and also outside of it, so because you get both reddened change markers and the asterisk, you have no means to know if there are any edits outside the current vertical scroll. And neither do you have a means to check it outside of scrolling until coming across one of those edits. Which is inefficient. With some indicators of edits outside the current vertical scroll I would know how to explore the Document Map whenever the...
-
The problem is when you have edited something in the current vertical scroll and also outside of it, so because you get both reddened change markers and the asterisk, you have no means to know if there are any edits outside the current vertical scroll. And neither do you have a means to check it outside of scrolling until coming across one of those edits. Which is inefficient. At least with the arrows I know how to explore the Document Map whenever the need arises.
-
The problem is when you have edited something in the current vertical scroll and also outside of it, so because you get both reddened change markers and the asterisk, you have no means to know if there are any edits outside the current vertical scroll. And neither do you have a means to check it outside of scrolling until coming across one of those edits. Which is inefficient.
-
Neil Hodgson posted a comment on ticket #1578
you still have no visual feedback if something has been edited outside the current vertical scroll position This is indicated by the asterisk coupled with the absence of visible change markers. This feature does not seem worthwhile to me. You could experiment with the concept by adding new windows to your application. Perhaps as thin windows above and below Scintilla approximating the appearance of suggestion 1 above.
-
[Feature Request] Change History Indicators for modifications outside of current vertical scroll position
-
Juergen Daubert posted a comment on ticket #2498
gdk-pixbuf on my system is build with XPM support. As I wrote already, this behavior is new with version 2.44.5, all versions until 2.44.4 and older are working without the warnings and errors.
-
Most applications, including Notepad++, indicate unsaved changes with an asterisk next to the file name in the title bar. Notepad++ also changes the colour of the icon in the file's tab. Yes, but what I'm trying to say is that when you modify something in the current vertical scroll position and get that asterisk, you still have no visual feedback if something has been edited outside the current vertical scroll position maybe by some possible accident from pressing keyboard shortcuts, so you could...
-
Most applications, including Notepad++, indicate unsaved changes with an asterisk next to the file name in the title bar. Notepad++ also changes the colour of the icon in the file's tab. Yes, but what I'm trying to say is that when you modify something in the current vertical scroll position and get that asterisk, you still have no visual feedback if something has been edited outside the current vertical scroll position maybe by some possible accident from pressing keyboard shortcuts, so you could...
-
if you are leaving something unsaved outside the current vertical scroll position without any awareness of it Most applications, including Notepad++, indicate unsaved changes with an asterisk next to the file name in the title bar. Notepad++ also changes the colour of the icon in the file's tab. Windows are independent and should only draw in their own area. Most of the illustrated suggestions draw outside the content area of the Scintilla window. Even if Scintilla were to force drawing on the surrounding...
-
Neil committed [625144] on Scintilla
Use std::array for text measurement cases where it only adds a little code.
-
Neil committed [c6b5a4] on Scintilla
Warning avoidance and code tidying.
-
Neil committed [af0b3b] on Scintilla
Avoid some warnings to make more interesting issues visible.
-
Neil committed [92bf22] on Scintilla
Rename some xStart to xOrigin as xStart was used for different purposes.
-
Neil committed [b8a9a7] on Scintilla
Use min and max instead of conditional code.
-
Neil committed [f757f4] on Scintilla
Fix some warnings from magic numbers and else after return.
-
[Feature Request] Change History Indicators for modifications outside of current vertical scroll position
-
It is up to your distribution whether GdkPixbuf is built with XPM support. I use Ubuntu (currently 25.10) which includes XPM support. These deprecation warnings do not appear for me on this system. SciTE uses XPM for toolbar buttons and search/replace pane option buttons. The toolbar can be changed to use stock system images with the toolbar.usestockicons=1 setting although some of these aren't great and this won't avoid the warnings. XPM makes it easy to include images inline in source code where...
-
Scite: use of deprecated API of gdk-pixbuf leads to errro message at startup
-
My experience with EOL annotation is that it always has one space before the annotation, it would be nicer if that space can be optionally removed to better create the "inline" effect. There is an 'end-of-line-selection' space after the last character on a line. If you select over the line end (such as selecting two lines) that space shows the selection background colour. While the size of that space could be modifiable, setting to zero or very small would affect other lines in a way that would likely...
-
yonken posted a comment on ticket #1577
My experience with EOL annotation is that it always has one space before the annotation, it would be nicer if that space can be optionally removed to better create the "inline" effect. Based on your comment, my understanding is that for now I can try to produce the feature with a EOL annotation (but without syntax color). When there's multiple line of text, I will also need a few more SCI_ANNOTATIONSETTEXT. I understand this may require more hard work, but still it would be nice to have this as an...
-
Inline annotation with syntax coloring
-
Styling of annotations is possible with SCI_ANNOTATIONSETSTYLES and the same feature could be implemented for EOL annotations since they share code. This still requires choosing styles, perhaps by lexing in an invisible document+window or preparing before hand in a configuration file. Perhaps first try a single inline annotation with both pieces of text to see how it works before the more complex work of adding styling to EOL annotations. It should be possible to produce the simplified feature just...
-
Inline annotation with syntax coloring
-
Neil committed [c8de12] on SciTE
Harmonize types and avoid warning.
-
Neil committed [aee791] on SciTE
Optimize out resizing when ShowBackgroundProgress does not change visibility of
-
Neil committed [11ddfa] on SciTE
Fix some warnings.
-
Neil committed [d9bb5f] on SciTE
Remove unused declaration which is available from header.
-
Roberto Rossi committed [8c0901] on SciTE
Add session.readonly option to save read-only choice in session files.
-
Neil committed [4d01d9] on Scintilla
Hoist calculation of last style of line into function and simplify logic.
-
Neil committed [379955] on Scintilla
Hoist EOL annotation padding calculations into functions.
-
Neil committed [87fe10] on Scintilla
Encapsulate updating maximum width for scroll bar adjustment.
-
Neil committed [447dbf] on Scintilla
Minor simplifications in Editor::Indent.
-
Neil committed [0cf8bf] on Scintilla
Small optimizations and adding noexcept for column calculations.
-
Zufu Liu modified ticket #2497
Rectangular selection indent incorrect selection modes and positions
-
The example shows the effect of trying to maintain selection rectangularity over the indent operation. The current indent code is mostly designed to handle stream selection. It chooses the end of indentation as the best place to position the caret afterwards as it simplifies some common actions like adding spaces for fine control over indentation or adding to the line text. This choice is more advantageous when there are multiple selections. In the example, the lines initially get empty selections...
-
The patch appears to me to change behaviour for too many situations (any call to SetRectangularRange) to be safe. A change restricted to Editor::Indent is less likely to cause new problems. A branch inside Editor::Indent that specializes the rectangular case explicitly should allow tighter control. Operating on a copy of the initial selection could avoid interference from rectangular selection recalculations. This would likely duplicate the lengthy calculations for each selection although the specific...
-
0x80 can be omitted from CP932/Shift_JIS, as it just maps to U+0080 C1 control character in CP932, and unsupported in other Japanese encodings: >>> pages = ['cp932', 'shift_jis', 'shift_jis_2004', 'shift_jisx0213', 'euc_jp', 'euc_jis_2004', 'euc_jisx0213'] >>> [b'\x80'.decode(page, 'backslashreplace') for page in pages] ['\x80', '\\x80', '\\x80', '\\x80', '\\x80', '\\x80', '\\x80'] >>> though omit it will cause a visual change: rendered by platform as invisible/box/question block vs rendered by Scintilla...
-
Triple click without selecting newline char
-
Single line selection is a part of line selection mode. Moving the mouse to other lines before releasing the button after the third mouse down selects multiple lines. A preference to omit the end line character(s) should address the behaviour of selecting multiple lines. I'd expect just omitting the final line end but alternatives include omitting the line end only from single line selections and omitting all line ends in the selected lines. I'll accept a well-written patch that implements this as...
-
OK.
-
Without a more specific benefit, such as a report of use of some single-byte EUDC, I think changing behaviour is more likely to produce new problems.
-
Cory Doctorow posted a comment on ticket #1576
Sorry, don't know what happened to the formatting there! The example that was omitted was a href=" [ctrl-v]"
-
Triple click without selecting newline char
-
off-topic the single byte range for CP932/Shift-JIS seems contains EUDC (end user defined character?). https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit932.txt vs https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP932.TXT EUDC from https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/ Code Page EUDC Control 932 0xa0, 0xfd - 0xff 936 0xff 949, 950 0xff 0x80 1361 0xd4 - 0xff 0x80 - 0x83 Should these EUDC also be included?
-
cp936/GBK treat 0x80 as valid single byte
-
Committed as [808977]. Works on Linux/GTK and macOS/Cocoa as well. Failures on other platforms can be addressed if they occur.
-
Zufu Liu committed [808977] on Scintilla
Allow Euro in code page 936 for byte 0x80.
-
not sure whether it will cause problem on earlier or non-Windows systems. Tested following code on XP, Vista and Win7: #include <windows.h> #include <stdio.h> int main(void) { char chars[2] = {'\x80'}; wchar_t code[2] = {0}; int len = MultiByteToWideChar(936, 0, chars, 1, code, 2); return printf("len=%d, code=%04X\n", len, code[0]); } the output is len=1, code=20AC as on Win 10 and 11.
-
cp936/GBK treat 0x80 as valid single byte
-
I don't work on the mac Qt version myself. You could look at ScintillaEditBase::keyPressEvent and add tracing. There is some special handling of alt (Option) starting at bool input = (!ctrl || alt);.
-
Simon Berriman posted a comment on ticket #2492
On macOS, the Option key appears to be intercepted, so 'Option + numeric key' combos on non-US keyboard layouts do not produce the desired characters. For example, Option+3 on a UK layout MacBook M4 Pro running Tahoe 26.2 should produce '#'. Likewise Option+2 should be '€'. These do not register in Scintilla and nothing is produced, as shown in the macOS version of NotepadNext - the bug report for which is linked this bug's description.
-
Nathaniel Braun posted a comment on ticket #184
Thanks for the quick turnaround!
-
The first 2 hunks in that patch appear to be changes I already made with 'Documentation changed slightly'. Committed the 3rd and 4th hunks with [c3f623]. It's better to generate patches against current source code control head since that is where it will be applied.
-
Nathaniel Braun committed [c3f623] on Scintilla
Feature [feature-requests:#184]. Small optimization.
-
@nyamatongwe here is a small patch which fixes some typos in the documentation and slightly improves performance by placing the check on the status of drag-and-drop editing earlier.
-
Thank you very much @nyamatongwe!
-
Neil committed [7f183a] on SciTE
Feature [feature-requests:#184]. Add option to disable drag/drop editing.
-
Neil committed [086e7c] on SciTE
Change log from Lexilla and Scintilla.
-
Option to disable drag/drop editing
-
Committed with [592f74]. Documentation changed slightly.
-
Nathaniel Braun committed [592f74] on Scintilla
Feature [feature-requests:#184]. Add option to disable drag/drop editing
-
Michael Heath created ticket #2497
Rectangular selection indent incorrect selection modes and positions
-
@nyamatongwe here is my updated patch, with the fix for the cursor, preventing dropping into Scintilla when drag-and-drop is disabled, and a unit test. Thanks for your review!
-
Undo added text at end of document
-
Undo added text at end of document
-
Committed fix with [7a533d]. Code is different from above to emphasize that the pos-1 branch is the unusual case.
-
Neil committed [7a533d] on Scintilla
Bug [#2491]. Fix lexing after undo at end of document.
-
PRIMARY selection gets filled, when search matches are marked
-
Yes, found text is selected and thus becomes the primary selection. This is behaving as intended.
-
Jaleks created ticket #2496
PRIMARY selection gets filled, when search matches are marked
-
Segfault when destroying ScintillaDocument [Qt]
-
Committed as [04be64].
-
Stefan Löffler committed [04be64] on Scintilla
Bug [#2495]. Fix crash when using ScintillaDocument object.
-
Neil committed [f93d1c] on SciTE
Fix indentation.
-
Neil committed [a9cf5a] on SciTE
Updates from Lexilla and Scintilla.
-
Qt: const qualifiers
-
Committed as [2e1151].
-
Stefan Löffler committed [2e1151] on Scintilla
Bug [#2494]. Add const to ScintillaDocument and ScintillaEdit methods.
-
Stefan Löffler created ticket #2495
Segfault when destroying ScintillaDocument [Qt]
-
Qt: const qualifiers
-
Update perl.properties keywords list
-
Committed with [082bee].
-
Neil Hodgson committed [cd7b96] on SciTE
Fix include path to avoid cppcheck warnings.
-
Neil committed [db5e93] on SciTE
Remove old comment that is no longer accurate.
-
Peter C. Jones committed [082bee] on SciTE
Feature [feature-requests:#1574]. Update Perl keywords for Perl 5.42.
-
Michael Heath committed [b66439] on SciTE
Added escape sequence suport as escseq.
-
GCC 15/Qt - ScintillaTypes.h: error: ‘intptr_t’ does not name a type
-
Committed with [0b6476]. Original issue was [#2458].
-
Stefan Löffler committed [0b6476] on Scintilla
Bug [#2493]. Add include of cstdint to provide intptr_t and uintptr_t.
-
Change is [c7ffad].
-
GCC 15/Qt - ScintillaTypes.h: error: ‘intptr_t’ does not name a type
-
pryrt created ticket #1574
Update perl.properties keywords list
-
Unable to type certain characters on non US keyboards/IME on macOS app using Scintilla
-
Bolsw created ticket #2492
Unable to type certain characters on non US keyboards/IME on macOS app using Scintilla
-
Committed as [ed808b], [490e80].
-
Zufu Liu committed [490e80] on Scintilla
Small optimization avoids retrieving font ascent twice.
-
Zufu Liu committed [ed808b] on Scintilla
Feature [feature-requests:#1571]. Improve determination of monospace.
-
The goal without change how aveCharWidth is measured is change how monospaceASCII is computed. Patch changed monospaceASCII to (maxWidth - minWidth)/minWidth < monospaceWidthEpsilon => (maxWidth - minWidth) < minWidth * monospaceWidthEpsilon, as minWidth is used to render ASCII characters.
1 >
