Re: Re: TeX (was: Re: Re: Re: styler.GetPropertyIntand keywordlists)

Hans,

> indeed, and the config files contain keywords for the core languages  
> (tex, pdftex, etex omega etc) 

> context ships wih a bunch of keyword defs (one for each user interface  
> language) 

> since i use no other macro packages i have no other lists 

Yes, I knew that most of the lists were for ConTeXt. But I don't understand the
use of these lists or what are the gains of using these lists comparing to not using 
them -- I tested with some ConTeXt sources and it seems that the ColouriseTeXDoc
works OK without setting %interface=en, nl, de etc. As I mentioned in the original 
message, users often define their own commands and structures, and these might not 
be in the lists, so might not get coloured if some of the interfaces is turned on;

>> So 
>> I'm wondering if you would accept the idea of replacing  
>> ColouriseTeXDoc code 
>> in LexTeX.cxx with something similar to ColoriseLaTeXDoc from  
>> LexOthers.cxx. 

> latex is just a macro package and the lexer is independent of the macro  
> package; toe original lexer was flawed and not tex compliant; the  
> current lexer is more configurable 

> scite if the reference editor for editing support in context (a tex  
> macro package) and its users now expect these the tex/mplexers to be  
> there -)

Re: Re: TeX (was: Re: Re: Re: styler.GetPropertyIntand keywordlists)

> btw, in the context distribution there are also lua scripts for spell  
> checking etc (some other functionality like justification may not always  
> work because i need to check the latest lua in scite) 

Hans 

That's quit interesting! Is it possible to get the spell checking Lua script without 
downloading the huge ConTeXt distribution? 

Re: TeX

instanton wrote:

> Yes, I knew that most of the lists were for ConTeXt. But I don't understand the
> use of these lists or what are the gains of using these lists comparing to not using 
> them -- I tested with some ConTeXt sources and it seems that the ColouriseTeXDoc
> works OK without setting %interface=en, nl, de etc. As I mentioned in the original 
> message, users often define their own commands and structures, and these might not 
> be in the lists, so might not get coloured if some of the interfaces is turned on;

i assume that you've read

http://www.pragma-ade.com/general/manuals/mscite-p.pdf

in principle users can add their own keywords as well; catching user
defined macros is not possible because that would involve a complete parser

> OK, I am not proposing that removing the current ColouriseTeXDoc is a necessity.
> I just wondered if using the lists in it is necessary. I wish to know how many users 
> are depending on these interfaces now?

no, you can turn of the lists (see manual)

> BTW, for me the two colourising procedures ColouriseTeXDoc and ColouriseLaTeXDoc 
> work a little differently: the latter allows for asigning different colours to
> inline maths and displayed maths, and also different colours for the tags
> \begin{...} ... \end{...} and the contents therein, this is very convenient but the former
> does not have this effect; on the other hand the former allows for colourising braces
> which is also convenient while the latter doesn't do this.

well, math is a complex story, since math itself can contain commands;

Re: TeX (was: Re: Re: Re: styler.GetPropertyIntand keywordlists)

instanton wrote:
>> btw, in the context distribution there are also lua scripts for spell  
>> checking etc (some other functionality like justification may not always  
>> work because i need to check the latest lua in scite) 
> 
> Hans 
> 
> That's quit interesting! Is it possible to get the spell checking Lua script without 
> downloading the huge ConTeXt distribution? 

for a while i had a small zip with just the script; if the context zip
is to big i can send you the script; some day soon i will update the lot

Hans

-----------------------------------------------------------------
                                          Hans Hagen | PRAGMA ADE
              Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
     tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
                                             | www.pragma-pod.nl
-----------------------------------------------------------------

[ scintilla-Bugs-1746163 ] Word deletion problem

Bugs item #1746163, was opened at 2007-07-01 12:56
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102439&aid=1746163&group_id=2439

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Scintilla
Group: Bug
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Word deletion problem

