Templot Club Archive 2007-2020

topic: 3564

Code Formatting

author

remove search highlighting

posted: 1 Dec 2019 07:22

from:

Graeme

Bangkok - Thailand

click the date to link to this post
click member name to view archived images

In the November Coding Clips:

Martin Wynne wrote:

Hmm. That's worrying, because for me it is an order of magnitude the other way.

Well, perhaps worrying, but not all that surprising (though I confess this is the first time I have seen this particular viewpoint!)

I've been trying to work out why that might be. I think it's that if I see:

abc:=123;

I see only 2 things, an object and its value, like an adjective describing a noun: hot water. The := operator is read as punctuation. All my brain needs to do is associate the object with its current value.

Whereas if I see:

abc := 123;

I see 3 things, the := operator becomes a word in its own right, not merely punctuation, and the line demands to be read as a full sentence: the water is hot. Which not only takes much longer, but seems to involve an entirely different brain function. Also nowadays with failing memory, by the time I've reached hot I've forgotten that it's water we are talking about and I need to read it all again. 2 things I can remember, 3 is asking a bit much.

hahaha - Well, an ingenious explanation, I have to say.

However - there ARE three things on the line. The ':=' is NOT just punctuation. In fact it is arguably the most important of the three because it is the one that defines what kind of statement we have here. It is an assignment.

Although you said "the variable and its value" there are in fact two values involved in this part of the code. The value of abc before the statement executes and the value after, and it is the ':=' which causes the replacement of one value with another. As you said it is the operator. Very different from the ; at the end of a line, for example, which I would agree is 'punctuation'.

With the three components closed together, I have to look closely at the line to see that it is an assignment and not a numerical expression (abc-123) or a procedure call (abc_123).

Your point about syntax highlighting is a very good one, and it does make the operator stand out in the editor ... but not in here

... and not if I print out the code so I can scribble on it

(does anyone really do that any more?)

And the example of the sentence with no spaces was intended only to demonstrate that spaces do help to highlight structure.

ANYWAY ... I promised I would not talk about specific formatting points. I am so clearly right about this that I don't see how anyone could possibly disagree! Which is great ... EXCEPT ... you DO disagree, and are just as totally convinced by your way of doing things. hahahaha

And therein lies the real problem. We can't BOTH be right. But actually I think we are!

Over the years I have been involved in literally scores of such discussions on formatting for over a dozen languages, and the conclusion I have come to is that there IS no logical justification for these views. It is fundamentally a matter of taste, normally re-inforced by familiarity, and all the "logical" arguments put forward are actually no such thing. They are post-justification for a previously determined view. My own cast-iron, how-could-you-possibly-dispute-it justifications included! This is why I call them 'religious' arguments. I know that NONE of the words I have written above, nor any of the thousands more I could write will change your feelings.

The whole discussion is akin to you telling me that your favourite colour is green and me trying to convince you that you are wrong and blue is much better.

But there is one thing that I can guarantee you. Absolutely 100%, cast-iron, totally, cross-my-heart guarantee. And that is this ... when we get a third contributor he will have a completely different view from either of us! hahaha

And so to the point of all this ...

You may have heard of the Go programming language, which was created by Google. In the Go community nobody ever talks about formatting. Not ever. It is a completely non-existent topic. The reason for this is that the compiler team also produced a code formatter which sits with the compiler and other tools and which everyone uses. It appears to be unthinkable to Go developers not to format their code using it.

Now, it is almost something of a joke in that community that nobody likes what it does - at least not completely. There are some good bits and some bad bits, but of course nobody agrees on what the good and bad bits actually are! But what they all DO agree on is that standardisation is the most important thing, and so it is at once universally disliked and universally accepted.

As you probably know, Lazarus provides easy (integrated) access to a code formatter called Jedi. I have glanced at the output and it looks acceptable, but even with a quick glance I saw a couple of things I would not do myself. I could not say I particularly like what it does. And I am pretty sure you will not like it either. But that is not the point. It provides consistency, and in a multi-contributor environment that is more valuable than anything else.

The main points are:

it is trivial to access
it is automatic
the output is reasonable (or at least not UNreasonable)
we WILL get used to it, and - perhaps most importantly,
it is far easier to say to any newcomers "Use this" than try to describe the scores of as-yet-undocumented conventions in the existing code - and perhaps even MORE most importantly ...
these discussions no longer waste our time.

