gmane.comp.lib.scintilla.devel

Line wrapping changes

Neil Hodgson — 2013-06-18T05:25:08

   There are some inefficiencies in the line wrapping code with lines outside the wrap-needed range being wrapped and lines being wrapped multiple times. Some improvements were just committed that should optimise the more common cases. In particular, most typing or deletion within a line should only cause that line to be rewrapped.

   A bug was introduced earlier this year that led to lines being wrapped shorter than they should and this has been fixed.

   The change sets are
http://sourceforge.net/p/scintilla/code/ci/9df53cc033e271f72fa37095a3f23f8aa3fa8006/
http://sourceforge.net/p/scintilla/code/ci/3e8191a68112e2b2cfbd7c5f5d2fab42fa70858c/
http://sourceforge.net/p/scintilla/code/ci/7bd094bcb7bada19de54aec108b50ba25e03d395/

   Its possible that there are new bugs in these changes so watch out for painting and wrapping problems.

   Neil

Re: Last (sub)-line in document displayed repetitively with word wrap

Neil Hodgson — 2013-06-11T02:40:20

Florian Balmer:


   OK. committed to Hg.

   For anyone that spots regressions in wrap mode, please report them.

   Neil

Re: Last (sub)-line in document displayed repetitively with word wrap

Florian Balmer — 2013-06-07T17:48:07

Thank you very much for the quick update, it works fine!

I don't have the power to see if it affects any other code paths, so far I 
haven't seen any side effects, at least.

--Florian

Re: Last (sub)-line in document displayed repetitively with word wrap

Neil Hodgson — 2013-06-06T00:34:19

Florian Balmer:

   The contraction state object wasn't correctly synchronized to the lines. Here is a potential patch but it may affect other code paths:

diff -r 6a2f299a13b1 src/Editor.cxx
--- a/src/Editor.cxx    Wed Jun 05 22:39:05 2013 +1000
+++ b/src/Editor.cxx    Thu Jun 06 10:28:37 2013 +1000
< at >< at > -4742,6 +4742,8 < at >< at >
             // Update contraction state for inserted and removed lines
             // lineOfPos should be calculated in context of state before modification, shouldn't it
             int lineOfPos = pdoc->LineFromPosition(mh.position);
