Re: Learning About Leo's Options

[HaveF HaveF]

A good addition to the documentation 
. 

I just review my custom settings, in addition to font-related 
configuration, I have

@bool log-pane-wraps = True
@bool show-tips = False
@bool highlight-body-line = True
@enabled-plugins

and some plugins settings etc.
It looks like I didn't configure much. Leo works great in default.

 
On Sunday, June 16, 2024 at 4:27:43 AM UTC+8 tbp1...@gmail.com wrote:

> From time to time Leo adds new options, but it's hard to know that this 
> happened let alone know what they are.  Once in a while a setting might get 
> removed, too. And even a long-time user can forget that such-and-such an 
> option exists.
>
> Leo has a large number of settings and it can be overwhelming to try to 
> get a handle on them  But it is possible.  Here is a fairly easy way to 
> it.  Options for specific capabilities are boolean - they are either turned 
> on or turned off by default.  A boolean setting is specified in a settings 
> tree by a headline like @bool highlight-body-line = False.  Leo's default 
> settings are all in the outline *LeoSettings.leo*. To find options that 
> are not turned on by default, search that outline using the Nav tab, and 
> search for this string: 
>
> = False.
>
> This will show you a list of nodes whose headlines are for boolean 
> settings that are turned off by default.  Clicking on one will navigate you 
> to that node. Sometimes the node's body has some explanation.  If not, you 
> can search for that setting's name in Leo's code base, *LeoPyRef.leo.*
>
> You can also search for settings that are turned on by default by 
> searching for = True, but this is less helpful because you are already 
> used to Leo using those options.  As an example, in another thread a day or 
> two ago, the option for highlighting the current line came up.  The listing 
> for searching for *False* options has this as the third result:
>
> @bool highlight-body-line = False
>
> That's the setting for turning on highlighting of the current line in the 
> body.  You can turn on any of these options by copying that node into the 
> settings tree in your customization file *myLeoSettings.leo* and change 
> the *False* to *True.*
>
> There may be a few obsolete settings that didn't get removed, but there 
> don't seem to be many of them.
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/7707d8fb-6741-4727-bc66-96e7715b3c90n%40googlegroups.com.

Re: Hex File Snooper

[Thomas Passin]