I suggest that we adopt it, however painful it may feel in the short term.

Cheers,

graeme

PS
Clearly that was only an example. I hope it is obvious to all that blue IS better than green.

posted: 1 Dec 2019 22:39

from:

Martin Wynne

West Of The Severn - United Kingdom

click the date to link to this post
click member name to view archived images

Hi Graeme,

I'm not convinced that my argument is simply post-justification of a mere personal preference.

However, I'm not going to continue this discussion because I suspect it is counter-productive. We need to encourage more folks to join in the coding fun for both TemplotMEC and Templot3, not put them off.

I have written a utility exe which will strip out the spaces from .pas files while I work on them, and put them back before I post them. This should keep everyone happy, and also allows all the old existing files to be similarly updated.

If anyone else shares my brain functioning and finds wide-spaced operators difficult to read, I will happily make the utility available to them.

I think you over estimate my knowledge of the IT world. I had no knowledge of Jedi, and I know GO only as a fiendish board game.

If you think either of these can help us, by all means go ahead with whatever is needed.

cheers,

Martin.

posted: 2 Dec 2019 06:58

from:

Graeme

Bangkok - Thailand

click the date to link to this post
click member name to view archived images

Martin Wynne wrote:

However, I'm not going to continue this discussion because I suspect it is counter-productive.

Yes indeed! And here we are in complete agreement. The one universal truth about formatting discussions is that they are a waste of time.

I have written a utility exe which will strip out the spaces from .pas files while I work on them, and put them back before I post them.

Perfect. And this is exactly how I believe we should work:

there is a 'standard' format and we all have a shared utility which can reformat the code for us that way
those of us who do not like to work in the standard form each has a small utility which re-formats the code in the way we want to see it
before changes are published, code is re-formatted back to 'standard'

I think you over estimate my knowledge of the IT world. I had no knowledge of Jedi, and I know GO only as a fiendish board game.

Hahahaha - no knowledge needed really, over and above what I said. Go is a programming language. The important thing is that their community has a standard format defined, as described above.

Jedi is (or should be) already there as part of your Lazarus installation, accessed under Source>JEDI Code Format> ... menu item. My suggestion is that since that is available to everyone, built into Lazarus (and therefore, I suppose, arguably some kind of standard) that we adopt that as our 'standard' form for Templot.

That should also suppress many of the spurious diffs which result from pure format shuffling.

Cheers,

Graeme

posted: 2 Dec 2019 09:42

from:

Martin Wynne

West Of The Severn - United Kingdom

click the date to link to this post
click member name to view archived images

Graeme wrote:

Jedi is (or should be) already there as part of your Lazarus installation, accessed under Source>JEDI Code Format> ... menu item. My suggestion is that since that is available to everyone, built into Lazarus (and therefore, I suppose, arguably some kind of standard) that we adopt that as our 'standard' form for Templot.

Hi Graeme,

Ah yes -- I now remember looking at that menu when I first started using Lazarus.

Under About it says:

Version 2.44
August 2009

This program attempts to standardise and make readable the layout of any Delphi Object-Pascal source code.

Copyright Anthony Steele 1999-2008

This program is still under development. In spite of thorough testing and removal of reported bugs, no guarantees are given. Please make backups, or better yet use a source control system.

My red. From which I assumed that its purpose was to convert code written in Lazarus for use in Delphi. Also that it was 10 years old and likely to be out-of-date for modern versions of Lazarus.

Also "make readable" is a joke for me, because having now tried it on a couple of files it does the exact opposite.

Look at this for example

then
begin
    if p2.x = def_req then
      p2.X := rings[ring_list_index, 0];
    if p2.y = def_req then
      p2.y := rings[ring_list_index, 1];
end
else
begin
    if p2.x = def_req then
      p2.X := screenx / 2;   // arbitrary..
    if p2.y = def_req then
      p2.y := screeny / 2;
end;

Unnecessary line-wrapping, thens and elses all mixed up, no idea which else goes with which then, and assignment operators lined up with conditional operators to cause maximum chances of misreading.

Compare with my original:

     then begin
            if p2.x=def_req then p2.X:=rings[ring_list_index,0];
            if p2.y=def_req then p2.y:=rings[ring_list_index,1];
          end
     else begin
            if p2.x=def_req then p2.X:=screenx/2;   // arbitrary..
            if p2.y=def_req then p2.y:=screeny/2;
          end;

