gmane.editors.scite.general

Re: [scintilla] Release 3.3.2 next week

Neil Hodgson — 2013-05-19T13:00:27

   There were some problems with Japanese language input on OS X 10.6. One was for a call that is only available on OS X 10.7+ so there is a workaround for that using an old call that is deprecated in 10.7.

   The others were in platform-independent code so could affect other platforms. The second problem was reading from a NULL pointer - in the previous version this read beyond the end of a zero-length allocation. The third was in failing to display a Japanese character at the start of a line and was caused by a mistake in converting to using a std::vector.

   A folding bug was fixed for Haskell.

   Available from the Mercurial repositories:
hg clone http://hg.code.sf.net/p/scintilla/code scintilla
hg clone http://hg.code.sf.net/p/scintilla/scite
   and from
http://www.scintilla.org/scite.zip  Source
http://www.scintilla.org/wscite.zip Windows executable

   Neil

Re: Release 3.3.2 next week

Neil Hodgson — 2013-05-17T06:59:12

Ashwin Hirschi:


   The first thing it does is to unconditionally show all lines. SciTE finds all top level fold headers and recursively shows their children.


   The SciTE code was written to allow more features like showing all of the top two levels of folds but that was never implemented. I wanted a slider on the toolbar that could be moved to show progressive levels of detail. 

   Neil

Re: Release 3.3.2 next week

Ashwin Hirschi — 2013-05-17T04:52:03

Yes, it works fine now.

Btw, I'm also pleased to see that editor:FoldAll(2) expands (much) quicker 
than the old toggle-all command (from the View menu) does. Though I haven't 
checked, I suspect that the menu command doesn't suppress some UI updates. 

On my machine the scrollbar sometimes got insanely busy when expanding a 
file with several hundred top level folds... Using the new folding method 
fixes this. Now expansion is near-instantaneous. Nice!

Ashwin.

Re: Release 3.3.2 next week

Neil Hodgson — 2013-05-17T04:00:31

Ashwin Hirschi:


   Thanks. It was trying to show a line 1 beyond the file end and errored out.

   Fixes committed and uploaded.

   Neil

Re: Release 3.3.2 next week

Ashwin Hirschi — 2013-05-17T00:55:23

I noticed several new folding methods in the Pane API. Since new arrival 
FoldAll only has an action parameter, I half-expected editor:FoldAll(2) to 
act like the Toggle-all-folds command. But, although contraction seem to 
work fine, expansion only changes the plus signs in the fold margin into 
minus ones. 

Is this the intended behaviour?

Ashwin.

Re: Release 3.3.2 next week

Neil Hodgson — 2013-05-16T23:11:46

A pre-release of 3.3.2 can now be tried.

Please report any regressions from 3.3.1.

Change list:
Basic implementations of common folding methods added to Scintilla to make it easier for containers to implement folding.
Add indicator INDIC_COMPOSITIONTHICK, a thick low underline, to mimic an appearance used for Asian language input composition.
On Cocoa, implement font quality setting. Feature #988.
On Cocoa, implement automatic enabling of commands and added clear command. Feature #987.
C++ lexer adds style for preprocessor doc comment. Feature #990.
Haskell lexer and folder improved. Separate mode for literate Haskell "literatehaskell" SCLEX_LITERATEHASKELL. Bug #1459 .
LaTeX lexer bug fixed for Unicode character following '\'. Bug #1468 .
PowerShell lexer recognises here strings and doccomment keywords. #region folding added. Feature #985.
Fix multi-typing when two carets are located in virtual space on one line so that spaces are preserved.
Fixes to input composition on Cocoa and implementation of accented character input through press and hold. Set selection correctly so that changes to pieces of composition text are easier to perform. Restore undo collection after a sequence of composition actions. Composition popups appear near input.
Fix lexer problem where no line end was seen at end of document.
Fix crash on Cocoa when view deallocated. Bug #1466.
Fix Qt window positioning to not assume the top right of a monitor is at 0, 0.
Fix Qt to not track mouse when widget is hidden.
Qt now supports Qt 5.0. Bug #1448.
Fix drawing on Windows with Direct2D when returning from lock screen. The render target had to be recreated and an area would be black since the drawing was not retried.
Fix display of DBCS documents on Windows Direct2D/DirectWrite with default character set.
For SciTE on Windows, fixed most-recently-used menu when files opened through check.if.already.opened.
In SciTE, do not call OnSave twice when files saved asynchronously.
Scintilla no longer builds with Visual C++ 6.0.
Available from the Mercurial repositories:
hg clone http://hg.code.sf.net/p/scintilla/code scintilla
hg clone http://hg.code.sf.net/p/scintilla/scite
and from
http://www.scintilla.org/scite.zip Source
http://www.scintilla.org/wscite.zip Windows executable

Neil

Re: Search in selection?

Philippe Lhoste — 2013-05-16T08:16:09

You can create new properties in Lua:

props['LuaInfoMessage'] = message

I use the above to create a custom property to display in the status bar, for example...