However, the simple FORTH kernel (I think it was fig-FORTH but my memory is 
hazy) didn't use DOS calls at all, and only screen write and direct disk 
access BIOS calls (that was INT21, wasn't it?). I don't see how the PC or 
DOS design could have slowed it down by much compared with the CP/M Z-80 
version.
On Sunday, June 16, 2024 at 10:02:49 AM UTC-4 David Szent-Györgyi wrote:

> The original IBM PC was a quick-and-dirty design; performance was not a 
> goal. 
>
> FORTH is an opposite: Simplicity and flexibility are at the heart of its 
> design, with carefully considered access to assembly language where 
> required for performance or access to bare metal. The design requires 
> trading conventional convenience for that. More conventional schemes for 
> access to bare metal involve complex, fragile, non-portable and expensive 
> platform development tools. Given engineering talent able to use FORTH, 
> FORTH makes sense. The wide-open architecture of FORTH requires discipline, 
> documentation, and careful management to write code that not only runs but 
> can be read and maintained. 
>
> I haven't made a career of embedded systems work, but I have done a few 
> small projects of that sort, and I think that FORTH holds its own in the 
> right hands. 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/ab5182b8-9869-4319-b0fe-28b8688d2a19n%40googlegroups.com.

Re: Hex File Snooper

[David Szent-Györgyi]

>From Documentation for Atari CoinOp Forth and Swarthmore Extensions 

: 

HOW TO WRITE GOOD FORTH 
FORTH suffers from a combination of bad press arid bad programmers. It is 
actually easier to write good FORTH than good anything else, since it is 
flexible, imposes few restrictions, and extracts no penalty for short 
programs, (Short programs, incidentally, are where it's at - breaking 
things up into small, sensible, lucid pieces is a key to good programming).


*Why write good FORTH? *
Good code is faster to write, if you consider total time, since it comes 
from clear thinking and good organization, arid it is much easier to debug. 
You can understand and modify good code in amazingly shorter time* 

Finally, you're much more employable if you write good code* Should a 
prospective employee tell me that he or she prides him or herself in 
writing good, clear, maintainable, well-documented FORTH I would, after 
picking myself up off the floor, endeavor to hire the person or. the spot. 


*How to write good FORTH: *
You need to (1) know what good FORTH is, (2) discipline yourself to write 
it. Item (1) will be addresed[*sic*] next. For (2), I've observed that a 
few thoughtful rewritings of a reasonably sized piece of code will not only 
help a decent programmer understand what good code is, but will also 
establish the necessary habits so that writing passable code becomes almost 
automatic, and good code a distinct possibility. 


*What is good FORTH? *
Good FORTH consists of short, well thought out pieces. A word should rarely 
take up more than half a screen. If you use more than that, see whether you 
can break up the word into smaller, more coherent pieces* A good FORTH word 
is one which is easy to understand, and which you might be tempted to use 
again elsewhere.

Good FORTH is vertical, not horizontal. That is, there are few words per 
line and the lines are left-indented in an intelligent fashion. DOs and 
LOOPs, BEGINs and UNTILs, IFs, TH£Ns, and ELSEs, etc. are all left 
justified, with inner groupings to the right of outer ones. Take a look, at 
the Swarthmore source code to see what this means. 

Each line should contain no more than a single idea. 

A comment accompanying each word should show its effect on the stack, 
preferably with helpful mnemonic symbols for the stack, elements.

Words should be liberally sprinkled with comments. More lengthy comments 
can be put after the "-->" or ";S". The best code is almost 
self-documented. 

The first line of a screen should consist of a comment which describes the 
contents of the screen. You should rarely start with more than half a 
screen full of code. 

Will you go broke buying the number of disks necessary to write good FORTH? 
Hardly. Even in this expansive forn, FORTH gets you a lot of mileage. 
Moreover, few items connected with computers are as cheap as disk space. 
Finally, truth to tell, revisions and reworking usually result in screens 
filling up more than the minimal recommended (starting minimally gives you 
room for such expansion). 

FORTH is supposedly a "stack oriented" language, but the programmer should 
not be stack oriented. Juggling several elements or. the stack can cause a 
surprising number of errors. In almost all situations, it's much clearer 
and leads to many fewer errors if you introduce sensibly named variables. 
It is hard to find a situation when such a practice will measurably slow 
down a program. It is possible to juggle stack elements by sending them to 
and from the return stack (it's possible to do lots of wild things in 
FORTH), but it's usually just not worth it. 

If you simply must play with several items or. the stack, you're probably 
best off making up special stack manipulation words. If a word deals with 
several items on a stack, I've also found it very helpful to put in full 
comment lines within the word which show the stack, changes in clear 
mnemonics[*sic*],

Well-thought-out names can contribute immensely to good code. It's worth 
spending tine making up useful names (self-documenting code, again). One 
helpful approach is to try to name *what* the word does, not *how* it does 
it. Don't use an unidentified nunber in a word. Either identify it in a 
content or define a constant (with a good name) arid use it in the code.

Avoid abbreviations when you're writing code. The extra typing is trivial 
and the clarity introduced is considerable. It's fair and reasonable to 
introduce abbreviations in a testing/debugging session, however.

*Is our code good?*

It varies. It's getting better. At first we committed the negation of the 
above ideas. Look over our source code and see what you like and what is 
clear. There are probably 8 different prograMMers represented on the 
SwarthMore disks, so there are lots of different styles, ideas, arid 
approachs. 

Further 

Re: Hex File Snooper

[David Szent-Györgyi]

The original IBM PC was a quick-and-dirty design; performance was not a 
goal. 

FORTH is an opposite: Simplicity and flexibility are at the heart of its 
design, with carefully considered access to assembly language where 
required for performance or access to bare metal. The design requires 
trading conventional convenience for that. More conventional schemes for 
access to bare metal involve complex, fragile, non-portable and expensive 
platform development tools. Given engineering talent able to use FORTH, 
FORTH makes sense. The wide-open architecture of FORTH requires discipline, 
documentation, and careful management to write code that not only runs but 
can be read and maintained. 

I haven't made a career of embedded systems work, but I have done a few 
small projects of that sort, and I think that FORTH holds its own in the 
right hands. 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/45bc7b8a-db98-4143-8fc0-fc932272306en%40googlegroups.com.