However, if you think we should use JEDI before posting files I'm happy to go along with that. Anything to keep folks quiet.

In passing I discover that it makes 50% of the utility I wrote yesterday unnecessary. On the other hand I can develop the first half to deal with more than just the spaced operators -- getting thens and elses lined up with clear space under them being a primary requirement to "make readable" for me!

cheers,

Martin.

posted: 2 Dec 2019 15:59

from:

Graeme

Bangkok - Thailand

click the date to link to this post
click member name to view archived images

Martin Wynne wrote:

From which I assumed that its purpose was to convert code written in Lazarus for use in Delphi. Also that it was 10 years old and likely to be out-of-date for modern versions of Lazarus.

Also "make readable" is a joke for me, because having now tried it on a couple of files it does the exact opposite.

Look at this for example

then
begin
    if p2.x = def_req then
      p2.X := rings[ring_list_index, 0];
    if p2.y = def_req then
      p2.y := rings[ring_list_index, 1];
end
else
begin
    if p2.x = def_req then
      p2.X := screenx / 2;   // arbitrary..
    if p2.y = def_req then
      p2.y := screeny / 2;
end;

Unnecessary line-wrapping, thens and elses all mixed up, no idea which else goes with which then, and assignment operators lined up with conditional operators to cause maximum chances of misreading.

Compare with my original:

     then begin
            if p2.x=def_req then p2.X:=rings[ring_list_index,0];
            if p2.y=def_req then p2.y:=rings[ring_list_index,1];
          end
     else begin
            if p2.x=def_req then p2.X:=screenx/2;   // arbitrary..
            if p2.y=def_req then p2.y:=screeny/2;
          end;

However, if you think we should use JEDI before posting files I'm happy to go along with that. Anything to keep folks quiet.

In passing I discover that it makes 50% of the utility I wrote yesterday unnecessary. On the other hand I can develop the first half to deal with more than just the spaced operators -- getting thens and elses lined up with clear space under them being a primary requirement to "make readable" for me!

Hi Martin,

I think originally it was actually written for (and probably by) Delphi programmers to reformat their code. Well that was how i read it anyway. I thought it had just been grabbed by Lazarus project and re-purposed. I guess if the (pascal) language spec has not changed in a while there is no great need for the formatter to change, but let me look into it a bit more.

But oh my gosh that code. :shock:

I know I said it does not matter if we like it or not, but that is just UGLY! I would be embarrassed to use that as our standard.

I still like the idea of a standard version, with a tool to support it, but this is not what I was hoping for.

I suggest do nothing for now and let me look around a bit and see what I can discover.

Cheers,

graeme

Last edited on 2 Dec 2019 16:00 by Graeme

posted: 3 Dec 2019 07:50

from:

Graeme

Bangkok - Thailand

click the date to link to this post
click member name to view archived images

Hi Martin,

Well I have managed to tweak the output from Jedi a bit to produce something I think is ... well not unreasonable, anyway. At least it has got rid of many of the single word lines that looked so ugly (and illogical) to my eyes.

On the basis that you have spaces under control I concentrated on the newlines and alignment.

The 'end's do not line up with 'begin's the way you do it - I am not sure we will get a reformatter which does that - but at least they line up with what seems to me to be the 'owner' of the block (i.e. the 'if', 'else', 'case', or whatever). This is anyway how it would work in most other languages. (Yes, I know we are not using other languages

, but it will at least have a familiar feel for most newcomers.)

Anyway, the procedure I wrote for showing switch info comes out looking like this ...

//______________________________________________________________________________________

procedure Tswitch_select_form.show_info_buttonClick(Sender: TObject);
begin
if check_valid_switch_selected = False then
    EXIT; // no switch or no data for it.

if switch_info_showing = True then begin
    show_info_button.Caption := 'show switch info';
    resize_small();
    switch_info_showing := False;
end
else begin
    show_switch_info(full_size_mm_radiobutton.Checked, switch_info_showing);
    show_info_button.Caption := 'hide switch info';
    resize_big();
    switch_info_showing := True;
end;

if switch_selector_listbox.Visible then
    switch_selector_listbox.SetFocus;
end;

Not perfect by any means (certainly not your 'Bingo!' moment) but I could live with it.

If you want to try on a bigger sample, copy the attached file (with change of extension!) into your equivalent of C:\Documents and Settings\graeme\Local Settings\Application Data\lazarus\jcfsettings.cfg

