gmane.editors.scite.general

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

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

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 fo

Sass highlight syntax sass.properties

Huynh Cao Ky — 2013-05-11T05:53:33

Hi,

Does anyone have sass.properties or build it?
Please share if you have it. 
Thanks!