How to Fix "TERM environment variable not set."?


Hello Discussion,

I am using SciTE 1.71 on Ubuntu 6.06, Gnome 2.14.3. I downloaded the tar
package and unleashed it inside my home directory. I symlinked it to
/usr/share. I work on SQL files and wanted SciTE to execute the SQL
inside of Postgres for testing purposes only. Here is my solution though
I have a small problem (more like a bugaboo).

Inside my .SciTEUser.properties file I have this...

	file.patterns.sql=*.sql
	command.go.$(file.patterns.sql)=\
	psql -U anon -d anon -f '$(FilePath)'

Inside my pg_hba.conf file I have this above all entries...

	local "anon" "anon" trust

Inside psql as user postrges I create the anon user and database...

	create user anon; create database anon;

To make this all work I restarted Postgres like this...

	sudo /etc/init.d/postgresql-8.1 restart

Now inside SciTE I am able to work on some SQL and then execute it with
F5 like I would execute my Python scripts. I see the results of the SQL
immediately in the output pane and like what I see...
(Continue reading)

Philippe Lhoste | 4 Sep 14:32
Picon

Gmane support of Scintilla/SciTE lists broken?

I use to read this list, and the Scintilla one, using Gmane.org nntp:// 
interface <nntp://news.gmane.org/gmane.editors.scite.general>, because 
currently I don't use much my main e-mail account.

I read also the Lua list, which I receive fine, but I no longer receive 
the Scintilla nor the SciTE e-mails. Looking at the Gmane site, I see it 
is stopped at the point I am in my newsreader: 
<http://blog.gmane.org/gmane.editors.scite.general>, ie. around August 24.

Was there any change in the mailing list handling that makes Gmane to 
have lost track of these lists?

--

-- 
Philippe Lhoste
--  (near) Paris -- France
--  http://Phi.Lho.free.fr
--  --  --  --  --  --  --  --  --  --  --  --  --  --
Srish Agrawal | 8 Sep 07:34

Filter out multiple lines

Hello EveryBody

I needed a small LUA script to be used with SciTE. It was supposed to remove all
multilple lines except the first one from a text document without changing the
original document in any other way. Unable to find a similer script posted
anywhere on the NET, I wrote it myself.

Of cource, I borrowed some coding ideas/tricks and functions from codes written
by Neil Hodgson and Philippe Lhoste.

It works as expected but is rather big.  May anybody give me some idea as to how
can I cange the logic and save a few lines of code.

This is what I have :

-- this function removes multiple lines
-- only the first occurance is kept
-- original order of lines are meintained
-- NOTE
-- editor line number starts from ZERO
-- table element number strats from ONE

function RemoveDupLines()
    local t = {}                -- // table in which all the editor lines are stored
    local t1 = {}               -- // table in which unique elements of t are stored
    local t2 = {}               -- // for temp storage of multiple lines
    local t3 = {}
    local eol = GetEOL()
    local en = editor.LineCount -- // number of lines in editor
    local dup_below = 0         -- // current line is not dup with line below it
(Continue reading)

Philippe Lhoste | 8 Sep 09:58
Picon

Mailing list hipcups?

Recently, I complained that I no longer receive messages of this mailing 
list (and Scintilla one) via Gmane NNTP server.
Actually, I saw at the same time that the archives were not updated either.
Today, I received 5 messages for this list, 7 for Scintilla's one, the 
latest dated August 31...
So I don't even have my own message...
I hope the shortage will stop soon. :-)

--

-- 
Philippe Lhoste
--  (near) Paris -- France
--  http://Phi.Lho.free.fr
--  --  --  --  --  --  --  --  --  --  --  --  --  --
Philippe Lhoste | 8 Sep 10:15
Picon

Re: performance issues with very long lines

Dan Anderson a écrit :
> I experience major performance problems (maxed CPU for 20 seconds) when 
> editing files with very long lines (138,374 chars, for example).  The 
> files are plain text log files.  I do not have line wrap enabled.  The 
> problem only occurs only when the cursor is located in one of these very 
> long lines.  I thought the problem might be a scintilla problem, but the 
> same problem does not appear to exist in another scintilla-based editor 
> that I occasionally use.  I'm running SciTE 1.69 on WinXP.  Anyone else 
> ever experience this problem?  Is there a configuration that might help?

