headers
SteveD | 1 Jul 2008 08:09
Picon

Re: hi ppl need help on scite working with c++


It looks like gcc is not on your path!  Go to My Computer|Properties|
Advanced,
click the 'Environment Variables' button, and put your mingw bin
directory at the end, separated by a semicolon.

E.g. my path looks like:
d:\progs\minsim;d:\Python25;D:\stuff\lua;c:\MinGW\bin

steve d.

On Jun 30, 10:29 pm, Alpha <tarun.saxena... <at> gmail.com> wrote:
> hey ppl I am tryin to use scite with c++ and I am not getting where I
> went wrong......it always gives an error wen I try to compile a .cpp
> file ....though it is easily compiled on my Borland c++
> compiler......the error it always gives is.     "g++ -pedantic -Os -
> fno-exceptions -c bcc1.cpp -o bcc1.o
>
> >The system cannot find the file specified."
>
> If anybody cud help me please I am desperate to use it.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "scite-interest" group.
To post to this group, send email to scite-interest <at> googlegroups.com
To unsubscribe from this group, send email to scite-interest-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/scite-interest?hl=en
-~----------~----~----~----~------~----~------~--~---
Permalink | Reply | 501 comments |
headers
nari | 1 Jul 2008 13:31
Picon

Lesbian girls


##############################
http:\\lakshmiraiprofile.blogspot.com
##############################
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "scite-interest" group.
To post to this group, send email to scite-interest <at> googlegroups.com
To unsubscribe from this group, send email to scite-interest-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/scite-interest?hl=en
-~----------~----~----~----~------~----~------~--~---
Permalink | Reply | 0 comments |
headers
Neil Hodgson | 1 Jul 2008 15:13
Picon

Spam


   It appears that spammers have worked out how to automate the
subscription and posting process and have sent two messages to this
list (previous one on June 23). I don't think that stopping automatic
subscription would help since the moderators have no way of knowing
that a particular address will be non-spammy. However, the "Messages
from new members are moderated" option may help (and I just turned it
on) although it means that there will be some delays for new
subscribers.

   Neil

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "scite-interest" group.
To post to this group, send email to scite-interest <at> googlegroups.com
To unsubscribe from this group, send email to scite-interest-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/scite-interest?hl=en
-~----------~----~----~----~------~----~------~--~---
Permalink | Reply | 1 comment |
headers
KHMan | 1 Jul 2008 19:27
Picon

Re: Spam


Neil Hodgson wrote:
>    It appears that spammers have worked out how to automate the
> subscription and posting process and have sent two messages to this
> list (previous one on June 23). I don't think that stopping automatic
> subscription would help since the moderators have no way of knowing
> that a particular address will be non-spammy. However, the "Messages
> from new members are moderated" option may help (and I just turned it
> on) although it means that there will be some delays for new
> subscribers.

Roger that. You beat me to the whack-a-spambot thing both times.
:-) Gmail seems to be under heavy assault; POP is dead slow here.
Moderating new members sounds fine.

--

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "scite-interest" group.
To post to this group, send email to scite-interest <at> googlegroups.com
To unsubscribe from this group, send email to scite-interest-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/scite-interest?hl=en
-~----------~----~----~----~------~----~------~--~---
Permalink | Reply | 0 comments |
headers
RichardOnRails | 2 Jul 2008 01:58

Re: How to reduce default tab-size for all *.rb pgms


Hi Philippe,

Thank you for your excellent suggestion.

I read the  SciTE Documentation HTML file.
I modified the K:\_Utilities\SciTE-1.74\SciTEGlobal.properties file as
follows:

# Window sizes and visibility
if PLAT_WIN
	position.left=0
	position.top=0
	tab.size.*.rb=2 <= added

I created a new SciTE instance.  Saved the null file as TestSpaces.rb
Entered two lines:
< 8 spaces>xxx
<tab>xxx

The x's on the two lines were aligned.  It appears my change had no
impact.  Do you think I need to add my spec to some other file?

Thanks again for your help.

Best wishes,
Richard

On Jun 30, 3:54 am, Philippe Lhoste <Phi... <at> GMX.net> wrote:
> On 28/06/2008 22:28, RichardOnRails wrote:
(Continue reading)

Permalink | Reply | 4 comments |
headers
Philippe Lhoste | 2 Jul 2008 10:56
Picon

Re: How to reduce default tab-size for all *.rb pgms


On 02/07/2008 01:58, RichardOnRails wrote:
> Entered two lines:
> < 8 spaces>xxx
> <tab>xxx
> 
> The x's on the two lines were aligned.  It appears my change had no
> impact.  Do you think I need to add my spec to some other file?

I couldn't reproduce the issue... :(
Note that it is officially recommended to put such change in SciTEUser.properties, to 
avoid custom changes to be overwritten by new version (if you careless drop all 
distributed files into the SciTE directory... :) )
No need to make the option system specific, too.