The example you gave is always going to be a hard one because a human eye will always be able to pick out cases where fortuitous similarity of lines of code make it worth breaking the rules. In that example, the 'if' statements looked so much better continued on one line.

Under these settings, that example looks like this:

begin
if True then begin
    if p2.x = def_req then
      p2.X := rings[ring_list_index, 0];
    if p2.y = def_req then
      p2.y := rings[ring_list_index, 1];
end
else begin
    if p2.x = def_req then
      p2.X := screenx / 2;   // arbitrary..
    if p2.y = def_req then
      p2.y := screeny / 2;
end;

end.

Again, not perfect, but reasonable, I think. Certainly a hell of a lot better than the default settings

What do you think? Is this getting to acceptable yet?

Cheers,

Graeme

Attachment: attach_2948_3564_jcfsettings.txt 4

Last edited on 3 Dec 2019 08:39 by Graeme

posted: 3 Dec 2019 12:49

from:

Martin Wynne

West Of The Severn - United Kingdom

click the date to link to this post
click member name to view archived images

Hi Graeme,

Many thanks for doing that.

Yes I can live with that. I might even get to like it in time.

I think it is important to see what it looks like with syntax highlighting, because in practice that how it is almost always viewed:

2_030735_420000000.png

I confess it is unnerving to see an else and not be able to glance vertically above it to find the then. For one thing you don't know how far back to look, a few lines or several pages?

One change I would prefer if it's possible, would be a blank line below "procedure..."/"function..."?

You probably noticed that I already sometimes put ends below a block rather than strictly below the begin. But in that case I often comment the end; to indicate what it is the end of. For example

with bananas do begin
if ripe=True then eat_now
               else keep;
end;//with

or

for n:=0 to eggs_list.Count-1 do begin
if eggs_list[n]=''
     then CONTINUE
     else begin
            with eggs_list[n] do begin
              fry_it;
              eat_it;
            end;//with
          end;
end;//next

Can Jedi actually modify the code by adding such comments to end;s?

cheers,

Martin.

posted: 3 Dec 2019 21:26

from:

Martin Wynne

West Of The Severn - United Kingdom

click the date to link to this post
click member name to view archived images

Hi Graeme,

I found the Jedi "Clarify" (!) settings thanks, and had a play with the indenting and line feeds.

I got your code looking more to my liking with plenty of white space below if and above else so I can glance up and down between them without any eyeball obstructions. Likewise between begin and end:

2_031603_070000000.png

However, when I tried the same settings on some of the other units it produced excessive amounts of white space indenting:

2_031612_350000000.png

So I'm in two minds about the whole thing.

I think I will write my stuff in my own way, and leave you (and others?) to set up this Jedi stuff any way you wish, and I will happily apply it to my code before posting it.

It's all getting a bit much to think about on top of Templot2 and Templot3 and supporting users -- there's a request on RMweb tonight for help with setting Templot timber spacings for Swiss railways. Plus another release needed for Templot2 after a bug fix this afternoon. Feeling a bit weary today.

cheers,

Martin.

posted: 4 Dec 2019 02:16

from:

Graeme

Bangkok - Thailand

click the date to link to this post
click member name to view archived images

Martin Wynne wrote:

Yes I can live with that. I might even get to like it in time.

I say! Steady on, old chap! hahaha

I confess it is unnerving to see an else and not be able to glance vertically above it to find the then. For one thing you don't know how far back to look, a few lines or several pages?

Yes, you are now looking back for the corresponding if, rather than the then - but it's just something you get used to. It should be easy to spot, though, as it should be just the previous thing at the same indentation level.

Some editors actually provide faint vertical lines on the left showing each level of indentation, which makes it a doddle, but Lazarus is not one of them

Perhaps using 3 or 4 spaces for indentation would make it more obvious? (I generally use 4 but I noticed that you had used 2 quite a lot, so I left Lazarus set at 2.)

One change I would prefer if it's possible, would be a blank line below "procedure..."/"function..."?

There is an option to insert above these headers, but not below.

I DID find a setting which removes blank lines above, so we could turn that off.

What I would like to see is a way of inserting the comment line of underscores that you have before each procedure, which is another thing I normally do, and I find it helps enormously. Again, no dice in Jedi.