Initial Comment:
Hello,
I am not too sure this is unwanted behavior, but here it is. When you hit Ctrl+Delete, it deletes the
following word. If you have a selection, Ctrl+Delete will still delete the following word, keeping the
selection. I believe it should delete the selection first, but this is only my opinion.
Example of what it actually does (selection represented by []):
Hello World!
[Hello], World!
<ctrl+delete>
[Hello]World!
<ctrl+delete>
[Hello]!

Scroll width tracking

   About a year ago a patch was sent to the list from Snow which
updated the horizontal scroll bar based on the widths of the lines
currently being displayed. I didn't like that patch as it modified the
scroll width too often and had the width change too closely coupled to
modifications. There is now a similar feature committed that allows
the scroll width to become wider (not narrower) and that defers the
scroll bar modification to be performed during the timer tick event.

   This is controlled with the ScrollWidthTracking property in
Scintilla (SCI_SETSCROLLWIDTHTRACKING, SCI_GETSCROLLWIDTHTRACKING) and
the SciTE properties horizontal.scroll.width.tracking and
output.horizontal.scroll.width.tracking.

  Changes available from CVS and from
http://scintilla.sourceforge.net/scite.zip Source
http://scintilla.sourceforge.net/wscite.zip Windows executable

   Neil

PLAT_MACOSX and #if

Hi,

I noticed that I stepped through code meant for OSX when debugging on 
win32.  This doesn't seem to cause any real problems, but the attached 
patch fixes this by changing uses of #ifdef to #if.

Cheers,

John

Index: include/Platform.h
===================================================================
--- include/Platform.h	(revision 15760)
+++ include/Platform.h	(working copy)
 <at>  <at>  -368,19 +368,19  <at>  <at> 
 class Window {
 protected:
 	WindowID id;
-#ifdef PLAT_MACOSX
+#if PLAT_MACOSX
 	void *windowRef;
 	void *control;
 #endif
 public:
 	Window() : id(0), cursorLast(cursorInvalid) {
-#ifdef PLAT_MACOSX
+#if PLAT_MACOSX
 	  windowRef = 0;
 	  control = 0;

Allow autocomplete popups to appear outside client rectangle

Hi,

Scintilla's autocomplete popup appears above the current line if there 
isn't room in the client rectangle below the current line and there is 
room above.  The client rectangle is where the text is drawn.  This 
means that the popup appears above the current line even when there is 
space below on the monitor.

The attached patch allows the popup to be displayed below as long as it 
can fit on the monitor the cursor is on.  It's only implemented on the 
gtk platform, but hopefully isn't too difficult to implement on other 
platforms.  The same positioning behavior might also be applied to 
calltips and other popups.

Cheers,

John

Index: include/Platform.h
===================================================================
--- include/Platform.h	(revision 15788)
+++ include/Platform.h	(working copy)
 <at>  <at>  -405,6 +405,7  <at>  <at> 
 	enum Cursor { cursorInvalid, cursorText, cursorArrow, cursorUp, cursorWait, cursorHoriz,
cursorVert, cursorReverseArrow, cursorHand };
 	void SetCursor(Cursor curs);
 	void SetTitle(const char *s);
+	PRectangle GetMonitorRect(Point pt);
 #if PLAT_MACOSX

Re: PLAT_MACOSX and #if

John Ehresman:

> I noticed that I stepped through code meant for OSX when debugging on
> win32.  This doesn't seem to cause any real problems, but the attached
> patch fixes this by changing uses of #ifdef to #if.

   OK, committed.

   Neil

Scintilla used by TortoiseSVN

I just noticed, when typing a comment while commiting a change: I saw a 
familiar wrap symbol, and indeed this dialogue is using Scintilla!

Maybe it can be added to the list of "Projects using Scintilla"?

--

-- 
Philippe Lhoste
--  (near) Paris -- France
--  http://Phi.Lho.free.fr
--  --  --  --  --  --  --  --  --  --  --  --  --  --