| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 553.1 | Used to work ... | WRONGO::PARMENTER | Venusian or Venerean? | Wed Jun 24 1987 17:58 | 4 |
| Hmmmm. That used to do just what you wanted. Julie will have to
tell you about the modern state of LSE.
David
|
| 553.2 | Probable explanation | BUNSUP::LITTLE | Todd Little NJCD SWS 323-4475 | Wed Jun 24 1987 19:33 | 20 |
| The problem stems from the way the tokens and placeholders have
been defined. In general, the tags are all defined as tokens, which
LSEDIT will automatically create menus for if the portion of the
token entered is ambiguous. There are a small subset of tags though
that have their tokens defined as "<tag>" instead of "tag", i.e. the
<SET_TEMPLATE...> tags. If instead, they were defined as
SET_TEMPLATE..., then the anomoly would disappear.
The real issue I think at hand is if all the tokens should be defined
with the <> as part of the token name. The disadvantage is that
you'd HAVE to type <t^E to get all tags that began with T as opposed
to right now, you can get that essentially with t^E. The advantage
of the former is that you're clearly asking for a tag expansion,
whereas in the latter, you might be fishing for something other
than a tag, such as a template or some other thing(?).
-tl
PS I too thought the results observed in .0 were a little un-nerving.
|
| 553.3 | Use SHOW TOKEN * | TOKLAS::FELDMAN | PDS, our next success | Thu Jun 25 1987 14:52 | 12 |
| The "most appropriate" way to do what was wanted in note .0 is to
issue the LSE command SHOW TOKEN */LANGUAGE=SDML. This will put
you into the $SHOW buffer, and list all available tokens. The way
the SDML tokens are set up, there should be an approximate one-to-one
relation between tokens and tags. I say approximate, because not
every SDML tag has a defined LSE token, and a number of tokens (such
as LIST) actually expand to several tags.
Ultimately, I expect the on-line help for DOCUMENT to have a complete
listing of tags; such help should be available from LSE.
Gary
|
| 553.4 | Space, <QUOTE> and LSE. A problem? | CASEE::THOMSON | Richard Thomson | Mon Aug 17 1987 10:45 | 30 |
| This seemed the most appropriate place to post this query. Usual
apologies if my search did not reveal a better spot...
When I first started to use DOCUMENT, I obtained snazzy little double
quote marks by pressing the " key (shift comma). It looked good on
the screen, and it looked good on my .ln03 output. Then I learned
that this was not good behaviour, and that I should use the <QUOTE>
tag(s). Ugh! Now my .ln03 output looks as if I don't have the double
quote character (it prints ''). C'est la bleedin' vie, as they say.
Such is progress.
Then I discovered LSE!! Wonderful. I take back all (well most of
them anyway) the nasty remarks I made about DOCUMENT being difficult
to input with its upper and lower case bits and bobs etc. But...
when LSE expands for the quote tags, and leaves the space for the
text-I-want-in-quotes, it puts the <QUOTE> on one line, the text
string on the next, and the <ENDQUOTE> on the third. The result
is that DOCUMENT implies space around the word, unless I manually
bring the tags together onto one line. So I've gone from:
this is a "nice" example -> to a not '' nice '' at all example.
Since I cannot imagine a circumstance when you would want this space,
I am hard put to understand why DOCUMENT or LSE contrive to put
it there. Any ideas why this is happening/what I'm doing wrong/why
I'm expecting too much?
BTW: why can't I have double quotes when I ordered them? Just curious...
Richard
|