You probably noticed that I already sometimes put ends below a block rather than strictly below the begin. But in that case I often comment the end; to indicate what it is the end of. For example

with bananas do begin
if ripe=True then eat_now
else keep;
end;//with

Can Jedi actually modify the code by adding such comments to end;s?

This is actually the kind of end indentation with which I am most familiar (as you probably gathered

).

I have also used this kind of commenting in the past with languages which use end to terminate just about everything. Sadly, Jedi will not insert such comments for us.

But again, the beauty of this kind of indentation is that the opening keyword is just the previous thing at the same level.

Cheers,

graeme

posted: 4 Dec 2019 02:55

from:

Graeme

Bangkok - Thailand

click the date to link to this post
click member name to view archived images

Martin Wynne wrote:

So I'm in two minds about the whole thing.

I think I liked "... I might even get used to it" better.

I think I will write my stuff in my own way, and leave you (and others?) to set up this Jedi stuff any way you wish, and I will happily apply it to my code before posting it.

Well, you need to be comfortable with your work flow, so if that's the best way...

Jedi could perhaps help you in this regard. If we have one 'standard' set of settings that we use for publication and a private set that adjusts to our individual preferences. Just a thought.

I have make the tweaks I mentioned earlier and attached a new version of the config file below that we can use as the 'standard'.

As you will see, I suggest that we call that file 'templot-jcfsettings.cfg' so we are not overwriting the delivered settings, and then we can each have a 'graeme.cfg', 'martin.cfg', or whatever.

Also, we should check templot-jcfsettings.cfg into the source tree somewhere so that it is under version control, and anybody who gets the Templot source also gets a copy of the file.

It may be a good idea to try to finish any work you have in progress before applying a global reformat, and post the reformatting as a change in it's own right. Any other changes in the same release will be buried in the diff tsunami!

I don't have much that I need to keep, so I will manually copy my diffs over once you release the reformatted version.

It's all getting a bit much to think about on top of Templot2 and Templot3 and supporting users -- there's a request on RMweb tonight for help with setting Templot timber spacings for Swiss railways. Plus another release needed for Templot2 after a bug fix this afternoon. Feeling a bit weary today.

Yes, it is a lot on top of your 'day job'.

I wish I could do more to help.

Cheers,

graeme

Attachment: attach_2950_3564_templot-jcfsettings.txt 0

posted: 4 Dec 2019 05:07

from:

Martin Wynne

West Of The Severn - United Kingdom

click the date to link to this post
click member name to view archived images

Hi Graeme,

Thanks.

I've rather lost track of how we got into this. We do have the existing units, is it essential that they be changed? Anyone writing new stuff can clearly use any style they prefer, the only really significant point being that it compiles without errors and works.

Changing the subject, did we follow up on my previous comments?

What I'm finding very difficult to fathom is how to merge the units together? While you have been making changes to these units, I have also been making changes to some of them. Which means we now have 3 versions of each file:

1. as currently on SourceForge
2. as modified by you
3. as modified by me

Which of us does the merging and conflict resolution? What happens if while one or other of us is doing that, the other makes some further changes -- which may or may not be compatible with the results of the merging?

WinMerge allows 3-way diffing, so I have just opened the above 3 versions of keep_select.pas, and there are so many differences that I hardly know where to begin. What seems obvious is that doing this every time any one of a group of programmers changes something in one file, with consequent changes needed in some other file, it is going to take 10 times longer than making the actual change in the first place. How do other groups manage this?

We don't currently have an updated set of files on SourceForge with some of the recent changes, however formatted. Anyone coming fresh to this hasn't currently got a starting point, which makes it difficult to encourage others to join in.

cheers,

Martin.

posted: 4 Dec 2019 05:43

from:

Martin Wynne

West Of The Severn - United Kingdom

click the date to link to this post
click member name to view archived images

p.s. Graeme,

Is there a mechanism in the editor to do something like this:

In base_unit.pas:

end;
//________________________________________________

INSERT FILE graeme_stuff_29.txt

//________________________________________________

INSERT FILE martin_stuff_17.txt

//________________________________________________

