<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.editors.scite.general">
    <title>gmane.editors.scite.general</title>
    <link>http://permalink.gmane.org/gmane.editors.scite.general</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.editors.scite.general/14290"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.editors.scite.general/14289"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.editors.scite.general/14288"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.editors.scite.general/14287"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.editors.scite.general/14286"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.editors.scite.general/14285"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.editors.scite.general/14284"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.editors.scite.general/14283"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.editors.scite.general/14282"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.editors.scite.general/14281"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.editors.scite.general/14280"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.editors.scite.general/14279"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.editors.scite.general/14277"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.editors.scite.general/14276"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.editors.scite.general/14275"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.editors.scite.general/14274"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.editors.scite.general/14273"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.editors.scite.general/14272"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.editors.scite.general/14271"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.editors.scite.general/14270"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.editors.scite.general/14290">
    <title>SciTE 3.3.2 released</title>
    <link>http://permalink.gmane.org/gmane.editors.scite.general/14290</link>
    <description>&lt;pre&gt;   SciTE 3.3.2 is now available from the scintilla.org web site.

   SciTE 3.3.2 is a minor bug fix release.

   Bugs fixed with multi-typing in virtual space.

   On Windows, a problem with Direct2D/DirectWrite (technology=1) was fixed and Asian DBCS encodings work with Direct2D.

   OnSave no longer called twice when files saved asynchronously.

   There are several fixes on OS X. Most importantly, the quarantine attribute should no longer be applied to files saved from SciTE or its subprocesses making it easier to compile and run programs. Input composition of accented and Asian characters improved. Release awaits Apple review which has been taking around a week.

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

   SciTE uses Mercurial (Hg) for source code control. The repositories can be cloned with
hg clone http://hg.code.sf.net/p/scintilla/code scintilla
hg clone http://hg.code.sf.net/p/scintilla/scit&lt;/pre&gt;</description>
    <dc:creator>Neil Hodgson</dc:creator>
    <dc:date>2013-05-22T00:14:46</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.editors.scite.general/14289">
    <title>Re: SciTE search problems</title>
    <link>http://permalink.gmane.org/gmane.editors.scite.general/14289</link>
    <description>&lt;pre&gt;Dmitry Konstantinov:


   Try to find a document and search example that will reliably show the problem then upload the document and describe all the search parameters used. Remove all changed settings and restart to see if a setting has caused the problem.

   Isolate the problem versions: does SciTE 3.3.0 never show the problem on this installation? The only change that seems relevant from 3.3.0-&amp;gt;3.3.1 was to regular expression search in DBCS (Asian) encodings.

   Pre-release 3.3.2 source code is available so could be checked if you are OK with building it:
http://www.scintilla.org/scite.zip

   Neil


&lt;/pre&gt;</description>
    <dc:creator>Neil Hodgson</dc:creator>
    <dc:date>2013-05-21T13:31:05</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.editors.scite.general/14288">
    <title>SciTE search problems</title>
    <link>http://permalink.gmane.org/gmane.editors.scite.general/14288</link>
    <description>&lt;pre&gt;Hi!

I have SciTE 3.3.1 on Ubuntu 12.10, KDE. I often have problem: SciTE
frezzes on text search, do not answer on any action and in top it get 100%
cpu. Prev versions i don't see such problem.

What information i need to get from my pc next time, to detect where is
problem: scite, scintilla or environment code and make bug report?

Thank you.

&lt;/pre&gt;</description>
    <dc:creator>Dmitry Konstantinov</dc:creator>
    <dc:date>2013-05-21T12:55:10</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.editors.scite.general/14287">
    <title>Re: [scintilla] Release 3.3.2 next week</title>
    <link>http://permalink.gmane.org/gmane.editors.scite.general/14287</link>
    <description>&lt;pre&gt;   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

&lt;/pre&gt;</description>
    <dc:creator>Neil Hodgson</dc:creator>
    <dc:date>2013-05-19T13:00:27</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.editors.scite.general/14286">
    <title>Re: Release 3.3.2 next week</title>
    <link>http://permalink.gmane.org/gmane.editors.scite.general/14286</link>
    <description>&lt;pre&gt;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

&lt;/pre&gt;</description>
    <dc:creator>Neil Hodgson</dc:creator>
    <dc:date>2013-05-17T06:59:12</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.editors.scite.general/14285">
    <title>Re: Release 3.3.2 next week</title>
    <link>http://permalink.gmane.org/gmane.editors.scite.general/14285</link>
    <description>&lt;pre&gt;
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.

&lt;/pre&gt;</description>
    <dc:creator>Ashwin Hirschi</dc:creator>
    <dc:date>2013-05-17T04:52:03</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.editors.scite.general/14284">
    <title>Re: Release 3.3.2 next week</title>
    <link>http://permalink.gmane.org/gmane.editors.scite.general/14284</link>
    <description>&lt;pre&gt;Ashwin Hirschi:


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

   Fixes committed and uploaded.

   Neil

&lt;/pre&gt;</description>
    <dc:creator>Neil Hodgson</dc:creator>
    <dc:date>2013-05-17T04:00:31</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.editors.scite.general/14283">
    <title>Re: Release 3.3.2 next week</title>
    <link>http://permalink.gmane.org/gmane.editors.scite.general/14283</link>
    <description>&lt;pre&gt;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.