+            if (mh.position > pdoc->LineStart(lineOfPos))
+                lineOfPos++;    // Affecting subsequent lines
             if (mh.linesAdded > 0) {
                 cs.InsertLines(lineOfPos, mh.linesAdded);
             } else {

   Neil

Last (sub)-line in document displayed repetitively with word wrap

Florian Balmer — 2013-06-05T19:46:33

I'd like to report an issue posted to me by a mindful user of Notepad2. I'm 
able to reproduce the problem with SciTE 3.3.3 on Windows (any version, 
Direct2D disabled):

1. Create a new document in SciTE
2. Enable word wrap (Options, Wrap)
3. Type some text, until the line is long enough to get wrapped
4. Insert two line breaks (hit Enter twice)
5. Type a shorter line of text (that won't wrap)
6. Move the caret to the end of the wrapped line typed in step 3
7. Hit Delete twice to join the two lines
8. Hit Ctrl+Z to undo the last action

The last (short) line is now visible two or more times (possibly depending 
on the number of sub-lines ("display lines") occupied by the longer, 
wrapped line typed in step 3). Once the text is modified again, the SciTE 
window is resized, or the word wrap option is changed, anything is fine, so 
this seems to be a display-only problem.

The problem does not appear if the shorter line typed in step 5 is not at 
the end of the document (i.e. followed by at least one line break). If the 
shorter line from step 5 is long enough to be wrapped, too, only the last 
sub-line will be repeated.

--Florian

Does anyone use Digital Mars C++?

Neil Hodgson — 2013-06-05T10:06:43

   There are some conditionally compiled sections of ScintillaWin.cxx that work around some problems with Digital Mars C++ from 11 years ago. Its likely that Digital Mars now supports the Imm32 library (needed for Asian language input) and zmouse.h header (mouse wheel definitions) so it should be possible to remove these preprocessor checks.

   If anyone is using Digital Mars C++, could you please try inverting the __DMC__ checks to see if they are still needed. If this is OK or no one responds then I'll remove the checks for DMC.

   Neil

Re: Font smoothing on OS X

Neil Hodgson — 2013-06-05T09:07:48

   Me:


   This change has now been committed.

   Neil

Scintilla 3.3.3 released

Neil Hodgson — 2013-06-02T01:01:53

   Scintilla 3.3.3 is now available from the scintilla.org web site.

   Scintilla 3.3.3 is a bug fix release, mostly for the GTK+ platform. The previous release 3.3.2 contained bugs with copy, paste and drag and drop leading to invalid memory reads and spurious characters.

   Other changes were made and bugs fixed. A detailed list of changes is available on the history page.
http://www.scintilla.org/ScintillaHistory.html

   Scintilla uses Mercurial (Hg) for source code control. The repository can be cloned with
hg clone http://hg.code.sf.net/p/scintilla/code scintilla

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

   Neil

Re: SetBufferedDraw(false) removes additional selection indication (and some other indicators) on OSX (Scintilla 3.2.3)

Neil Hodgson — 2013-05-31T05:36:28

   This should be reported to the wxStyledTextCtrl maintainers.

   Neil

Re: SetBufferedDraw(false) removes additional selection indication (and some other indicators) on OSX (Scintilla 3.2.3)

Paul K — 2013-05-31T05:22:59

Neil:
 
I did find the fragment you referenced in cocoa/ScintillaCocoa.mm. There 
are only two places (and both set bufferedDraw to false). I don't have 
anything similar to that file in wxSTC, but I did set the default value to 
"false" as you have and recompiled the component to see if this makes any 
difference (I thought maybe the initialization order matters).
 
Unfortunately the result is the same: the default value is "false" now, but 
some of the indicators are still missing. Not sure what else to check.
 
Paul.

On Thursday, May 30, 2013 8:38:36 PM UTC-7, Paul K wrote:

Re: SetBufferedDraw(false) removes additional selection indication (and some other indicators) on OSX (Scintilla 3.2.3)

Paul K — 2013-05-31T03:38:36

Neil:
 
wxStyledTextCtrl instead of the native implementation. wxWidgets may not 
have implementations for translucency or may differ in the way the alpha 
value is interpreted: possibly making it less visible.
I indeed use wxSTC, but the interesting thing is that I can get the colors 
(including transparency) to work just find as long as I don't turn the 
buffering off.
 
I'm attaching three snapshots that show how it looks:
1. The first snapshot (-default) is taken when the app just starts. I 
disabled any explicit setting of BufferedDraw and 
GetBufferedDraw reports "true", so it seems to be on. everything 
works/looks correctly.
 
2. The second snapshot is after I run SetBufferedDraw(false) (-false). 
Nothing is visibly changed, but if I move the cursor to those lines that 
have ROUNDBOX indicators, those indicators disappear. They don't reappear 
in any subsequent redrawing. As you can see, other indicators are still on 
and not affected.
 
3. The third snapshot is after I run SetBufferedDraw(true) (-true). Again, 
after the screen is refreshed, everything is back to normal.
 
Couple of other things. I don't see the fragment you references in the 
Scintilla version I have. It turned out to be 3.2.1 and the fragment that 
sets bufferedDraw looks like this:
 
 case SCI_SETBUFFEREDDRAW:
  bufferedDraw = wParam != 0;
  break;
This is in Editor.cxx; or do I look in the wrong place?
 
The other thing is that the text looks a bit crispier with BufferedDraw set 
to false, even though I'm using a regular (not Retina) screen.
 
In any case, -default and -true screenshots show that there is no issue 
with displaying indicators with alpha properties. And yet when BufferedDraw 
is false, all indicators that have any alpha property disappear (whether 
it's ROUNDBOX or AdditionalSelection). This doesn't seem to be 
wxwidgets/wxSTC specific issue (at least as far as I can tell). Thank you 
for looking into this. 
 
Paul.

Re: SetBufferedDraw(false) removes additional selection indication (and some other indicators) on OSX (Scintilla 3.2.3)

Neil Hodgson — 2013-05-31T00:41:10

Paul K:


   Looked through your posting history and it appears you are using wxStyledTextCtrl instead of the native implementation. wxWidgets may not have implementations for translucency or may differ in the way the alpha value is interpreted: possibly making it less visible.

   Neil

Re: SetBufferedDraw(false) removes additional selection indication (and some other indicators) on OSX (Scintilla 3.2.3)

Paul K — 2013-05-31T00:28:38

Neil:
 
platform used and the colour chosen. Setting 
selection.additional.back=#0000FF in SciTE shows additional selections as a 
light blue on my main MacBook display (a Dell 2005FPW) but its less intense 
on the built-in screen. Choose a colour and level of alpha that works for 
you.
 
Right; everything looks/works as expected as long as I don't call 
"SetBufferedDraw(false)".
 
Its initialised to false and the code responding to the call looks like 
this:
 
This is very strange. I can clearly call it with "SetBufferedDraw(true)" 
and indicators come back as they should be; I call "SetBufferedDraw(false)" 
and they disappear. I have a console in my application, so I can make these 
calls without restarting the app, so I can see the immediate effect.
 
Based on what you are saying, it shouldn't make any difference, right? This 
is all running on a *regular* MacBookPro (not Retina) with OSX 10.7.4. Any 
idea what may be going on?
 
Paul.

On Thursday, May 30, 2013 5:07:03 PM UTC-7, Neil Hodgson wrote:

Re: SetBufferedDraw(false) removes additional selection indication (and some other indicators) on OSX (Scintilla 3.2.3)

Neil Hodgson — 2013-05-31T00:07:03

Paul K:


    The visibility of translucent features will depend on the display and platform used and the colour chosen. Setting selection.additional.back=#0000FF in SciTE shows additional selections as a light blue on my main MacBook display (a Dell 2005FPW) but its less intense on the built-in screen. Choose a colour and level of alpha that works for you.


   Buffered drawing is supposed to be permanently off on Cocoa since 2.28. Its initialised to false and the code responding to the call looks like this:
    case SCI_SETBUFFEREDDRAW:
      // Buffered drawing not supported on Cocoa
      bufferedDraw = false;
      break;

   Neil

SetBufferedDraw(false) removes additional selection indication (and some other indicators) on OSX (Scintilla 3.2.3)

Paul K — 2013-05-30T19:00:21

Neil:
 
I just noticed that I don't see any color on additional selections on OSX 
(Scintilla 3.2.3). On Windows the same code shows the same selection by 
default and when I adjust SetAdditionalSelAlpha I get a proper change in 
additional selection.
 
It turned out to be related to SetBufferedDraw(false) call I added on OSX 
to enable Retina support. When I set it to false, I see additional 
selection indication disappearing as well as some other indicators 
disappearing (for example, INDIC_ROUNDBOX); other indicators (PLAIN, DOTS, 
DASH) don't seem to be affected.
 
Is this a known issue? Is there a workaround?
 
Paul.

Re: Getting Re-Acquainted with Scintilla

Florian Balmer — 2013-05-29T15:39:17

I have been adapting my software to the most recent version of Scintilla 
for years, now, and I really appreciate the fact that everything remained 
compatible!

The only major change I remember to require some more fine tuning was the 
concept of multiple selections (and carets). Rectangular selections were 
now represented by multiple selections, and if multiple carets were not to 
be allowed, they had to be explicitly disabled for rectangular selections. 
Yet I think these changes happened before 2010 ...

--Florian

Re: DirectWrite bug in 3.0.2 pre-release

Neil Hodgson — 2013-05-28T13:58:31

Greg:


   As a proof of concept, you can just munge the Scintilla code heavily. Remove the current window handling in ScintillaWin and splice it into an MFC shell. It should be possible to only implement a few methods to get drawing working.

   Then try to refactor so that minimal changes are needed to ScintillaWin - maybe some way to pass the render target into WndPaint.

   Neil

Re: DirectWrite bug in 3.0.2 pre-release

Greg — 2013-05-28T13:45:34

I realise that to make any sense of the previous post, I need to explain 
that a CSciCtrl is a CWnd descendent that wraps up a SciDirect pointer. The 
ScriCtrl::Create(...) holds:

BOOL CSciCtrl::Create(DWORD dwStyle, const RECT& rect, CWnd* pParentWnd, 
UINT nID,
                                          DWORD dwExStyle, LPVOID lpParam) 
{
    if ((m_hModScintilla == NULL) &&         // if first user...
        !InitScintilla())                                   // ...load the 
Scintilla DLL
        return FALSE;
    BOOL bOK = CreateEx(dwExStyle, _T("scintilla"), NULL, dwStyle, rect, 
pParentWnd, nID, lpParam);
    if (bOK)            // if all was OK we can now send messages to the 
window
    {
        ASSERT(::IsWindow(m_hWnd));                         // moan if we 
failed
        m_pSciDirect = (SciFnDirect)SendMessage(SCI_GETDIRECTFUNCTION);  // 
get address to use
        m_pSciData = SendMessage(SCI_GETDIRECTPOINTER);     // get our 
instance data pointer
 #ifdef SCI_USED2D
        EnableD2DSupport();
        if (IsD2DSupportEnabled())
            SetTechnology(SC_TECHNOLOGY_DIRECTWRITE);       // attempt to 
set direct write
        if (GetTechnology() == SC_TECHNOLOGY_DIRECTWRITE)   // if using 
DirectWrite
        {
            SetBufferedDraw(false);                         // probably 
right
            SetTwoPhaseDraw(false);
        }
#endif

        SetFontQuality(SC_EFF_QUALITY_LCD_OPTIMIZED);       // and best 
quality font
    }
    return bOK;
}

The rest of the class is there to turn the scintilla messages into member 
functions and convenience functions. To blend the MFC code with the 
scintilla control we need to get scintilla to use the CHwndRenderTarget we 
get from the AFX_WM_DRAW2D registered message... then there is a chance 
that the GDI and D2D painting will be proprely sequenced.

Re: DirectWrite bug in 3.0.2 pre-release

Greg — 2013-05-28T12:20:39

I do have VS2012 and have done a bit more digging. It looks like to make 
this work in an MFC app (or in any app that is using GDI) there is more 
syncing work to be done. In MFC, it seems that you must call 
CWinApp::EnableD2DSupport() and also call CWnd::EnableD2DSupport() for the 
window itself. Then they add:

    afx_msg LRESULT OnDraw2D(WPARAM wParam, LPARAM lParam); // in the header


BEGIN_MESSAGE_MAP(CSciCtrl, CWnd)
    ON_REGISTERED_MESSAGE(AFX_WM_DRAW2D, &CSciCtrl::OnDraw2D)
END_MESSAGE_MAP()

afx_msg LRESULT CSciCtrl::OnDraw2D(WPARAM wParam, LPARAM lParam)
{
    CHwndRenderTarget* pRenderTarget = (CHwndRenderTarget*)lParam;
    ASSERT_VALID(pRenderTarget);
    ...your code in here to render...
    return TRUE;
}

I guess that this is tried before the CWnd::OnPaint()...

This seems to be saying that to make this work, MFC must handle the render 
target so that it can arbitrate between the various items that are 
attempting to update it. Unless you can suggest a simple method to link 
this into the underlying Scintilla D2D rendering I think I will just have 
to live with the GDI rendering (at least until I have a lot more time to 
look at this).

The code suggested here is available on the Web, but there seems very 
little help for people trying to do this.

Changes to text selection, copy/paste, and drag'n'drop. Change will impact platform layers.

Neil Hodgson — 2013-05-26T10:05:53

   There are some problems on GTK+ with text selection for the 3.3.2 release with crashes easily produced on Windows and access outside memory bounds on Linux. These were dues to recent changes which omitted NUL terminators in some cases. Some fixes for these have been committed.

   To try to simplify selection handling, the SelectionText class is now using a std::string to hold the text and access methods are used to reach this text. The API of SelectionText has changed which will require changes to platform layers maintained by other people. All the core platform layers have been updated. This change is here:
http://sourceforge.net/p/scintilla/code/ci/46b68a5a53ea8c7fea44fd3119601a8559014613/
   Since SelectionText:: FixSelectionForClipboard uses std::replace, files that include Editor.h should now #include <algorithm>.

   The cut, copy, paste and drag & drop operations are very common but include optional conversions of encoding and line ends, so there is a good chance I haven't tested all possibilities. If others could check out and run the code, it would help ensure the next version is less buggy than 3.3.2.

   Since there are crashing bugs in 3.3.2, its likely I'll make a new release in around a week if no further problems are found.

   Neil

Re: Getting Re-Acquainted with Scintilla

Neil Hodgson — 2013-05-25T23:26:43

Gary Beene:


   It should be compatible. Version 3 was mostly about platform churn. Sub-pixel positioning is used on some platforms but isn't really exposed through the API. If you are writing a lexer and want to store extra state about the document then it can be written as an object lexer.

   Neil