procedure more_base_code(.....

If each contributor's stuff is contained in separate files, it would be much easier to do the updating and merging. They can't be full .pas files linked in the usual way by the compiler, this merging would take place in the editor before the compiler runs.

Is this the sort of thing a Preprocessor function does? Or is there a compiler directive to do this? In some other compiling software I use for HTML I would write:

#MERGE my_other_file.txt

to do that.

You have probably realised by now that you are not dealing with a fellow IT professional, but with someone who has ploughed his own furrow for decades.

cheers,

Martin.

posted: 4 Dec 2019 09:09

from:

Graeme

Bangkok - Thailand

click the date to link to this post
click member name to view archived images

Martin Wynne wrote:

I've rather lost track of how we got into this.

Hi Martin,

Originally this started from a discussion on formatting, and my observation that

expecting people to manually format code consistently to any particular standard is somewhat optimistic, to say the least. (As an indication, I have never seen it happen, except on projects which dedicated an inordinate amount of programmer time to code reviews.)
discussions on code formatting are huge time-wasters (as we have seen already ) and tend to be religious in nature, in so far as each person has their own view and can support it with lots of supposedly 'logical' reasons and yet each person's logic contradicts someone else's
the community around the GO language avoided both problems by having a tool to format code in a certain way and everyone just uses it (even though it produces nobody's favourite format)
a similar tool (Jedi) is integrated into Lazarus, and so is just a click in the workflow

The other point being that it is far easier to say to a newcomer "run the formatter" rather than try to teach them a specific set of formatting rules. Without a tool to apply standard formatting, we will get a lot of spurious diffs generated by people shuffling code to their preferred format.

We do have the existing units, is it essential that they be changed?

I would hesitate to say 'essential' to change the existing code base, in so far as the code runs fine without it. However, I would describe it as 'highly desirable' for the reasons mentioned above. A common format throughout the code base just makes life easier.

On a purely practical note, at some stage one of us is bound to accidentally reformat an old module. It will be hard to go back, and any changes made will then be buried in the reformatting changes. if it is to be done at all, it will be much better just to do it all in one hit.

Anyone writing new stuff can clearly use any style they prefer, the only really significant point being that it compiles without errors and works.

Apart from 'working' from a user's perspective, the code needs to 'work' from a programmer's point of view, which involves being:
- easy to read and understand
- easy to modify and extend
- easy to test
etc. etc. all of which tend to be invisible to normal users, but important nevertheless, and most of these things are rooted in code which has consistent styling.

Working on a code base which follows half a dozen different styles would be a nightmare. (or I should say IS a nightmare! I know. I have done it. :shock:

)

Cheers,

g

PS
I still think I preferred "... I might even get used to it"

posted: 4 Dec 2019 09:14

from:

Graeme

Bangkok - Thailand

click the date to link to this post
click member name to view archived images

Martin Wynne wrote:

Changing the subject, did we follow up on my previous comments?

What I'm finding very difficult to fathom is how to merge the units together? While you have been making changes to these units, I have also been making changes to some of them. Which means we now have 3 versions of each file:

1. as currently on SourceForge
2. as modified by you
3. as modified by me
.......

We don't currently have an updated set of files on SourceForge with some of the recent changes, however formatted. Anyone coming fresh to this hasn't currently got a starting point, which makes it difficult to encourage others to join in.

Hi Martin,
No, not yet. I was expecting to get the formatting issue cleared away before going on to this. That has taken longer than I expected.

I will try to get something out this evening.

Cheers,

graeme

posted: 4 Dec 2019 10:17

from:

Graeme

Bangkok - Thailand

click the date to link to this post
click member name to view archived images

Martin Wynne wrote:

Is there a mechanism in the editor to do something like this:

//________________________________________________

INSERT FILE graeme_stuff_29.txt

......

You have probably realised by now that you are not dealing with a fellow IT professional, but with someone who has ploughed his own furrow for decades.

Fair enough!

There is almost certainly some sort of include mechanism in the compiler (few languages DON'T have one) but it would not be practical to use it for this purpose. For large changes it might work, but as changes get smaller it would be unworkable, I would think, and over time generate more problems than it solves.

Cheers,

graeme

Please read this important note about copyright: Unless stated otherwise, all the files submitted to this web site are copyright and the property of the respective contributor. You are welcome to use them for your own personal non-commercial purposes, and in your messages on this web site. If you want to publish any of this material elsewhere or use it commercially, you must first obtain the owner's permission to do so.

	Templot Companion - User Guide - A-Z Index	Templot Explained for beginners	Please click: important information for new members and first-time visitors.
indexing link for search engines

Templot Club Archive 2007-2020 < back - search archive browse archive images

Templot Club Archive 2007-2020