statusbar.text.1=\
Various things and \
$(LuaInfoMessage)

Re: Re: Search in selection?

Pablo Baena — 2013-05-15T13:19:10

Yes, I even tried to write some script to do it by using StripShow but
lacking static variables to store the selection is a problem, since setting
CurrentPos or using GotoPos clear the selection.



On Wed, May 15, 2013 at 7:42 AM, Philippe Lhoste <PhiLho< at >gmx.net> wrote:

Re: Search in selection?

Philippe Lhoste — 2013-05-15T10:42:07

What this script would do?
In standard search, the found string is selected, so it would lost the current selection 
and you would no be able to search further, unless the script saves the information (line 
range?) somewhere.

Re: Complete list of keyboard shortcuts

Neil Hodgson — 2013-05-14T22:47:18

Ben Fisher:


   There are also keys built into Scintilla found in KeyMap::MapDefault in scintilla/src/KeyMap.cxx.

   Neil

Re: What is the default Character Set if character.set=0?

Neil Hodgson — 2013-05-14T22:36:39

trismarck:


   In the important case, displaying text, SciTE doesn't determine the default character set but tells Windows to use the default character set. When creating a font to display characters, one of the parameters, lfCharSet is set to this value. SC_CHARSET_DEFAULT -> DEFAULT_CHARSET.
http://msdn.microsoft.com/en-us/library/windows/desktop/dd145037%28v=vs.85%29.aspx


   Whatever it is set to by Windows.


   The default character set is not determined in SciTE. There is some encoding discovery performed in CodePageFromCharSet.


   The default value is SC_CHARSET_DEFAULT.

   Neil

Search in selection?

tetsuo — 2013-05-14T22:01:27

Hello. I would like to be pointed to a Lua script to make a "search in selection". That functionality is present in the "Replace" function, but it only works for replacing. I would like to find stuff in a selection and wrap around the search while in it.

Thank you.

What is the default Character Set if character.set=0?

trismarck — 2013-05-14T13:04:15

Hello,

I have a question about the default Character Set that Scite uses when it 
opens a text file w/o the Unicode BOM (or w/o any other indication, what 
the character encoding of the text file is).
There is a setting in File: Encoding, that is called "Code Page Property". 
I've found out that this option maps to the code.page setting in the 
SciTEGlobal.Properties file (Options: Open Global Properties). What I have 
set there is: code.page=0, which means that, to display the contents of the 
text file, a _single_-byte code page will be used. 
On this newsgroup I've found the information that the code.page setting is 
actually only needed to determine, _how many bytes_ does each character in 
the text file translates to (I know there exist 'code pages' for which not 
every character maps to the same number of bytes), and not to set a 
particular character set. So, if code.page=0, then that means that each 
character in the text file is interpreted as a single byte.
The second setting is the character.set setting. This setting determines, 
what character set will be used to map the bytes (or byte sequences) in the 
file to the actual characters (characters that this character.set contains).
Now, the documentation tells me that the character.set=0 means the 
'Default' character set. This is the part where I get stuck - how does 
Scite determine, what is this 'default' character set? Does Scite use some 
Windows API call to i.e. determine the default code page of the OS? I've 
actually sifted through the source code and I've found out that, if Scite 
uses GTK+ or Qt, then the SC_CHARSET_DEFAULT preprocessor directive (see 
Scintilla.h) maps to 0, which maps to ISO-8859-1 (see CharacterSetID() 
function in PlatGTK.cxx and PlatQt.cxx). But, I'm not sure if the same 
happens on Windows - I couldn't find the function that would tell me, how 
the default character set is determined if Scite uses Windows controls. In 
ScintillaWin.cxx I've found the CodePageFromCharset() function that takes 
the VisualStyle object that has the Style subobject and this Style 
subobject has the .characterset property defined, but I can't figure out, 
how is this property set (or this property is actually relevant to my 
original question) if Scite uses Windows controls.

So the questions I have:
1. What is the default Character Set if character.set=0? (if Scite uses 
Windows controls)
2. What is the function is the Scite source code that determines, what is 
the default Character Set? (is this just a fixed setting or does Scite use 
Windows API calls? (and if it uses those calls, where can I find them in 
the code) )
3. How is the .characterset property of the Style subobject of the 
VisualStyle object set by default (and is this at all relevant to what I'm 
asking about).

What I want to do is to roughly understand, how does the text editor use a 
given character encoding to read a text file / display the characters that 
it has read from the text file. Especially, to test this, I need to know 
exactly, what character set Scite used to encode characters to the file 
(characters -> byte sequences).

Cheers and sorry for the long post.

Re: Caret invisible after toggling all folds twice

Ashwin Hirschi — 2013-05-14T16:36:31

lines whatsoever* in common with the view before. Do you (or anyone else, 
for that matter) find Scite's current behaviour helpful? Or do we agree 
there's room for improvement? 

not consistent with opening a single fold. 

Fair enough.


margin to use the cursor location where the command was performed as that 
line should be the focus. 

