Neil Hodgson | 1 Nov 01:25
Picon

Re: Bug found in wscite v1.66

Julian Herten-Greaven:

> I'll post further findings to the tracker.. but with regard to this
> particular issue, it's not the vertical "block" select that I'm
> after..rather being able to use the ALT-HOME and ALT-END behaviour along
> with selecting text. ALT-SHIFT-left/right is simply another way this errant
> behaviour can be observed.

   When Alt was made the rectangular modifier, the key Shift+Alt+Home
was remapped to SCI_VCHOMERECTEXTEND. You can switch the behaviour to
your preference by mapping this key to SCI_HOMEDISPLAYEXTEND.
Similarly Shift+Alt+End -> SCI_LINEENDDISPLAYEXTEND.

user.shortcuts=\
Shift+Alt+Home|2346|\
Shift+Alt+End|2348|

   Neil
Philippe Lhoste | 1 Nov 11:17
Picon

Re: Upper and lower case

Neil Hodgson wrote:
> Luc ROLLAND:
>> I would obtain that some keywords would
>> automatically mapped to upper or lower case
>> (instead of using CTRL+U).
>> I think it is possible using options and properties,
>> but I don't understand how ?
> 
>    Use the case:u or case:l values in the appropriate style setting.
> For example,
> style.python.5=fore:#00007F,bold,case:u

I believe Luc is aware of this feature (see his "Bugs item #1344313", 
"PDF don't reflect some style directives"), but is frustated that this 
is only a visual effect, ie. text is not changed.

I believe this feature has been forgotten in most exporters...

Luc, if you want to have to physically alter the source, you have either 
to modify SciTE to get that effect, or more easily, to use Lua script.

To change existing code, you should use an external script (Perl, 
Python, whatever), as it would be more efficient, probably, that an 
internal script (and no need to load the file, apply the transformer, 
save the file...). But it would need to rewrite a lexer.

To change code on the fly, while typing, you can use a script similar to 
the one already given on this list:

--## Put SQL keywords on uppercase while typing them.
(Continue reading)

Andy Sy | 1 Nov 15:35
Favicon

Re: control-key status being missed?

Neil Hodgson wrote:

>    Aaahhh, "Microsoft Comfort" ... There have been issues in the past
> with the enabling of Undo getting confused but that should lead to
> unresponsive Ctrl+Z rather than "z" and I think those problems have
> been fixed. When you see this behaviour can you move your hands away
> from the keyboard and then perform Ctrl+Z? 

Yes.  If I release all pressed keys and do a Ctrl-Z again it usually
works.  What happens is that if I keep pressing 'z' (without releasing
the Ctrl-key) it's as if the Ctrl-key got released and plain z's come
out.

> Have you switched into a foreign keyboard or accessibility mode? For
>example, pressing shift 5 times goes into sticky keys mode.

Nope pretty sure I haven't.  Although my keyboard is set to switch
between Dvorak and QWERTY on Left-Alt-Shift-0 and Left-Alt-Shift-1
respectively (but I did turn off the switch-between-layout with single
key combination functionality).
william | 1 Nov 21:32

title numbering

I'm using Scite for all my text files (maybe not a good idea). But I don't have
knwoledge concerning configuration aspects ;-(.

Thus I'm using Scite for wiki texts (I'm writing it in scite, with correct
formating) then copy/paste to the wiki tool.

In that context I would like to know if it's possible to automatically numbering
titles.

Let me take a small example:
= Title Intro =
bla bla bla
= Title Ideas =
blable
= Title Conclusions =
ble ble ble

Thus, is there possibilities (via lua I presume) to replace word "Title" by an
incremental number (1,2,3) ?

If Yes, where can I find some info for that subject ?

Thanks.
Neil Hodgson | 2 Nov 05:14
Picon

Re: sending message to SciTE

April White:

> I removed SciTEWin::Execute(), placing that code within the command
> case, and it executes the commands in the queue.  I tested Makefile and
> a simple .c file
>
> hoo hoo, it works :-)

   OK. It worked for some external programs and Lua scripts.

   The implementation of Jobs::JobList::HasParameterisedCommand and
Jobs::HasParameterisedCommand need "const" to match the header.

   commandMax and commandCurrent should disappear and some of the
other fields (cancelFlag?) should be inside JobQueue. Some processing
has been moved from SciTEBase::Execute in the UI thread to
SciTEWin::ProcessExecute in the tool thread which has increased the
chances of a thread clash. The current code isn't completely safe
either as two calls to props.GetInt (win95.death.delay and
output.scroll) have crawled into the tool thread which is unsafe as
the property set could be reloaded by the UI while the tool is running
inside the props.GetInt call. Everything the tool thread needs should
be put in the Job or JobQueue object and protected with the lock.

   The implementation of Jobs::JobList::HasParameterisedCommand and
Jobs::HasParameterisedCommand need "const" to match the header.

   The queue class should be called JobQueue rather than Jobs, be
housed in JobQueue.h and JobQueue.cxx (too many files start with SciTE
which makes tab completion not so useful) and the header should not be
(Continue reading)

Picon
Favicon

Re: Bug found in wscite v1.66

Neil,

Great. Thank you on the followup and for sticking with the thread.

I doubt I'll have to reply with anything substantial, unless I find 
something worth reporting.

Regards,
Julian

