> I currently use Alt+Edit and Alt+View to solve this problem, but
> wouldn't
> including a 'REM #ZTview' line in many scripts be a lot of work?
I don't have lots of referance items, but I use them often

> It's also
> polluting pure text (like your tables), if you export them, for example.
> It appears it will create a lot of maintenance work, IMO. Why not
> implement what you want outside the item body?
Agree, but a single line with ":: #ZTView" is no harder than any other method.

> Some time ago I've sent to Kim a long list of F9 ZEPs, including
> extending what is *already* there just a little bit and obtaining
> some interesting benefits. It's no-ZEP time, so I'll just mention
> something related to your request:
The reason I ZEP'ed is that the Alt-X and it's #ZTStart, and #ZTExit have been added in the no ZEP time, and I consider the requested #ZTView as being a similar feature.

> Currently, as in FW/DW, F9 knows how to jump to items starting with a
> letter/number, and that's it. Note that you cannot access items like

> #How to setup Distiller
> #Adding servers to hosts file
> !TODO fssdfsdfsdfsf
> !WORK asfsdfsfsf asfsf fsfdf
> @Export this ZDB now (Ctrl+Enter)

> directly, but in DW/FW you can jump to such dirs/files! In F9 you need
> to look for them and navigate, and with macros it's not easy to reach
> all such items reliably.
Yes having spell search in F9 would be usefull, and for macro use a treespec equivilent would make navigating more reliable.

> Phase 1
> =======

> I suggested adding support for jumping to ALL printable characters, ie,
> all those accepted when naming F9 items. Maybe even graphics box-drawing
> ones.
> This set of characters largely surpasses that of legal file names and is
> probably very easy to implement in code by relaxing range-checking. It has
> absolutely no impact on anything outside F9 and would not take more than
> a coffee break for Kim to implement, IMO :-)

> Once this becomes available, I see huge possibilities for adding simple
> KEYs
> to DATABASE items:

> [one-char-key] Item name goes here...

> Of course, every item that has any name (even starting with a space)
> already
> has a KEY, by definition, and today the valid keys are 0-9 and A-Z (only).

> I use !, #, and a few others to tag items that are not executable, for
> example.
> I use Alt+Edit and Alt+View on them. Still, I sometimes hit Enter as well.
> It would be nice if ZTree prevented this (or behaved differently) in these
> cases!

> It's up to you to use [ ] { } = + ^ and all the others as you like, but
> there should be right away some reserved ones that we should argree upon,
> IMO.
> We could all play with this for a few months in order to come up with
> reasonable conventions for 'keying' (or 'tagging') items into different
> classes. Obviously, we have two broad classes of items today to start
> with:
> executable and non-executable, but this open-ended...

> Does anybody use the first character of the item name for anything
> special?
> If not, Ben and Laurent, start now :-)

I don't like the idea of having to name the items in a particular way, at least not when is has to be the first character, I could live with the last character though, but I would prefer that the item type was stored in a place that is accessable from the edit menu. The item type could be displayed in the tree, but the "key" character would not be used for navigating.

> Phase 2
> =======

> This takes more time and effort and can wait while we play with item KEYs
> as they are today. Hopefully, the 0-9A-Z barrier will be broken soon :-)

> What I'm proposing is having ZTree treat that first character in a special
> way, the way scripts treat # ; ! :: REM, and so on. (Of course, one should
> still be able to use it as a navigation shortcut!)

> So, in your case, you could just name your tables:

> # ASCII 0-127
> # ASCII 128-256

> and hitting Enter would do the ACTION ASSOCIATED WITH THE '#' KEY,
> whatever it is (TYPE it, View it, Do nothing, Mail it, Print it, etc.)
The mappings could be stored in the menu file header.

> A very fast and easy implementation, as proof of concept, would be, say,
> for '#' to be equivalent to the current Alt+V: after the user hits
> Enter (or its variants) *and* the item starts with '#', ZTree would
> interpret it as Alt+V -- but, no @ECHO OFF would be added and no parsing
> performed. This is what Ben wants, I believe.
Yes an un-pre-processed view would be ideal for my referance items.

> Note that by simply prefixing an executable item (buggy, destrucive)
> with '#' you may also be protecting yourself from trouble...

> We could start with the '#' KEY as the most obvious. Once the habit
> is there, new usages will be found for this simple yet powerful
> mechanism.

> Usage example
> =============

> Actually, I've been using for several years KEYs in F9 in some macros
> as proof of concept:

> http://vujnovic.free.fr/ztw/ztw_macros.html#Macro_9 Simply, I use '9' as
> a KEY to jump to items starting with '9'. I know
> where these items are and control how many of them there are. One just
> needs to be careful not to add too many of them and/or to move them
> around, because these KEYs are accessed sequentially. And it works great!

> I also have a macro that jumps to the first 'S' item . I moved the item
> around and the macro found another 'S' item and was broken.

> With KEY=[0-9] the risks are smaller, but using obscure special characters
> for KEYs and a few conventions would eliminate then altogether.

> Summary
> =======

> Even as it is today, ZTree allows direct access to *any* item ('record')
> in
> the current ZTW_MENU.DAT file ('database') by first-character-stepping
> method
> ('record-key'). It works!

> Breaking the 0-9A-Z barrier would help navigation greatly.
Agree

> Treating certain KEYs (a better name may be needed...) in special ways
> would add very interesting possibilities.
Possibly TYPE, and different types could be displayed in different colours.

> There is much more to ZEP for in the database, outliner, program launcher
> that F9 is, but it can wait...
>
Agree, I have a list that I update when I think of things.

Ben