I think these two changes would improve things a lot.

Ashwin.

Re: Complete list of keyboard shortcuts

Ben Fisher — 2013-05-14T15:52:17



I updated the script, and posted to my blog at
http://halfhourhacks.blogspot.com/2013/05/keyboard-shortcuts-for-scite-code-editor.html

Let me know if it works!
Since I've been adding many commands, it will be a useful script for me, 
too.

-Ben

Re: Caret invisible after toggling all folds twice

Neil Hodgson — 2013-05-13T23:49:23

Ashwin Hirschi:


   I think it could be improved but moving to the caret is jarring and is not consistent with opening a single fold.


   That would be my preference.

   Another would be, when performing this through Ctrl+Shift+Click in fold margin to use the cursor location where the command was performed as that line should be the focus.

   Neil

Re: Caret invisible after toggling all folds twice

Ashwin Hirschi — 2013-05-13T23:41:12

Well, at the moment the view after a toggle-all-folds often has *no lines 
whatsoever* in common with the view before. Do you (or anyone else, for 
that matter) find Scite's current behaviour helpful? Or do we agree there's 
room for improvement?

Having said that, I think it may be quite tricky to come up with a 
mechanism that satisfactorily keeps the view as-is when the range of 
visible document lines changes so drastically (by either opening or closing 
all folds)... 

Should the top line remain visible? The bottom one? What if the user was 
really looking at the section in the middle?

If the user just opened all folds, depending on the answer above, you're 
quite likely looking at completely different sections of the file they are 
editting. So, what's the right choice?

In other words, what does it even mean to keep the view "where it is" after 
opening all folds?

Ashwin.

Re: Caret invisible after toggling all folds twice

John Yeung — 2013-05-13T23:00:40

On Mon, May 13, 2013 at 6:44 PM, Ashwin Hirschi
<ashwin.hirschi< at >gmail.com> wrote:

The fact that you think positioning by caret is going to work for my
examples.  I specifically laid out scenarios in which that would be
quite jarring.


Your proposal to "fix" this is to automatically move the view to the
caret.  What I am saying is that I don't want the view to
automatically move to the caret.  I want the view to stay the hell
where it is.

John

Re: Caret invisible after toggling all folds twice

Ashwin Hirschi — 2013-05-13T22:44:47

I read them just fine. What gives you the idea I did not?


Right. And like I wrote, using the Toggle all folds command *does* change 
the view at the moment. 

Are you suggesting it is not? If so, please try it out for yourself. With 
any file that holds substantially more top-level folds than lines that can 
be displayed at once, you often end up looking at something completely 
unrelated to what you were viewing before the toggle-all.

I think that fact alone shows there's room for improvement here.


I'm not baffled by an editor showing me where new text will go.

Ashwin.

Re: Caret invisible after toggling all folds twice

John Yeung — 2013-05-13T21:57:52

On Mon, May 13, 2013 at 2:24 PM, Ashwin Hirschi
<ashwin.hirschi< at >gmail.com> wrote:

It seems you didn't read my examples at all.

The important thing is not to put the view where the caret is; it's to
keep the view unchanged, whether it happens to be on the caret or not.

Your proposal potentially violates both of your "rules" (by not
preserving the state of the view and by bewildering the user).

John

Re: Caret invisible after toggling all folds twice

Ashwin Hirschi — 2013-05-13T18:24:19

There are several possible rules to stick to for an editor. I agree that 
keeping the view "as stable as possible" is one of them. Never baffling the 
user is another.

The way I see it, the command to toggle the *current* fold works fine. It 
seems to adhere to both the above rules. But... the toggle *all* folds 
command *breaks* them both! Which is why I feel changing its behaviour 
would improve things (a lot).

In fact, I now realise I could have left off the "twice"-bit in the post 
subject: 

Starting out with a large enough file (with all folds opened) you generally 
end up looking at something ("random") near the bottom of the file after 
the first toggle-all. A subsequent toggle-all to open all folds then moves 
the view near the top...

In both cases (i.e. after closing and after opening all folds) the user 
basically ends up staring at something that's completely unrelated to the 
initial view. Don't take my word for it. Please try it out (using a 
sufficiently large file, with enough top-level folds).

There's another way to look at the toggle-all-folds command. When exactly 
are people using it? And how can this best be accommodated?

Personally, I use it on 2 occasions. The first is to get my bearings within 
a large file. Here I am basically asking myself: what's around here? So, I 
use the toggle-all-folds commands twice, and then I'd like to be done (i.e. 
back where I was). 

My second use-case is to move to something that's related/nearby. I use the 
toggle command once, then move the caret to where I want to be, and finally 
trigger the toggle-all command a second time to continue working.

Others may have different uses for the toggle-all command. But the 2 
scenario's above should explain why I think a call to scroll-caret (at the 
end of FoldAll) does make sense.

Leaving things as they are, seems undesirable. What's the advantage of 
looking at a "random" view on your file after a toggle-all-folds?

Ashwin.