&lt;/pre&gt;</description>
    <dc:creator>Ashwin Hirschi</dc:creator>
    <dc:date>2013-05-17T00:55:23</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.editors.scite.general/14282">
    <title>Re: Release 3.3.2 next week</title>
    <link>http://permalink.gmane.org/gmane.editors.scite.general/14282</link>
    <description>&lt;pre&gt;   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&lt;/pre&gt;</description>
    <dc:creator>Neil Hodgson</dc:creator>
    <dc:date>2013-05-16T23:11:46</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.editors.scite.general/14281">
    <title>Re: Search in selection?</title>
    <link>http://permalink.gmane.org/gmane.editors.scite.general/14281</link>
    <description>&lt;pre&gt;
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)

&lt;/pre&gt;</description>
    <dc:creator>Philippe Lhoste</dc:creator>
    <dc:date>2013-05-16T08:16:09</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.editors.scite.general/14280">
    <title>Re: Re: Search in selection?</title>
    <link>http://permalink.gmane.org/gmane.editors.scite.general/14280</link>
    <description>&lt;pre&gt;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 &amp;lt;PhiLho&amp;lt; at &amp;gt;gmx.net&amp;gt; wrote:


&lt;/pre&gt;</description>
    <dc:creator>Pablo Baena</dc:creator>
    <dc:date>2013-05-15T13:19:10</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.editors.scite.general/14279">
    <title>Re: Search in selection?</title>
    <link>http://permalink.gmane.org/gmane.editors.scite.general/14279</link>
    <description>&lt;pre&gt;
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.

&lt;/pre&gt;</description>
    <dc:creator>Philippe Lhoste</dc:creator>
    <dc:date>2013-05-15T10:42:07</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.editors.scite.general/14277">
    <title>Re: Complete list of keyboard shortcuts</title>
    <link>http://permalink.gmane.org/gmane.editors.scite.general/14277</link>
    <description>&lt;pre&gt;Ben Fisher:


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

   Neil

&lt;/pre&gt;</description>
    <dc:creator>Neil Hodgson</dc:creator>
    <dc:date>2013-05-14T22:47:18</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.editors.scite.general/14276">
    <title>Re: What is the default Character Set if character.set=0?</title>
    <link>http://permalink.gmane.org/gmane.editors.scite.general/14276</link>
    <description>&lt;pre&gt;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 -&amp;gt; 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

&lt;/pre&gt;</description>
    <dc:creator>Neil Hodgson</dc:creator>
    <dc:date>2013-05-14T22:36:39</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.editors.scite.general/14275">
    <title>Search in selection?</title>
    <link>http://permalink.gmane.org/gmane.editors.scite.general/14275</link>
    <description>&lt;pre&gt;
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.

&lt;/pre&gt;</description>
    <dc:creator>tetsuo</dc:creator>
    <dc:date>2013-05-14T22:01:27</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.editors.scite.general/14274">
    <title>What is the default Character Set if character.set=0?</title>
    <link>http://permalink.gmane.org/gmane.editors.scite.general/14274</link>
    <description>&lt;pre&gt;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 &lt;/pre&gt;</description>
    <dc:creator>trismarck</dc:creator>
    <dc:date>2013-05-14T13:04:15</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.editors.scite.general/14273">
    <title>Re: Caret invisible after toggling all folds twice</title>
    <link>http://permalink.gmane.org/gmane.editors.scite.general/14273</link>
    <description>&lt;pre&gt;
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.

&lt;/pre&gt;</description>
    <dc:creator>Ashwin Hirschi</dc:creator>
    <dc:date>2013-05-14T16:36:31</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.editors.scite.general/14272">
    <title>Re: Complete list of keyboard shortcuts</title>
    <link>http://permalink.gmane.org/gmane.editors.scite.general/14272</link>
    <description>&lt;pre&gt;


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

&lt;/pre&gt;</description>
    <dc:creator>Ben Fisher</dc:creator>
    <dc:date>2013-05-14T15:52:17</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.editors.scite.general/14271">
    <title>Re: Caret invisible after toggling all folds twice</title>
    <link>http://permalink.gmane.org/gmane.editors.scite.general/14271</link>
    <description>&lt;pre&gt;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

&lt;/pre&gt;</description>
    <dc:creator>Neil Hodgson</dc:creator>
    <dc:date>2013-05-13T23:49:23</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.editors.scite.general/14270">
    <title>Re: Caret invisible after toggling all folds twice</title>
    <link>http://permalink.gmane.org/gmane.editors.scite.general/14270</link>
    <description>&lt;pre&gt;
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.


&lt;/pre&gt;</description>
    <dc:creator>Ashwin Hirschi</dc:creator>
    <dc:date>2013-05-13T23:41:12</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.editors.scite.general/14269">
    <title>Re: Caret invisible after toggling all folds twice</title>
    <link>http://permalink.gmane.org/gmane.editors.scite.general/14269</link>
    <description>&lt;pre&gt;On Mon, May 13, 2013 at 6:44 PM, Ashwin Hirschi
&amp;lt;ashwin.hirschi&amp;lt; at &amp;gt;gmail.com&amp;gt; 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

&lt;/pre&gt;</description>
    <dc:creator>John Yeung</dc:creator>
    <dc:date>2013-05-13T23:00:40</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.editors.scite.general">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.editors.scite.general</link>
  </textinput>
</rdf:RDF>
