Desired text editing features
Why Tea
utility features instead of text editing features. Has Tse Pro reached
its potential as a text based editor? Personally, I would like to see
the following features:
- native support of code folding
- better support of printing, e.g. printer setup and
WYSIWYG printing as in syntax highlight
I still use Tse quite heavily in text editing on Windows, but I also
use some freeware GUI based text editor 30% of the time. Once I port
all my customized Tse macros across, I believe I'll use less of Tse.
In the Unix world, vi is always needed when all you have is a text
terminal. Under Windows, such situation doesn't seem to exist. I hope
I can get some discussion going here on how Tse should evolve in order
to better suit the Windows environment and to attract new users.
/Why Tea
Howard Kapustein
And yet, sadly, I can't find another editor I find as compelling. A testament to TSE - despite its relative age and limitations, it still smokes the competition.
I've been recently doing some Ruby on Rails work and spent a little time burning thru various Ruby-aware editors. RadRails (i.e. Eclipse), SteelSapphire (i.e. Visual Studio), NetBeans, and a few Ruby-specific editors. None of the IDEs were really all that compelling, over a good editor and command line. Maybe someday, when type inference gets smarter and IDEs provide a real Intellisense experience for dynamic languages, but that day's not today.
NONE of the IDEs were all that great as editors. NetBeans was the best of the bunch, and TSE is still more productive.
NOTE: I used TextMate for the past year when I had a Mac at Amazon, and despite it being the #1 hot programmer's editor on the Mac, I still often yearned for TSE. Maybe TextMate 2.0 will improve matters. If it's ever finished.
You mention CodeFolding and Printing. Both would be improvements, but not fundamental improvements most would find helpful. Some, yes, but only some.
I think TSE's true weaknesses at this point are more subtle, often incremental features.
* Unicode support
* Improved macro language (in many little ways, e.g. dynamic/variable-length strings)
* Improved syntax highlighting (e.g. mixed content, e.g. .ASP files with HTML, CSS and Javascript - 3 syntaxes, but TSE today only handles 1 at a time; ASP.NET, JSP, RHTML, and others would benefit. Ditto Java with Annotations and C# with Attributes, among others)
* More
Regex support was a major addition to TSE that many benefit from. The change to a Win32 GUI app with true Font support was a big deal, but also a somewhat subtle change. TSE still largely looked and felt the same (yay!), but it just did what it did better.
The problem is, a lot of the enhancements at this point are either of benefit to a fraction of users, or are widely valuable but require fundamental internal changes to support (or at least, 'twould seem so, based on Sammy Comments <g> the past few years).
I check out alternative editors every few years, and keep coming back to TSE. A testament to its design and implementation.
[Yes, I tried even vi and emacs. Again. And again, bleh.]
I'd love to see TSE under active development, but it sounds like at this point any major changes will require a lot of work, and the market ($) for editors has been shrinking. So unless Sammy hits the Mega Million jackpot and decides hacking TSE is how he wants to spend his retirement <fingers crossed :->, I'm having a hard time thinking of TSE enhancements that would justify the time investment (from a commercial sense).
Of course, I'm just an interested observer. You asked how TSE could evolve in the Windows market. I think first you need to understand what you mean by that. Who are the target users?
That's a smaller target than past years. Visual Studio, Eclipse and NetBeans are compelling to many, who'd rather (only?) have an IDE than an editor.
Then there's the vi and emacs fans, those who cut their teeth on Unix and like them. I doubt you'll find many (any) converts from this segment.
And those for whom Notepad is adequate for casual use.
That leaves the 'power editor' market. Seems to be largely programmers and sys admins, though I'm sure Sammy's got more solid breakdown past on past sales.
The competition in this area tends to be rather fractured, with the big expensive boys shrinking (e.g. Slickedit) or dead (anyone even know if Brief or Epsilon Editor are even still around?). It's the low-end (shareware/inexpensive and free) editors you're competing with.
I do believe TSE has most of the core features you need, but incremental and specialized improvements WOULD be welcome.
Last time this came up (2 years ago?) there was a list of features tossed around. I'd start there - dust off that top N list from the archives, and see if it's still current.
Then of course there's the question of Sammy's time and interest.
Or the alternative, if Sammy was interested in open source'ing TSE.
Or somewhere in between, perhaps offering source access to a limited audience under NDA / controlled access. Several people (myself included) offered interest.
There's another idea that comes to mind that I don't recall having come up - open sourcing SC32.EXE.
Some interesting things could be done at the compiler level w/o runtime changes, though I suspect most of the meaty improvements will require changes in TSE itself.
How (if) Sammy wants to proceed is, IMO, the most interesting question.
TSE improvements are easy to enumerate (again). The big question is THE NEXT STEP.
Perhaps Sammy would like to chime in with his current thinking and plans.
- Howard
knud van eeden
> anyone even know if Brief or Epsilon Editor are even still around?
1983 - BRIEF: The Underware corporation releases the BRIEF (='B'asic 'R'econfigurable 'I'nteractive 'E'diting 'F'acility) text editor, written by Dave Nanian and Michael Strickman.
BRIEF was bought by Solution Systems,
then bought by Borland.
At Borland it was used as the text editor in some of their programming language IDEs.
===
Epsilon editor
http://www.lugaru.com/history.html
===
with friendly greetings,
Knud van Eeden
Howard Kapustein
- Howard
knud van eeden
with friendly greetings,
Mike Boyd
From: sem...@googlegroups.com [mailto:sem...@googlegroups.com] On Behalf Of Howard Kapustein
Sent: Sunday, April 19, 2009 1:21 PM
To: sem...@googlegroups.com
Subject: [TSE] Re: Desired text editing features
Heijer, Rob den
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
knud van eeden
> ... arrays, maybe?
See possibly also
http://www.faqts.com/knowledge_base/view.phtml/aid/31754/fid/1714
Howard Kapustein
There ARE things in SAL that could be improved. Strings for one. It's nice to be able to declare a fixed-size string sometimes (eg. when calling some native functions in DLLs), but most of the time it's a nuisance, and it's not too uncommon to handle strings >255 (TSE's limit). Especially these days, bigger strings are quite common. Given TSE's current behavior, if you need to handle strings that might be even slightly bigger, you're forced to use buffers. Makes sense when I'm handling 100M strings, but that 400 and 3K string are more annoying than anything else.
One option is a new data type, VarString, which acts like a string but is implemented as a facade over a buffer. Worst case that could be handled with just compiler changes (SC32.EXE). There's some warts doing that (e.g. debugging), but even that would provide a welcome enhancement w/o negatively impacting TSE.
A transpiler would work too, but that means writing your own TSE parser. Hmmm. Sammy, does SAL have a well defined grammar? You wouldn't happen to have an ABNF spec laying around would you? Or something like it?
- Howard
S.E. Mitchell
<howard.k...@gmail.com> wrote:
> A transpiler would work too, but that means writing your own TSE parser.
> Hmmm. Sammy, does SAL have a well defined grammar? You wouldn't happen to
> have an ABNF spec laying around would you? Or something like it?
Last one we did - looks best with a fixed width font:
0
LAST REVISION: 18-APR-1991
1. FEATURE: TF-19 Macro Syntax Diagrams
2. PURPOSE: Documents the high-level syntax of QEdit 3.0's
macro language.
3. USER INTERFACE: N/A. This may be included in the manual?
4. IMPLEMENTATION: Here are the diagrams (working from the top
down in the syntax):
Since curved lines are difficult to draw in ASCII, the
convention has been adopted here that forward pointing
arrows are always "below" the center line, and backward
pointing arrows (loopbacks) are always "above" the
center line.
Literal keywords are enclosed in quotes within their box.
|| Anything that is not alphanumeric (like "." or "_") that is
inside a box is also a literal symbol, the quotes
|| are left off for clarity.
|| Items that have changed lately are marked with vertical bars
"||" in the left margin.
DefinitionFile
══════════════
┌─────────<────────────────────────┐
│ │
│ ┌─────────────────────┐ │
────────┴──┬─>┤ KeyboardDefinition ├──┬───┴────────>
│ └─────────────────────┘ │
│ │
│ ┌─────────────────────┐ │
├─>┤ MacroDefinition ├──┤
│ └─────────────────────┘ │
│ │
│ ┌─────────────────────┐ │
├─>┤ ConfigDefinition ├──┤
│ └─────────────────────┘ │
│ │
│ ┌─────────────────────┐ │
├─>┤ Declaration ├──┤
│ └─────────────────────┘ │
||
|| ? ?
│ ┌─────────────────────┐ │
├─>┤ ClipboardDefinition ├──┤
│ └─────────────────────┘ │
│ │
│ ┌─────────────────────┐ │
└─>┤ MenuDefinition ├──┘
└─────────────────────┘
Notes:
|| Declarations at this level are "global" in scope.
ClipboardDefinition and MenuDefinition are not
currently implemented and may not be for this release.
Menus will probably end up being done directly in macros.
|| QMAC, when it is running, displays a "." for each
"loop" through this part of the syntax. So the number
|| of dots is the number of top-level declaration/definitions.
KeyboardDefinition
══════════════════
┌─────────┐ ┌───────────────┐
───>┤ KeyList ├─>┤ StatementList ├───────>
└─────────┘ └───────────────┘
|| Notes:
|| One of the very few parts of the language that is
context dependent is here, in the recognition of
|| KeyLists. The KeyList must be the *first* non
whitespace item on the line of text. The second key of
|| two keys in a key list must appear on the same line.
MacroDefinition
═══════════════
┌─────────┐ ┌────────┐
┌─────────────────┐ ┌───────────────┐ ┌────────────┐ ┌────────┐
───>┤ "MACRO" ├─>┤ Ident ├─┬──────────────┬─>┤
DeclarationList ├─>┤ StatementList ├─>┤ "ENDMACRO" ├─>┤ Ident ├───>
└─────────┘ └────────┘ │ ┌─────────┐ │
└─────────────────┘ └───────────────┘ └────────────┘ └────────┘
└─>┤ String ├─┘
└─────────┘
Notes:
Opening and closing Ident must match.
|| String is optional "macro name" which is visible while
in QEdit. The ExecuteNamedMacro command will use
|| these names.
|| The Ident name for the macro only exists at compile
time, not when loaded into QEdit.
Declarations must occur first, before other statements.
|| Declarations at this level are "local" in scope.
ConfigDefinition
════════════════
┌────────────<───────────────┐
│ │
┌──────────┐ │ ┌─────────────────────┐ │ ┌─────────────┐
──>┤ "CONFIG" ├─┬─┴──>┤ AssignmentStatement ├──┴─┬──>┤ "ENDCONFIG" ├──>
└──────────┘ │ └─────────────────────┘ │ └─────────────┘
│ │
└────────────────>───────────────┘
Notes:
Used by/with QCONFIG to assign configuration variables
in a text form.
|| Naturally, only certain variables (those which appear
in the permanently configurable part of QEdit) are
|| legal for use in this context.
|| The Expressions in these assignment statements MUST be
ConstExpressions.
DeclarationList
═══════════════
┌───────────<───────┐
│ │
│ ┌─────────────┐ │
────┬─┴─>┤ Declaration ├──┴─┬────>
│ └─────────────┘ │
│ │
└────────────────>──────┘
|| Declaration
|| ═══════════
|| ┌─────────────────────┐
|| ───┬──>┤ IntegerDeclaration ├──┬──>
|| │ └─────────────────────┘ │
|| │ ┌─────────────────────┐ │
|| ├──>┤ StringDeclaration ├──┤
|| │ └─────────────────────┘ │
|| │ ┌─────────────────────┐ │
|| └──>┤ ConstantDeclaration ├──┘
|| └─────────────────────┘
|| Notes:
|| Declarations at top-level (see DefinitionFile) are
GLOBAL in scope and persist until the end of
|| compilation. Declarations within a
MacroDefinition are LOCAL in scope, and cease to exist at the
|| end of the macro. Local declarations can
supersede like-named global declarations.
|| IntegerDeclaration
|| ══════════════════
┌───┐
┌───────────────────┤ , ├<────────────────────┐
│ └───┘ │
┌────────────┐ v ┌───────┐ │
───>┤ "INTEGER" ├───>┤ Ident ├──┬────────────────────────────┬──┴───>
└────────────┘ └───────┘ │ │
│ ┌───┐ ┌─────────────────┐ │
|| └─>┤ = ├>┤ ConstExpression ├─┘
└───┘ └─────────────────┘
|| Notes:
|| The optional ConstExpression supplies the initial value
of the declared integer. Naturally, it must
|| resolve to an integer constant.
||
|| On an IntegerDeclaration inside a MacroDefinition (a
local variable), the requirement that the initializer
|| be a ConstExpression is relaxed: any legal
Expression will be allowed.
|| StringDeclaration
|| ═════════════════
┌───┐
┌───────────────────────────────────┤ ,
├<──────────────────────────────────┐
│ └───┘
│
┌────────────┐ v ┌───────┐ ┌───┐ ┌─────────────────┐
┌───┐ │
|| ──>┤ "STRING" ├───>┤ Ident ├>┤ [ ├>┤ ConstExpression ├>┤ ]
├─┬────────────────────────────┬─┴──>
└────────────┘ └───────┘ └───┘ └─────────────────┘
└───┘ │ │
│ ┌───┐ ┌─────────────────┐ │
||
└─>┤ = ├>┤ ConstExpression ├─┘
└───┘ └─────────────────┘
|| Notes:
|| The required ConstExpression supplies the maximum
length of the string, and must resolve to an integer in
|| the range 1..1024.
||
|| The optional ConstExpression supplies the initial value
of the declared string. Naturally, it must
|| resolve to an string constant.
||
|| On an StringDeclaration inside a MacroDefinition (a
local variable), the requirement that the initializer
|| be a ConstExpression is relaxed: any legal
Expression will be allowed.
|| ConstantDeclaration
|| ═══════════════════
|| ┌───┐
|| ┌───────────────────┤ , ├<────────────────────┐
|| │ └───┘ │
|| ┌────────────┐ v ┌───────┐ │
|| ───>┤ "CONSTANT" ├───>┤ Ident ├──┬────────────────────────────┬──┴───>
|| └────────────┘ └───────┘ │ │
|| │ ┌───┐ ┌─────────────────┐ │
|| └─>┤ = ├>┤ ConstExpression ├─┘
|| └───┘ └─────────────────┘
||
|| Notes:
|| CONSTANT declares a compile-time constant. It is
simply a programmer's convenience, such constants take
|| no space at run time.
||
|| Right now, CONSTANT only allows INTEGER constants.
Later, strings will be allowed. The type of the
|| constant is automatically determined from the type
of the expression.
StatementList
═════════════
┌───────────────<────────────────┐
│ │
v │
─────┬───────────────────────────┬─┴───>
│ ┌─────────────────────┐ │
├─>┤ AssignmentStatement ├──┤
│ └─────────────────────┘ │
│ ┌─────────────────────┐ │
├─>┤ FunctionCall ├──┤
│ └─────────────────────┘ │
│ ┌─────────────────────┐ │
├─>┤ IfStatement ├──┤
│ └─────────────────────┘ │
│ ┌─────────────────────┐ │
├─>┤ WhileStatement ├──┤
│ └─────────────────────┘ │
│ ┌─────────────────────┐ │
├─>┤ RepeatStatement ├──┤
│ └─────────────────────┘ │
│ ┌─────────────────────┐ │
├─>┤ LoopStatement ├──┤
│ └─────────────────────┘ │
|| │ ┌─────────────────────┐ │
|| ├─>┤ CaseStatement ├──┤
|| │ └─────────────────────┘ │
│ ┌─────────────────────┐ │
├─>┤ "BREAK" ├──┤
│ └─────────────────────┘ │
│ ┌─────────────────────┐ │
├─>┤ GotoStatement ├──┤
│ └─────────────────────┘ │
|| │ ┌─────────────────────┐ │
|| ├─>┤ Label ├──┤
|| │ └─────────────────────┘ │
│ ┌─────────────────────┐ │
└─>┤ ReturnStatement ├──┘
└─────────────────────┘
Notes:
|| CaseStatement is not implemented yet.
||
|| Potential future additions here are a CONTINUE
statement (opposite of BREAK--jumps to top of loop), and a
|| FOR loop. Probably won't be in first release.
AssignmentStatement
═══════════════════
┌───────┐ ┌───┐ ┌───────────────┐
──>┤ Ident ├──>┤ = ├──>│ Expression ├───────────────────>
└───────┘ └───┘ └───────────────┘
Notes:
The "=" means assignment here, but it means "is equal
to" within expressions.
FunctionCall
════════════
┌───────┐
──>┤ Ident ├──┬─────────────────────────────────────┬───>
└───────┘ │ ┌───┐ │
│ ┌──────┤ , ├──────┐ │
│ │ └───┘ │ │
│ ┌───┐ v ┌────────────┐ │ ┌───┐ │
└─>┤ ( ├────>┤ Expression ├─┴─>┤ ) ├──┘
└───┘ └────────────┘ └───┘
Notes:
This includes both built-in commands and functions, as
well as user defined named macros.
|| There is a special "repeating" syntax used here for
commands and functions that do not accept parameters.
|| Simply enclose a single INTEGER expression in the
parentheses, and the command/function will be repeated
|| that many times.
IfStatement
═══════════
┌────────<──────────────┐
│ │
┌──────────┐ v │
┌─────────┐
──>┤ IfClause
├───┬───────────────────┬─┴─┬─────────────────┬─>┤ "ENDIF" ├─>
└──────────┘ │ │ │ │
└─────────┘
│ ┌──────────────┐ │ │ ┌────────────┐ │
└─>┤ ElseIfClause ├─┘ └─>┤ ElseClause ├─┘
└──────────────┘ └────────────┘
IfClause
════════
|| ┌──────┐ ┌────────────┐ ┌───────────────┐
|| ──>┤ "IF" ├─>┤ Expression ├─>┤ StatementList ├───>
|| └──────┘ └────────────┘ └───────────────┘
|| Notes:
|| There used to be a "THEN" keyword after the Expression here.
ElseIfClause
════════════
|| ┌──────────┐ ┌────────────┐ ┌───────────────┐
|| ──>┤ "ELSEIF" ├─>┤ Expression ├─>┤ StatementList ├──>
|| └──────────┘ └────────────┘ └───────────────┘
|| Notes:
|| There used to be a "THEN" keyword after the Expression here.
ElseClause
══════════
┌────────┐ ┌───────────────┐
──>│ "ELSE" ├──>┤ StatementList ├──>
└────────┘ └───────────────┘
WhileStatement
══════════════
|| ┌─────────┐ ┌────────────┐ ┌───────────────┐ ┌────────────┐
|| ──>┤ "WHILE" ├─>┤ Expression ├─>┤ StatementList ├─>┤ "ENDWHILE" ├──>
|| └─────────┘ └────────────┘ └───────────────┘ └────────────┘
|| Notes:
|| There used to be a "DO" keyword after the Expression here.
RepeatStatement
═══════════════
┌──────────┐ ┌───────────────┐ ┌─────────┐ ┌────────────┐
──>┤ "REPEAT" ├──>┤ StatementList ├──>┤ "UNTIL" ├──>┤ Expression ├──>
└──────────┘ └───────────────┘ └─────────┘ └────────────┘
LoopStatement
═════════════
┌────────┐ ┌───────────────┐ ┌───────────┐
──>┤ "LOOP" ├──>┤ StatementList ├──>┤ "ENDLOOP" ├──>
└────────┘ └───────────────┘ └───────────┘
|| CaseStatement
|| ═════════════
|| ┌───────<─────────────┐
|| │ │
|| ┌──────────┐ ┌────────────┐ v ┌──────────────┐ │
┌───────────┐
|| ──>┤ "CASE" ├─>┤ Expression ├─────>┤ SelectClause
├──┴─┬──────────────────────┬─>┤ "ENDCASE" ├─>
|| └──────────┘ └────────────┘ └──────────────┘ │
│ └───────────┘
|| │
┌─────────────────┐ │
|| └─>┤
OtherwiseClause ├─┘
||
└─────────────────┘
||
|| Notes:
|| This is not implemented yet.
||
|| The keywords "CASE", "SELECT", "OTHERWISE" and
"ENDCASE" are not yet carved in stone. Suggestions of
|| alternatives are welcome. However be warned that
"OTHERWISE" *cannot* be changed to "ELSE" (a la
|| Turbo Pascal) without introducing ambiguities in the syntax.
||
|| The expression must resolve to a scalar quantity
INTEGER, BOOLEAN, etc.
|| SelectClause
|| ════════════
|| ┌──────────┐ ┌─────────────────┐
┌───────────────┐
|| ──>┤ "SELECT" ├─>┤ ConstExpression
├──┬────────────────────────────────┬─>┤ StatementList ├──>
|| └──────────┘ └─────────────────┘ │
│ └───────────────┘
|| │ ┌────┐
┌─────────────────┐ │
|| └─>┤ .. ├──>┤
ConstExpression ├──┘
|| └────┘ └─────────────────┘
||
|| Notes:
|| This is not implemented yet.
||
|| The expression(s) must resolve to a CONSTANT expression.
|| OtherwiseClause
|| ═══════════════
|| ┌─────────────┐ ┌───────────────┐
|| ──>│ "OTHERWISE" ├──>┤ StatementList ├──>
|| └─────────────┘ └───────────────┘
||
|| Notes:
|| This is not implemented yet.
GotoStatement
═════════════
┌──────────┐ ┌────────┐
───┬──>┤ "JUMP" ├──┬──>┤ Ident ├─┬────────┬────>
│ └──────────┘ │ └────────┘ │ ┌───┐ │
│ ┌──────────┐ │ └─>┤ : ├─┘
├──>┤ "JTRUE" ├──┤ └───┘
│ └──────────┘ │
│ ┌──────────┐ │
├──>┤ "JFALSE" ├──┤
│ └──────────┘ │
│ ┌──────────┐ │
└──>┤ "GOTO" ├──┘
└──────────┘
Notes:
This is mainly for compatibility with 2.1, since of
course we don't want to encourage this sort of thing
amongst our users. <grin>
|| The optional colon after the label identifier is for
2.1 compatibility as well.
Goto is just a convenient familiar synonym for Jump.
Not implemented yet, but: QMAC will issue a warning
(only once per session) when compiling a Jump,
encouraging folks to convert to the new conditional &
looping constructs. (Not on "GOTO", however ).
Label
═════
┌───────┐ ┌───┐
──>┤ Ident ├─>┤ : ├──>
└───────┘ └───┘
Notes:
This defines a label that can be used as the target of
a GotoStatement. Execution resumes at the next
statement after the label.
ReturnStatement
═══════════════
|| ┌──────────┐
|| ──>┤ "RETURN" ├─┬───────────────────┬────>
|| └──────────┘ │ │
|| │ ┌────────────┐ │
|| └─>│ Expression ├───┘
|| └────────────┘
Notes:
"Return" used to be a named function in QEdit. Now
that function is called "CReturn".
|| Inside KeyDefinitions, the optional Expression is ILLEGAL.
|| Inside MacroDefintions, the optional Expression is REQUIRED.
|| The expression must evaluate to a numeric type,
preferably a boolean TRUE or FALSE (for use with
|| RepeatCommand) but any numeric value is allowed.
KeyList
═══════
|| ┌─────────────┐
|| ────>┤ FullKeyName ├──┬────────────────────┬──>
|| └─────────────┘ │ │
|| │ ┌─────────────┐ │
|| └──>┤ FullKeyName ├──┘
|| └─────────────┘
|| Notes:
|| As noted earlier, a KeyList must be the first
non-whitespace on a line. It does NOT have to be in column 1 as
|| in QEdit 2.1, however.
|| The second key of a two key must be on the same line.
FullKeyName
═══════════
|| ┌────────────────────┐
|| ┌───┐ v │ ┌─────────┐ ┌───┐
|| ──>┤ < ├──┬────┬───────────────┬──┴──>┤ KeyName ├──┬───>┤ > ├───>
|| └───┘ │ │ ┌──────────┐ │ └─────────┘ │ └───┘
|| │ └─>┤ ShiftKey ├─┘ │
|| │ └──────────┘ │
|| │ │
|| │ ┌─────────┐ │
|| ├─>┤ Integer ├───────────────────────────┤
|| │ └─────────┘ │
|| │ ┌─────────┐ ┌─────────┐ │
|| └─>┤ Integer ├─>┤ Integer ├──────────────┘
|| └─────────┘ └─────────┘
|| Notes:
|| While multiple shift keys are allowed by the above
syntax, the current keyboard scanner in QEdit itself
|| only recognizes legal BIOS keys, none of which
have multiple shifts. Multiple shift state keys may
|| come into play later, with the TSR version, etc.
||
|| The integer forms allow "non standard" keys to be
assigned. There are three separate varieties of this:
||
|| (1) The single integer form of a key assignment is
compatible with numeric assignments in QEdit 2.1: it
|| specifies a key whose ASCII code is 0, and whose
Scan code is the specified number.
|| The scan code must be in the range of 0 to 255 inclusive.
||
|| (2) If the single integer is greater than 255 (the
maximum value for a scan code), it is assumed to
|| be both the ASCII code plus scan code together in
the same form returned by the BIOS.
||
|| (3) If two integers are specified, the first is assumed
to be an ASCII code, the second a Scan code.
||
|| SHOWKEY is useful in determining the integer forms for
various non-standard keys.
|| ShiftKey
|| ════════
|| ┌───┐
|| ─────┬─>┤ # ├────────┬──────>
|| │ └───┘ │
|| │ ┌───┐ │
|| ├─>┤ ^ ├────────┤
|| │ └───┘ │
|| │ ┌───┐ │
|| ├─>┤ @ ├────────┤
|| │ └───┘ │
|| │ ┌─────────┐ │
|| ├─>┤ "SHIFT" ├──┤
|| │ └─────────┘ │
|| │ ┌─────────┐ │
|| ├─>┤ "CTRL" ├──┤
|| │ └─────────┘ │
|| │ ┌─────────┐ │
|| └─>┤ "ALT" ├──┘
|| └─────────┘
||
|| Notes:
|| The new style shift designators ("Shift", "Ctrl" and
"Alt") obviously requires some whitespace between
|| themselves and the KeyName to be distinguishable. The
old (2.1) style shift designators do not require this.
||
|| The first three shift designators (the old style ones)
are intended only for 2.1 compatibility.
|| Users should move to the new names when developing new macros.
KeyName
═══════
┌──────────────────────<───────────┐
│ │
v ┌───────────────────────────┐ │
|| ─────────>┤ non-whitespace except ">" ├──┴─────>
└───────────────────────────┘
|| Notes:
|| There is a fixed predeclared list of 93 keynames. For
keys which have more than one graphic symbol on
|| them (example "8" and "*") the LOWER or UNSHIFTED
symbols are always used.
|| ConstExpression
|| ═══════════════
|| ┌────────────┐
|| ───>┤ Expression ├──>
|| └────────────┘
||
|| Notes:
|| Must resolve to a constant value at compile time.
||
|| Not yet fully implemented: most places where
ConstExpression is called for right now only allow simple
|| literal constants.
Expression
══════════
┌──────────────────┐
───>┤ SimpleExpression ├──┬─────────────────────────────────────┬──>
└──────────────────┘ │ │
│ ┌────┐ ┌──────────────────┐ │
└──┬─>┤ = ├──┬─┤ SimpleExpression ├──┘
│ └────┘ │ └──────────────────┘
│ ┌────┐ │
├─>┤ <> ├──┤
│ └────┘ │
│ ┌────┐ │
├─>┤ < ├──┤
│ └────┘ │
│ ┌────┐ │
├─>┤ <= ├──┤
│ └────┘ │
│ ┌────┐ │
├─>┤ > ├──┤
│ └────┘ │
│ ┌────┐ │
└─>┤ >= ├──┘
└────┘
SimpleExpression
════════════════
┌────┐
┌───┤ + ├<──┐
│ └────┘ │
│ ┌────┐ │
├───┤ - ├<──┤
│ └────┘ │
│ ┌────┐ │
├───┤ OR ├<──┤
│ └────┘ │
│ │
v ┌──────┐ │
──┬────────┬────>┤ Term ├──┴────>
│ │ └──────┘
│ ┌───┐ │
├─>┤ + ├─┤
│ └───┘ │
│ ┌───┐ │
└─>┤ - ├─┘
└───┘
Notes:
The first occurrence of "-" and "+" in the above
represent "unary" operators. Really "-" is the only one
|| that makes sense there. "+" is simply passed over and ignored.
The operators "-", "+" and "OR" are the "Addition Operators".
Term
════
┌─────┐
┌────┤ * ├<──┐
│ └─────┘ │
│ ┌─────┐ │
├────┤ / ├<──┤
│ └─────┘ │
│ ┌─────┐ │
├────┤ AND ├<──┤
│ └─────┘ │
│ ┌─────┐ │
├────┤ MOD ├<──┤
│ └─────┘ │
│ │
v ┌────────┐ │
────>┤ Factor ├──┴───────>
└────────┘
Notes:
The operators "*", "/", "AND" and "MOD" are the
"Multiplication Operators".
Since we only define INTEGERS in this language, by
definition the "/" operator is an integer division.
Factor
══════
┌──────────────┐
──┬────────────┬──┬─>┤ Integer ├──────────────┬──>
│ │ │ └──────────────┘ │
│ ┌───────┐ │ │ ┌──────────────┐ │
└─>┤ "NOT" ├─┘ ├─>┤ String ├──────────────┤
└───────┘ │ └──────────────┘ │
│ ┌──────────────┐ │
├─>┤ Ident ├──────────────┤
│ └──────────────┘ │
│ ┌──────────────┐ │
├─>┤ FunctionCall ├──────────────┤
│ └──────────────┘ │
│ ┌───┐ ┌────────────┐ ┌───┐ │
└─>┤ ( ├──┤ Expression ├──┤ ) ├──┘
└───┘ └────────────┘ └───┘
Notes:
The Ident above would be a reference to a variable or constant.
Ident
═════
┌─────────────────────┐
│ │
┌────────┐ v │
──┬─>┤ letter ├──┬─────┬──────────────┬───┴──────>
│ └────────┘ │ │ ┌────────┐ │
|| │ ┌────────┐ │ ├─>┤ letter ├──┤
|| └─>┤ "_" ├──┘ │ └────────┘ │
|| └────────┘ │ ┌────────┐ │
├─>┤ digit ├──┤
│ └────────┘ │
│ ┌────────┐ │
└─>┤ "_" ├──┘
└────────┘
Notes:
|| Maximum length is the line length, currently 512.
Maximum *significant* length is 32 characters.
Identifiers are NOT case sensitive (neither are
language keywords).
|| In *predeclared* identifiers, but NOT keywords, the
underscores are NOT significant. So, for example,
|| CRETURN, CReturn, c_return and c_ret_urn all refer
to the same predeclared command.
|| Again, this does NOT apply to user-declared identifiers.
|| Integer
|| ═══════
|| ┌─────────────────────┐
|| │ │
|| ┌────────┐ v │
|| ────>┤ digit ├────────┬──────────────┬───┴──────>
|| └────────┘ │ │
|| │ ┌────────┐ │
|| └─>┤ digit ├──┘
|| └────────┘
|| Notes:
|| Integers are base 10 (decimal), and have a 32 bit
signed range. (From -2,147,483,648 to +2,147,483,647).
||
|| It's not implemented yet, but we may allow HEX integers too.
String
══════
┌───────────────<─────────────┐
│ │
┌───┐ v │ ┌───┐
───┬─>┤ " ├──────┬─────────────────────┬───┴───>┤ " ├─┬───>
│ └───┘ │ ┌───────────┐ │ └───┘ │
│ └───>┤ character ├────┘ │
│ └───────────┘ │
│ │
│ ┌───────────────<─────────────┐ │
│ │ │ │
│ ┌───┐ v │ ┌───┐ │
└─>┤ ' ├──────┬─────────────────────┬───┴───>┤ ' ├─┘
└───┘ │ ┌───────────┐ │ └───┘
└───>┤ character ├────┘
? └───────────┘ ?
│ │
│ ┌───┐ ┌───────────┐ │
└─>┤ # ├──────────>┤ Integer ├───────────────────┘
└───┘ └───────────┘
Notes:
|| Not implemented yet, but ASCII codes and such can be
embedded inside strings using the same syntax
|| as in regular expressions. (i.e. \d###, \x### etc.)
|| The quote character can be embedded in a string that it
quotes by doubling it up. For instance, the
|| token:
|| "this is a ""string"" right here"
|| defines the following string:
|| this is a "string" right here
|| ...this is just as in QEdit 2.1.
|| The # + integer syntax is not implemented yet.
|| Boolean
|| ═══════
|| ┌──────────┐
|| ───┬──>┤ "TRUE" ├──┬──>
|| │ └──────────┘ │
|| │ ┌──────────┐ │
|| └──>┤ "FALSE" ├──┘
|| └──────────┘
||
|| Notes:
|| The two Boolean constants TRUE and FALSE are
predeclared as TRUE = 1, and FALSE = 0.
||
|| Boolean's are type compatible (NOT QUITE YET) with
INTEGERS, and for purposes of testing (e.g. in IF
|| statements) any NONZERO value is considered TRUE,
while 0 is FALSE.
|| ClipboardDefinition (MAY NOT BE IMPLEMENTED)
|| ═══════════════════
┌──────────────┐ ┌──────────┐ ┌────────┐ ┌──────┐
┌────────────────┐
───>┤ "CLIPBOARD" ├─>┤ ClipType ├─>┤ String ├─>┤ text ├─>┤
"ENDCLIPBOARD" ├─>
└──────────────┘ └──────────┘ └────────┘ └──────┘
└────────────────┘
Notes:
This is a way of defining a named clipboard that will
automatically be initialized at the time this macro
is loaded.
The QuickHelp screen will simply be a
ClipboardDefinition just like this, with the reserved name of
"<Help>". (This is handled transparently behind
the users back). Doing this this way would afford
the user a way to consolidate QCONFIG.DAT and
QHELP.TXT if they wish to.
In order to not unduly restrict the content of the
clipboard, the ENDCLIPBOARD keyword must occur first
on a line.
|| ClipType (MAY NOT BE IMPLEMENTED)
|| ════════
┌─────────────┐
───┬──>┤ "LINE" ├───────────────────────────────────┬───>
│ └─────────────┘ │
│ ┌─────────────┐ │
├──>┤ "CHARACTER" ├───────────────────────────────────┤
│ └─────────────┘ │
│ ┌─────────────┐ ┌───┐ ┌────────────┐ ┌───┐ │
└──>┤ "COLUMN" ├──>┤ [ ├──>┤ Integer ├──>┤ ] ├──┘
└─────────────┘ └───┘ └────────────┘ └───┘
Notes:
The free-form text always starts on the line after the
end of the string which names the clipboard.
A CHARACTER clipboard includes from the beginning of
that line, to the end of the last line prior to
"ENDCLIPBOARD", not inclusive of the last line
break. If you wish to include line breaks at the
beginning or end of a character Clipboard, leave
blank lines.
The integer on a COLUMN type indicates the width in
columns. Column 1 is assumed to be the left column.
|| MenuDefinition (MAY NOT BE IMPLEMENTED)
|| ══════════════
┌────────────────┐
│ │
┌────────┐ ┌────────┐ │ ┌───────────┐ │ ┌───────────┐
┌────────┐
──>┤ "MENU" ├─>┤ Ident ├─┴─>┤ MenuItem ├─┴─>┤ "ENDMENU"
├──>┤ Ident ├───>
└────────┘ └────────┘ └───────────┘ └───────────┘
└────────┘
Notes:
The Ident "MainMenu" is reserved for QEdit's own top
level menu, which is handled specially. Users can
redefine it, but they cannot define other "top
level" menus that act like it. (In other words,
there can be only ONE pull down menu "bar", and
that is the one called "MainMenu").
The user can call the MENU Ident from a macro just as
if it were a macro. It returns a numeric
value indicating which menu option was selected,
or zero if user cancelled.
MenuItem
════════
┌────────┐ ┌────────┐ ┌─────────┐ ┌───────┐ ┌────────────┐
──>┤ "ITEM" ├─>┤ String ├─>┤ Boolean ├─>┤ Ident ├─>┤ Integer ├──>
└────────┘ └────────┘ └─────────┘ └───────┘ └────────────┘
Notes:
The String contains the actual menu text. The "quick
key" for that menu (not to be confused with a
keyboard definition key) is preceded with a "~" in
the string.
The Boolean indicates whether the user wishes QMAC to
add the human readable name (example: <Alt X>) of
the keyboard definition that executes this same
command, to the menu item. Letting QMAC do this
makes QCONFIG.DAT more maintainable, but some
users may not want hot keys in all their menu items.
The Ident is the identifier of what this menu option
should do. If this is a Variable, then this menu
item merely enters the value of this variable. If
this is a Macro or built-in function name, then
this menu item executes that function. If this is
a Menu name, then this menu item chains to that
menu.
The Integer is the context number to pass to the
context-sensitive help handler if help on this item is
requested.
Because users will probably expect them, we will allow
optional commas between the items.
How about options to have a menu run the option &
return to menu, rather than run it and close the menu??
(Idea from D. Marcus)
|| BlockComment (REMOVED)
|| ════════════
┌─────────────<──────────────┐
│ │
┌───────────┐ │ │ ┌──────────────┐
──>┤ "COMMENT" ├─┴──┬─────────────────────┬───┴──>┤ "ENDCOMMENT" ├──>
└───────────┘ │ │ └──────────────┘
│ ┌───────────────┐ │
└──>┤ lines of text ├─┘
└───────────────┘
Notes:
The token "ENDCOMMENT" must be the first item on the
the line on which it appears (disregarding leading
white space).
5. IMPACT/ISSUES: Certain items in the above, particularly
ConfigDefinition and ClipboardDefinition are very
tentative.
Here is an example of a MENU definition, using the menu bar
and Search menus of the current QEdit as an example:
MENU MainMenu
ITEM "~File" FALSE FileMenu 0
ITEM "~Window" FALSE WindowMenu 0
ITEM "~Block" FALSE BlockMenu 0
ITEM "~Search" FALSE SearchMenu 0
ITEM "~Print" FALSE PrintMenu 0
ITEM "~Macro" FALSE MacroMenu 0
ITEM "~Editing" FALSE EditingMenu 0
ITEM "~Other" FALSE OtherMenu 0
ITEM "~Quit" FALSE QuitMenu 0
ENDMENU
MENU SearchMenu
ITEM "~Find" FALSE Find 0
ITEM "~Replace" FALSE FindReplace 0
ITEM "~Again" FALSE RepeatFind 0
ENDMENU
All hotkey listings and help contexts are set to nothing here.
The definitions of Expression, SimpleExpression, Term and Factor are
all very similar to that used in Pascal and Modula-2. This results
in an order of precedence of operators as follows:
1. (Highest) NOT (Unary Operators)
2. *, /, AND (Multiplication Operators)
3. +, -, OR (Addition Operators)
4. (Lowest) =, <>, <, >, <=, >= (Relational Operators)
Operators at same level have equal precedence, and are
evaluated from left to right.
When something has an operator to the left and to the right,
it "binds" to the operator with the higher
precedence, or else to the one on the left.
6. REVISIONS: 30-Nov-1990. StatementList modified to include
possibility of a NULL statement. (Loop across it
on the bottom).
Statement modified not to include Declaration, and new
definition DeclarationList added. This reflects the
fact that variable declarations cannot be interspersed with
normal statements---all variables within a macro
must occur at the top of the macro. MacroDefinition modified
to reflect this.
KeyDefinition now disallows local variable declarations as a result.
DefinitionFile modified to add optional semicolons.
About the mandatory trailing semicolon on RETURN statements:
it appears that QMAC will be able to determine
from syntactic context whether an expression is necessary, so
it may not be mandatory in the final shipping
QMAC.
18-Apr-1991. Revisions to bring document in line with
actual implementation.
Clipboards and Menus noted as not currently implemented, and
moved to end of document.
Notes on context-dependency of KeyLists written.
Other miscellaneous notes added to various definitions.
CASE statement added. FOR statement removed, except for comments.
Various "synonyms" removed to make syntax more rigid.
The "THEN" in IF/THEN/etc and the "DO" in WHILE/DO removed.
Fixed the diagram for "RETURN". (See note above about RETURN
contexts).
Renamed VariableDeclaration to just Declaration.
Added "CONSTANT" to Declaration.
Fixed FullKeyName to include decimal key codes.
Added ShiftKey and Integer diagrams.
BlockComment noted removed & moved to bottom of list.
Declaration split into three separate definitions to reduce
complexity of diagrams.
Boolean added.
All references to semicolons removed.
Label broken out of Statement (falsely implied that a label
had to have a real statement following it, which is
not true.
StatementList and Statement merged.
2
Why Tea
On Apr 20, 9:13 am, "Mike Boyd" <mb...@atlis.com> wrote:
> Hello all,
>
> I have used TSE since its beginnings. In my opinion, nothing comes close
> to its ease and benefits
case. Not anymore, as many text editors have caught up. Besides,
the limitation of memory and storage are no longer an issue. With
today's CPU, speed is not a problem either. So, what makes Tse
attractive in today's environment? I think because we are all
very familiar with it. To me, I pick the power of the scripting
language to be my main reason of staying with Tse because I'm
so used to the customized macros I wrote over the years.
When I was trying out various Windows free text editors, I
noticed that many of the Tse features implemented in macros
were standard features. I won't mention some of the nice
features that can only be done in GUI. I have tried and kept
notepad++, pspad and RJ Texted. Just for the sake of comparison,
have a look at R J Texted: http://www.rj-texted.se/ about
the following features:
- search/extended search
- scripting (in 4 languages with "stepping")
- syntax highlight
- unicode support and encoding conversion
- inbuilt nc-like file manager, ftp client
- etc.
With such a full list of features, it's still remarkably
easy to use.
Like many of you, I have used Qedit since the Dos days
before Tse came along. I'd love to see Tse evolve into
a more modern editor and live for many years to come.
Robert Seely
> When I was trying out various Windows free text editors, I
> noticed that many of the Tse features implemented in macros
> were standard features. I won't mention some of the nice
...
It isn't clear from what you say whether or not these editors can
execute commands from within the editor* - a basic function I use in
TSE every day many times over. (Of course it's something emacs could
always do, but the only way I'd be really happy with emacs would be to
recreate my tse environment in it - and why not just use tse!?!)
-= rags =-
* PS - if it's not clear what I mean by this, here's an example. You
are working on your (eg) tex file, you then hit a key making the
editor save the file, execute tex on the file (to compile the code),
then returns to your spot in the tex file when it finishes.
Similarly you could launch a viewer, a spell checker, or whatever,
always returning to your spot in the file (while the command
executes in the background.
Hayes Smith
I hope it remains as flexible, simple,
and powerful as it is now. Hayes Smith
or 
, depending on your viewpoint. Howard Kapustein
Howard Kapustein
knud van eeden
knud van eeden
Hayes Smith
----- Original Message -----From: knud van eedenSent: Tuesday, April 21, 2009 11:43 AMSubject: [TSE] Re: Desired text editing features
knud van eeden
From: knud van eeden <knud_va...@yahoo.com>
To: sem...@googlegroups.com
Sent: Tuesday, April 21, 2009 6:39:43 PM
Subject: [TSE] Re: Desired text editing features
knud van eeden
> What is code folding or text folding, exactly?
If you ever worked with Lotus Notes mail client, in which they had created with databases, you possibly remember that text folding feature, where it is used heavily.
I currently personally do not have a strong need to use such a feature.
I like to see it all.
Of course if it is implemented in TSE it will be used.
knud van eeden
Ed Ahlsen-Girard (TYBRIN Corp.)
Hopefully I’ll get the Linux version running under OpenBSD. My bonds of affection with vi are strained.
--
Ed Ahlsen-Girard
Senior Network Engineer
TYBRIN Corporation
tybrin.com
850-337-2830 (mobile 850-543-9843)
850-337-2885 (fax)
This e-mail and any files transmitted with it are the property
of TYBRIN Corporation, are TYBRIN PROPRIETARY, and are intended solely for the
use of the individual or entity to which this email is addressed. If you
are not one of the named recipient(s) or otherwise have reason to believe that
you have received this message in error, please delete this message
immediately. Any other use, retention, dissemination, forwarding, printing, or
copying of this e-mail is strictly prohibited.
From:
sem...@googlegroups.com [mailto:sem...@googlegroups.com] On Behalf Of Hayes
Smith
Sent: Tuesday, April 21, 2009 10:36 AM
To: sem...@googlegroups.com
Subject: [TSE] Re: Desired text editing features
I might also mention that it is well to remember what TSE's purpose for existing is. TSE is a text editor, not a word processor or exotic utility. For producing prodigious amounts of text or programming code, there's none better.
Jim Wilson
> fundamental improvements most would find helpful. Some, yes, but only
> some.
I'm a bit surprised by this statement; you're probably the first programmer I have ever heard say that folding was not completely indispensible, once they've used it. To me, it's as critical as the projects feature. Personally, I'd find it hard to live without either.
Just curious; what type of programming are you involved with?
Regards,
Jim
____________________________________________________________
FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop!
Check it out at http://www.inbox.com/earth
Howard Kapustein
Howard Kapustein
Why Tea
> I WAS saddened to learn that a Linux version was coming rather than a Mac version. I've been itching to buy a Mac for ages and would have had a TSE been written for it.
many wonderful apps around apart from Tse. Not trying to be cynical,
that could also explain why you can't remember or don't know what code
folding is. I tie this to users who are unwilling to learn another
editor when one works well and does the job. Is there anything wrong
with the attitude? No (see The Editor War: http://en.wikipedia.org/wiki/Editor_war).
But you could be missing all the fun and innovations from other text
editors.
I still use Tse quite a lot. But I'm using less of it as there are
other editors that do certain tasks better than Tse - I know it's
scary to admit it, but it's true :)
Why Tea
> make me *constantly* yearn for TSE.
> And yes, I tried several. Bleh.
you don't have to change a thing in nedit. Like any serious Unix
editor, it comes with a decent macro language. I managed to port all
of my most frequently used Tse macros across and never look back. In
any case, for any serious Unix (not just Linux) user, on top of the
GUI editor of choice one should at least know how to use vi as well.
Howard Kapustein
But when it comes to a programmer's editor, I find TSE fits my use *better* than the alternatives.
And I never said I forgot or didn't know what code folding is. I've used several editors that support it.
I just don't find it personally compelling.
I found TextMate to be one of the better editors in my travels, but even that fell a bit short in some ways.
I never used TSE's template feature, so the whole I'll-paste-in-the-keyword-block-when-you-type-a-few-letters isn't very interesting to me.
But I have a good memory and type very fast, so it could just be me.
[Or it could be as I've routinely bounced amongst 2-3 editors concurrently in the past several years, such 'shortcuts' need to be highly consistent (unlikely) or they just slow me down.]
Now code completion with Intellisense is (usually) useful, though _smart_ Intellisense is where it really helps - I don't want a static list of completions, I want context-sensitive awareness and the ability to parse and know my code as well as 'built in' symbols. A full-blown language parser, and a forgiving one at that which understands incomplete or not-all-lines-compile-yet source. Eclipse is a pretty good model for this.
TextMate's "bundles" are nice, though I don't know I'd call it overly innovative. A decent packaging / distribution mechanism. Though I found most of the features provided via 'bundles' weren't useful for my usage.
To each their own.
- Howard
P.S. I did promise a friend I'd take another dive at Emacs. It's been about 4-5 years since my last foray, but now there's pymacs so maybe it's not so painful.
I still doubt it'll rival TSE :-)
Why Tea
> 4-5 years since my last foray, but now there's pymacs so maybe it's not so
> painful.
>
> I still doubt it'll rival TSE :-)
to re-program your fingers especially when you are a fast typist.
My own experience is that I usually have to un-learn some of the
Tse habits. The experience of different editors usually influences
both ways, you can implement Tse features in the "new" editor
and vice versa (via macro or scripting).
Why Tea
close the left window (click on X). Is it
better now?
Howard Kapustein
both ways, you can implement Tse features in the "new" editor
and vice versa (via macro or scripting).
I hate LISP.
It's one of the few languages I learned, that I have pretty much zero ability with.
My brain's just not wired right for it or something.
Pymacs is interesting as it binds Python to Emacs, supposedly comparably to LISP.
Let's be honest - SAL may seem limited, but it's actually a quite capable but easy and forgiving script language. That, plus the way TSE does keydefs makes it much easier to customize than most edtors. Well, easier than most configurable editors. [Most aren't configurable - options, yes, but not configurable in the same league as TSE, Emacs, and others]
- Howard
Guy Rouillier
the whole day editing, reviewing, or debugging code. I've been though
the Semware family of editors since the beginning (Qedit, Qedit for
OS/2, now TSE), so I'm very fast and productive with it.
I took a quick look at the two editors mentioned in this thread - RJ and
e. They seem okay, but nothing compelling enough for me to leave
something I know as well as TSE.
My editing needs run from the very simple - editing batch or script
files - for which TSE is perfectly suited; quick in and out editing of
simple text. The other end of my spectrum is large Java projects
(currently - previously C and C++). Since I have so much history in
TSE, my tendency is to edit files for large projects with TSE. But I've
begrudgingly accepted the benefits of an integrated environment like
Eclipse: context sensitive coding (pop-up lists of object methods, etc),
instant links to object declarations, etc. I don't see TSE ever getting
to that, and frankly, I wouldn't want to use Eclipse to edit a script file.
The problem with both e and RJ is that they are not as fast and flexible
as TSE, nor as full featured as Eclipse. I couldn't find in either one
an option to specify my coding style; I like indented curly braces like so:
if (x)
{
do something;
}
About the only need not met by TSE and Eclipse is for the occasional
test program. Having a tool that I could use to compile and
interactively debug would be handy; Eclipse is no good for that because
it requires a project.
Howard Kapustein wrote:
> I was serious, I _have_ looked around, regularly (about every 2-3
> years), and yes, there are many nice applications out there.
> But when it comes to a programmer's editor, I find TSE fits my use
> *better* than the alternatives.
>
> And I never said I forgot or didn't know what code folding is. I've used
> several editors that support it.
> I just don't find it personally compelling.
>
> I found TextMate to be one of the better editors in my travels, but even
> that fell a bit short in some ways.
> I never used TSE's template feature, so the whole
> I'll-paste-in-the-keyword-block-when-you-type-a-few-letters isn't very
> interesting to me
--
Guy Rouillier
Why Tea
> e. They seem okay, but nothing compelling enough for me to leave
> something I know as well as TSE.
something new :) But when you get to know it well enough, you
might actually find that it does certain things better.
I work in a multi-OS environment. Getting a Unix-er to even
try Tse is a major victory. Do they type fast? You bet. The
things they can do with vi is magic. Of course, it'll be the
same for you with Tse.
> instant links to object declarations, etc. I don't see TSE ever getting
> to that, and frankly, I wouldn't want to use Eclipse to edit a script file.
> The problem with both e and RJ is that they are not as fast and flexible
> as TSE, nor as full featured as Eclipse. I couldn't find in either one
> an option to specify my coding style; I like indented curly braces like so:
>
> if (x)
> {
> do something;
> }
up too much space and prefer the K&R style.
knud van eeden
FYI, I have something like 20 text editors (vi, emacs, notepad++, UltraEdit, SlickEdit, e-texteditor, ..., almost all main text editors as seen on Wikipedia) and tried and still installed on my computer, and still use only one, TSE (the Swiss army knife).
with friendly greetings,
Knud van Eeden
----- Original Message ----
From: Why Tea <ytl...@gmail.com>
To: SemWare <sem...@googlegroups.com>
Sent: Wednesday, April 22, 2009 1:03:31 AM
Subject: [TSE] Re: Desired text editing features
knud van eeden
And regarding IDEs, working regularly with Eclipse, Netbeans, Delphi IDE, and before with Microsoft Visual Studio. Very nice, very impressive, each with its own merits (automation, wizards, intellisense, syntax highlighting, ...) but for the text editing and utitlities using TSE.
----- Original Message ----
From: knud van eeden <knud_va...@yahoo.com>
knud van eeden
> I never used TSE's template feature, so the whole I'll-paste-in-the-keyword-block-when-you-type-a-few-letters isn't very interesting to me.
Interesting. Just to give some feedback, it really saves me much typing, having to remember, and reducing errors significantly. Retyping that same text out of the head will almost always introduce typing errors, having to look it up (how was that again?), maybe loosing time.
The idea is similarly to creating procedures and functions in a programming language. Reusing, centralizing, create once use many times, DRY, ....
Further examples, if I type the 3 characters
dot
it automatically inserts a minimal template for a GraphViz graph in my text.
digraph myGraph {
graph [style=bold, label="My Title"];
rotate="90";
center="true"
size="7,7";
rankdir = LR;
node [color=red style=filled fillcolor=lightyellow];
a0 -> a1;
"" -> "";
node [color=red style=filled fillcolor=lightblue];
a1 -> a2;
"" -> "";
node [color=red style=filled fillcolor=lightcyan];
a2 -> a3;
"" -> "";
node [color=red style=filled fillcolor=lightgrey];
a3 -> a4;
"" -> "";
}
(If I then type a bit of my text, highight that block, it will save that block to a .dot file, run a GraphViz program which converts it to a Postscript .ps file, then running Adobe Acrobat which runs Acrobat Distiller, which generates a PDF file with a nice colored graph).
In general, depending on the programming language (e.g. TSE SAL) I am working in, it will offer templates for that.
(Adapted) template.s and (auto)complete.s are the main macros. E.g. if I type ''GetF' in TSE it offers me 2 options 'GeTFreeHistory()' and 'GetFoundText()' and possibly showing the parameters.
In a text file, if I type 'o' it expands to 'Oracle', saving having to type about 5 characters more.
I maintain (currently about 3000) the abbreviations (with its corresponding template text) in a text file (each abbreviation in a record with in the header the abbreviation name and in the body the template text) using TSE macros.
Ed Ahlsen-Girard (TYBRIN Corp.)
Ubuntu is very popular right now. A very extensive, capable distribution is CENTOS, which is a free version of Red Hat Enterprise Linux, but it is very challenging for a newcomer, since it comes up with SELinux (security enhancements from NSA) enabled by default, and a whole lot of things will mysteriously not work until specifically configured.
I run OpenBSD, though, which is not a Linux at all, but a BSD.
Hayes Smith
----- Original Message -----Sent: Wednesday, April 22, 2009 7:57 AMSubject: [TSE] Re: Desired text editing features
Howard Kapustein
It's also based on Debian, so it inherits some pluses like Debian's package manager (apt). For someone who wants to learn Linux, I can't think of a better distro to start with than Ubuntu.
[Despite the fact I much prefer KDE over Gnome, I still recommend Ubuntu over others, including Kubuntu]
- Howard
Howard Kapustein
As a 20 year veteran 'PC' user and developer -- NT, 9x, Win16, OS/2 and all the way back to DOS - I can categorically and undeniably state I would far rather have a Mac Book Pro running Leopard than a Dell laptop running XP or Vista.
I lived that life. @ Amazon last year I...needed <g>...a Mac for the project I was working on, and got a 15" Mac Book Pro running Leopard. [OK, Amzon IT's slightly mucked up OS image, but that settled out after a few months.] I was working on the Kindle, mostly device side with a little server side, using primarily Java and SVN, with some Tomcat and Linux work. I had 3 machines:
* Dell desktop running RHEL 5
* Dell Latitude D630 running XP
* 15" Mac Book Pro running Leopard
Despite having to 'unlearn' some habits and muscle memory gained from years of Windows use, I found working on the Mac was a far more enjoyable experience, and went out of my way to stay there.
Eclipse (or Subclipse?) was occasionally unstable and needed to be restarted.
If you never thought you'd yearn to use Outlook, try living with Entourage.
It makes you yearn for Outlook *2003*. 2007 would be like mana from heaven.
I learned ZSH and only sometimes missed 4NT (mainly the popup windows for history and filename completion).
I lived in TextMate and Eclipse.
Despite having VMware Fusion loaded, I rarely booted the XP image.
Mac OS X has its warts.
Keyboard handling isn't quite as extensive as Windows; better than in past days, but if you lose your mouse, you're pretty much dead. [At least you can hit F10 or Alt to put focus on the menu in Windows.]
Double-clicking a window's title bar minimizes(!) the app; you have to use laser guided precision to tap the tiny little green Grow button to maximize.
Among other things.
That said, I'd choose a 15" MBP over an XP or Vista laptop right now if I had a choice.
Despite lacking TSE, I find it more interesting and enjoyable, and once you get over the learning curve - and find the right tools, more productive.
So I'm calling Shenanigans. Despite 22 years of TSE back thru Qedit for OS/2 to Qedit 2.x, I would switch to another editor if I could find a better tool for my needs.
I've looked. Regularly. I've yet to find something to fill TSE's shoes.
A testament to TSE's design and quality, and one which Sammy should be proud.
TSE is just a damned fine tool.
- Howard
P.S. I'd love to trade in this archaic contraption I've know for decades. I mean, it has *wheels*! How dated can you get! I'm still looking for that Atomic Powered Flying Car I was promised as a youth.
Ah well. I guess I'll have to settle for a Tesla :-)
Howard Kapustein
I never found enough standardization of some text that I'd reuse to warrant mucking with the templating (in any editor), and the usual trivial "if<space>"-injects-an-if-block is usually something I turn off as it's too trivial and slows me down.
But to each their own. As Lewis Black says, we're all unique little snowflakes
:-)
Jim Wilson
> Before that, a couple of years of Java with some Python.
> Before that, C++ or Java (or both) depending on the day, with the regular
> smattering of Python.
>
> I've used editors with Folding, but never really picked up the habit.
> Though I'll admit I use TSE's FunctionView rather heavily, as a
> symbol-goto.
>
> I've done C++ and a little C# in various releases of Visual Studio.
> I've done Java in Eclipse and occasionally NetBeans.
> I've done Python, Ruby, shell script, BATch files and a random sampling
> of other editing hacks. I've done HTML, CSS and Javascript on and off
> in various projects over the years.
> I've done XML and JSON on and off over the years.
Geez, it would have probably been easier to list the languages you don't program in then the ones you do. Would have been a shorter list... :-)
> >To me, it's as critical as the projects feature
> Another thing I've never been enthralled with.
>
> Yeah, I'm a dinosaur.
> Or it could just be my photographic memory. I use the 'project explorer'
> / whatever in IDEs, but don't overly miss it in TSE.
Just because your preferences don't mirror most others doesn't necessarily make you a "dinosaur". Different perhaps, but not prehistoric.
That merely adds to my confusion though; a man who has programmed in so many languages -- and presumably for quiet a number of years as well -- who doesn't use folding and projects? I guess I just can't fathom such a thing. Heck, I'm only a hobby programmer and I couldn't live without those. Guess you really must type fast... :-)
Regards,
Jim
____________________________________________________________
GET FREE 5GB EMAIL - Check out spam free email with many cool features!
Visit http://www.inbox.com/email to find out more!
Why Tea
On Apr 22, 6:03 pm, knud van eeden <knud_van_ee...@yahoo.com> wrote:
> FYI, I have something like 20 text editors (vi, emacs, notepad++, UltraEdit, SlickEdit, e-texteditor, ..., almost all main text editors as seen on Wikipedia) and tried and still installed on my computer, and still use only one, TSE (the Swiss army knife).
Howard Kapustein
That merely adds to my confusion though; a man who has programmed in so many languages -- and presumably for quiet a number of years as well -- who doesn't use folding and projects?
knud van eeden
From: Howard Kapustein
> I've been recently doing some Ruby on Rails work and spent a little time burning thru various Ruby-aware editors. RadRails (i.e. Eclipse), SteelSapphire (i.e. Visual Studio), NetBeans, and a few Ruby-specific editors. None of the IDEs were really all that compelling, over a good editor and command line. Maybe someday, when type inference gets smarter and IDEs provide a real Intellisense experience for dynamic languages, but that day's not today.
I might have again a look at TSE in combination with Ruby on Rails
http://www.knudvaneeden.com/tinyurl.php?urlKey=url000012
(but stopped at time after discovering that
creating web pages from foreign key tables was would I thought at the time rather involved in Ruby on Rails v1.x)
as cloud computing (makes it e.g. scaling your (web) application easy) is getting more and more mainstream.
After reading this article here about Heroku
http://tech.yahoo.com/news/infoworld/20090424/tc_infoworld/72885
You can host your (starting) Ruby on Rails applications there for free (Blossom account).
See also for cloud computing:
Engine Yard http://engineyard.com (Ruby on Rails)
Google App Engine http://code.google.com/appengine/ (Python, Java, JavaScript, HTML)
Heroku http://www.heroku.com (Ruby on Rails)
Morph Exchange http://www.morphexchange.com (Ruby on Rails)
knud van eeden
From: S.E. Mitchell <sammy.m...@gmail.com>
To: sem...@googlegroups.com
Sent: Tuesday, April 21, 2009 4:24:07 AM
Subject: [TSE] Re: Desired text editing features
On Mon, Apr 20, 2009 at 1:46 PM, Howard Kapustein
<howard.k...@gmail.com> wrote:
> A transpiler would work too, but that means writing your own TSE parser.
> Hmmm. Sammy, does SAL have a well defined grammar? You wouldn't happen to
> have an ABNF spec laying around would you? Or something like it?
Last one we did - looks best with a fixed width font:
0
LAST REVISION: 18-APR-1991
1. FEATURE: TF-19 Macro Syntax Diagrams
2. PURPOSE: Documents the high-level syntax of QEdit 3.0's
Howard Kapustein
What font is that?
I tried cut/paste into TSE but no matter the font all I get are ? for the line drawing
(though I think the sizing and alignments right, with a monospace font)
Perhaps email the doc as an attachment, instead of cut/paste inline?
If this was generated from something, do you have the original source? That would be handy too.
- Howard
S.E. Mitchell
http://groups.google.com/group/semware/files
It is just a text file, created with whatever was the current version of QEdit.
You'll need to use the Terminal font (or something very close) to view it.
On Mon, Apr 27, 2009 at 8:22 PM, Howard Kapustein
S.E. Mitchell
<howard.k...@gmail.com> wrote:
> Ack! Sammy, how'd you create those diagrams?
> What font is that?
I forgot to add: Tim Farley created those. I suppose he used QEdit's
line drawing.
Since it was created in DOS, terminal font works good.
rd.ch...@gmail.com
the need for which I run into more and more regularly with Windows
text files/logs.
Otherwise, TSE has been an old friend for many years, and I can't
imagine a computing environment without it. Thanks Sammy!
knud van eeden
S.E. Mitchell
MacroDefinition ::= "MACRO" Ident String? DeclarationList
StatementList "ENDMACRO" Ident
Should probably something like:
[type] "proc" ident "(" parameters ")" DeclarationList
StatementList "endproc" [ident]
By the way, here is a simplified EBNF that I did a while back -
this only covers a subset of the language:
program = {"proc" procedure | funcOrVar}.
funcOrVar = type ("proc" function | restVarDcl).
type = "integer" | "string".
function = procedure.
procedure = ident "(" [formalArgs] ")" varDcl stmtSeq "endproc" [ident].
formalArgs = [var] type ident {, [var] type ident}.
varDcl = {type restVarDcl}.
restVarDcl = ident [= constExpr] {, ident [= constExpr]}
stmtSeq = {ifStmt|whileStmt|readstmt|writestmt|writelnstmt|assignOrCall}.
assignOrCall = ident ("=" expr | "(" [actParm] ")").
actParm = expr {, expr}.
ifStmt = "if" expr "then" stmtSeq {"elseif" expr "then"
stmtSeq} [else stmtSeq] "endif"
whileStmt = "while" expr "do" stmtSeq "endwhile"
knud van eeden
> From: S.E. Mitchel