----- Original Message ----- 
From: "Neil Hodgson" <nyamatongwe <at> gmail.com>
To: "Discussion of the SciTE editor" <scite-interest <at> lyra.org>
Sent: Monday, October 31, 2005 7:25 PM
Subject: Re: [scite] Bug found in wscite v1.66

| Julian Herten-Greaven:
|
| > I'll post further findings to the tracker.. but with regard to this
| > particular issue, it's not the vertical "block" select that I'm
| > after..rather being able to use the ALT-HOME and ALT-END behaviour along
| > with selecting text. ALT-SHIFT-left/right is simply another way this 
errant
| > behaviour can be observed.
|
|   When Alt was made the rectangular modifier, the key Shift+Alt+Home
| was remapped to SCI_VCHOMERECTEXTEND. You can switch the behaviour to
| your preference by mapping this key to SCI_HOMEDISPLAYEXTEND.
| Similarly Shift+Alt+End -> SCI_LINEENDDISPLAYEXTEND.
|
(Continue reading)

Carlos Pita | 2 Nov 09:30
Picon
Favicon

Slow buffer scrolling and switching

Hi!
I've recently started using scite for python programming. I find the
editor pretty comfortable and complete except for a couple of quirks
that I couldn't get rid of. One ocurrs when I keep up/down arrow keys
pressed; the cursor reaches the top/bottom of the window but then the
buffer isn't scrolled; when I finally release the arrow key the buffer
suddenly jumps to the far point where it should have smoothly scrolled
to.  Another minor annoyance is the latency when switching buffers; fast
buffer navigation via shift-f6 seems out of question. As I have read a
number of times that a disctinctive feature of scite is its performance
I guess I'm doing something wrong. I'm using the scite 1.66 package for
debian. I've also recompiled scite 1.66 from the sources and turned off
line wrapping, braces matching, buffering and 2-phase draw and changed
to good old X fonts but that didn't make for any improvement. I'm
running scite in an athlon 700 mhz with 384 mb of ram. I've been working
with emacs and vim for years in this same pc without any noticeable
delay as those described above.
Any suggestions?
Thank you in advance.
Best regards,
Carlos

	

	
		
___________________________________________________________ 
1GB gratis, Antivirus y Antispam 
Correo Yahoo!, el mejor correo web del mundo 
http://correo.yahoo.com.ar 
(Continue reading)

Neil Hodgson | 2 Nov 11:41
Picon

Re: Slow buffer scrolling and switching

Carlos Pita:

>One ocurrs when I keep up/down arrow keys
> pressed; the cursor reaches the top/bottom of the window but then the
> buffer isn't scrolled; when I finally release the arrow key the buffer
> suddenly jumps to the far point where it should have smoothly scrolled
> to.

   The slippage is deliberate as it means it is quicker to move around
even when the display is slow. When the display is fast enough it is
not noticeable. Adding an option to ignore repeating keys while
drawing is pending would be complex.

> Another minor annoyance is the latency when switching buffers; fast
> buffer navigation via shift-f6 seems out of question.

   One cause of slowness in buffer switching is remembering folding
information for each buffer and restoring this. There is no way of
turning this off even if no folding has been performed. SciTE reloads
options files when switching buffers with little optimization so can
be slow when the options files are accessed over a network.

> As I have read a
> number of times that a disctinctive feature of scite is its performance
> I guess I'm doing something wrong. I'm using the scite 1.66 package for
> debian. I've also recompiled scite 1.66 from the sources and turned off
> line wrapping, braces matching, buffering and 2-phase draw and changed
> to good old X fonts but that didn't make for any improvement.

   I accept that SciTE is too slow for you but seeing no improvement
(Continue reading)

Roman Hubacek | 2 Nov 13:44
Picon
Favicon

Re: title numbering

william wrote:
> I'm using Scite for all my text files (maybe not a good idea). But I don't have
> knwoledge concerning configuration aspects ;-(.
> 
> Thus I'm using Scite for wiki texts (I'm writing it in scite, with correct
> formating) then copy/paste to the wiki tool.
> 
> In that context I would like to know if it's possible to automatically numbering
> titles.
> 
> Let me take a small example:
> = Title Intro =
> bla bla bla
> = Title Ideas =
> blable
> = Title Conclusions =
> ble ble ble
> 
> Thus, is there possibilities (via lua I presume) to replace word "Title" by an
> incremental number (1,2,3) ?
> 
> If Yes, where can I find some info for that subject ?

Yes, it is possible. I wrote lua function that does it for you. Put this 
into your startup script:

function replace_title()
   i = 1
   for m in editor:match("Title") do
     m:replace(i)
(Continue reading)

Andy Sy | 2 Nov 19:29
Favicon

Re: control-key status being missed?

Neil Hodgson wrote:

>>I though initially it may be a problem with my Microsoft
>>Wireless Comfort Keyboard, but the problem does not seem
>>to manifest itself with other applications.
> 
>    Aaahhh, "Microsoft Comfort" ... There have been issues in the past
> with the enabling of Undo getting confused but that should lead to
> unresponsive Ctrl+Z rather than "z" and I think those problems have
> been fixed. When you see this behaviour can you move your hands away
> from the keyboard and then perform Ctrl+Z? Have you switched into a
> foreign keyboard or accessibility mode? For example, pressing shift 5
> times goes into sticky keys mode.
> 
>    Neil

I've just confirmed that it is a problem with the keyboard and not
SciTE.

Gmane