It is a very old problem with Scintilla...
It is more suited to regular source code editing, where most code have 
less than 80 chars long lines, that to edit any text files.
Except that XML (or even HTML) lines can be very long too...
I think it is in the way the lines are handled, Scintilla has to compute 
the length of each part (words) to properly display the line.
Plus it might have issues with the WinAPI, at least on old platforms 
like Win98.
I recall it works better on short segments (of same style) that on long 
runs of one style.

Some known workarounds can be to cut (hard wrap) your long lines with 
some tool, to activate the word wrapping (but it is still slow, IIRC, 
although slightly faster (?)), or to use some lexer that colourize parts 
of the line (even a special lexer just using two styles every n chars 
would be enough).

--

-- 
Philippe Lhoste
--  (near) Paris -- France
(Continue reading)

Philippe Lhoste | 8 Sep 10:20
Picon

Re: How does SciTE recongnize none command file w/o extensions?

Robert Hicks a écrit :
> I know you recently did the shbang thing but what if I have a property 
> file (lets say it is an ini type file) but it doesn't have an extension 
> of .ini? I know jEdit lets you do something like # :style=ini: and it 
> will take that hint to color the file.

That's for this case that I implemented, a long long time ago, the 
language menu: to allow arbitrary selection of a lexer on the current 
buffer. It was made mostly for your case: extension-less file names. Or 
for another frequent case, like the myriad of XML files with proprietary 
extensions.
Of course, doing this on each file opening can be a chore (that's why I 
implemented also some shortcuts for text, HTML, XML and makefiles), but 
that's better than nothing.
I don't know if shbang matching is flexible or hard-coded.

--

-- 
Philippe Lhoste
--  (near) Paris -- France
--  http://Phi.Lho.free.fr
--  --  --  --  --  --  --  --  --  --  --  --  --  --
Neil Hodgson | 8 Sep 15:01
Picon

Re: performance issues with very long lines

Dan Anderson:

> I experience major performance problems (maxed CPU for 20 seconds)
> when editing files with very long lines (138,374 chars, for example).

   Scintilla has poor performance on very long lines. You can try
setting cache.layout.

   Neil
Lionel B | 8 Sep 17:01
Picon
Favicon

Re: Gmane support of Scintilla/SciTE lists broken?

On *Mon, 04 Sep 2006* 14:32:31 +0200, Philippe Lhoste wrote:

> I use to read this list, and the Scintilla one, using Gmane.org nntp:// 
> interface <nntp://news.gmane.org/gmane.editors.scite.general>, because 
> currently I don't use much my main e-mail account.

I've just received this now (Sep 8) via news.gmane.org and am posting this
reply via Gmane too. I notice that the latest messages I received on this
list via Gmane were dated Aug 31.

--

-- 
Lionel B
Robert Roessler | 8 Sep 21:59
Favicon

Re: Gmane support of Scintilla/SciTE lists broken?

Philippe Lhoste wrote:
> I use to read this list, and the Scintilla one, using Gmane.org nntp:// 
> interface <nntp://news.gmane.org/gmane.editors.scite.general>, because 
> currently I don't use much my main e-mail account.
> 
> I read also the Lua list, which I receive fine, but I no longer receive 
> the Scintilla nor the SciTE e-mails. Looking at the Gmane site, I see it 
> is stopped at the point I am in my newsreader: 
> <http://blog.gmane.org/gmane.editors.scite.general>, ie. around August 24.
> 
> Was there any change in the mailing list handling that makes Gmane to 
> have lost track of these lists?

Neil would know for sure, but it just looks like one of the occasional 
blockages at the mail site (Lyra) itself... notice how we are suddenly 
seeing a lot of emails that were being held since that time. ;)

Unless someone notices that there haven't been any Scintilla/SciTE 
list emails for "too long" and Neil fixes the problem, things just 
continue to back up.

Robert Roessler
robertr <at> rftp.com
http://www.rftp.com
Neil Hodgson | 9 Sep 02:08
Picon

Re: Gmane support of Scintilla/SciTE lists broken?

Philippe Lhoste:

> Was there any change in the mailing list handling that makes Gmane to
> have lost track of these lists?

   The mailing list was not processing messages.

   Neil

Gmane