Just in case, grep if tab.size.*.rb isn't defined in another .properties file: if loaded 
after your definition, it will override it.

You can also check the current settings with the indent dialog (Ctrl+Shift+I or in Options 
menu).

HTH.

--

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

--~--~---------~--~----~------------~-------~--~----~
(Continue reading)

Permalink | Reply | 3 comments |
headers
Taylor Venable | 3 Jul 2008 19:16
Picon

Initial buffer seems to ignore eol.mode?


I've got eol.mode set to "LF" in my user properties file, but the very
first buffer that SciTE shows (the empty one that loads on startup)
has it set to CR+LF when eol.auto is 1 -- when I do a CTRL-N it goes
to LF.  Is there any way to set the EOL for the first buffer which is
created on startup, or is this possibly an error?  The eol.mode
property is definitely working right in every buffer but the very
first one.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "scite-interest" group.
To post to this group, send email to scite-interest <at> googlegroups.com
To unsubscribe from this group, send email to scite-interest-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/scite-interest?hl=en
-~----------~----~----~----~------~----~------~--~---
Permalink | Reply | 3 comments |
headers
Remi Gillig | 3 Jul 2008 19:32
Picon
Gravatar

Re: Initial buffer seems to ignore eol.mode?


It seems like eol.auto also has a role in applying the line endings. I
can reproduce the behaviour you described only when eol.auto=0 and it
is =1 by default. Try setting eol.auto=0 in your user properties.

I don't know if this is by design though. There seem to be some odd
code :
- SciTEBase.cxx (line 3353), when a new file is created from the menu
ReadProperties();
SetIndentSettings();
if (props.GetInt("eol.auto"))
SetEol();

- SciTEProps.cxx (line 728), in ReadProperties used above :
if (!props.GetInt("eol.auto")) {
	SetEol();
}

So, logically, when a new file is created from the menu, eol.auto does
not matter because SetEol will be called in both eol.auto=0 (in
ReadProperties) and eol.auto=1 (in MenuCommand). However, the first
buffer is created using only ReadProperties which calls SetEol only if
eol.auto=0. That matches the behaviour I have and yours.

We have to wait for an answer from Neil to really know the intention.

Remi Gillig.

On Jul 3, 7:16 pm, Taylor Venable <taylorvena... <at> gmail.com> wrote:
> I've got eol.mode set to "LF" in my user properties file, but the very
(Continue reading)

Permalink | Reply | 2 comments |
headers
Eliot | 4 Jul 2008 01:07
Picon

Regexp for F4 / Next message?


Greetings,

There is a FAQ item (http://scintilla.sourceforge.net/
SciTEFAQ.html#CompilerErrors) on how to get F4 to understand new
formats for compiler error messages.

However, this is very arcane, and certainly not something that can be
done quickly.
Looking at the code it seems very complex.  If I was going to add
something, I'd rather work on the following idea.

To me this function is a special case of regexp search. (rather than
coding up every search and match in C++)

The match would be something defined in an options file.  It could be
set per-language, or per-directory etc.
E.g. heres my compiler output
"ahif.c", line 97: error #20: identifier blah

f4.regexp="(.+)", line ([0-9]+): [ew][ra]r[on][ri]n*g*
f4.filename=1 # tag number for filename match
f4.linenumber=2 # tag number for linenumber match
f4.column=0 # no column in this example

1) Is this a dumb idea? (because?)
2) How hard to implement (My job is coding C and some C++)
3) Where to start?

regards
(Continue reading)

Permalink | Reply | 2 comments |
headers
Remi Gillig | 4 Jul 2008 11:29
Picon
Gravatar

Re: Regexp for F4 / Next message?


Interesting idea, but I think you can do it directly using a Lua
function.
Why?
- you can access the text from the output pane
- you can use regex in Lua (see string.gmatch)
- you can send messages to the editor pane to go to the line, switch
to the file (or open it), etc.

The only problem may be to retrieve the full path of the file because
usually the compilers/interpreters just give the base filename.

Remi Gillig.

On Jul 4, 1:07 am, Eliot <ewb... <at> gmail.com> wrote:
> Greetings,
>
> There is a FAQ item (http://scintilla.sourceforge.net/
> SciTEFAQ.html#CompilerErrors) on how to get F4 to understand new
> formats for compiler error messages.
>
> However, this is very arcane, and certainly not something that can be
> done quickly.
> Looking at the code it seems very complex.  If I was going to add
> something, I'd rather work on the following idea.
>
> To me this function is a special case of regexp search. (rather than
> coding up every search and match in C++)
>
> The match would be something defined in an options file.  It could be
(Continue reading)

Permalink | Reply | 0 comments |

Gmane