Ok, first off I have to say TextPad is my editor of choice, so thanks for making a solid app. I think it has most of the features I can imagine needing, and my ideas are only for enhancing it's usefulness and the ability to help the user be more efficient.
The clip library structure, as it is, is a simple structure:
!TEXT= <title>
<Clip Contents>
! <- end of clip
My problem is that there's no depth to this system at all. Using different methods you could have nested clips which greatly increases it's usefulness. Basically creating a tree structure of clip 'sections' and clips. You can also use this to create a clean list of certain API calls or defined functions.
I think by using XML (or a similar tech), you can create a far more advanced system for clip libraries. Say for example I'm using TextPad for PHP work. PHP has a huge number of predefined functions. Putting all of those into the clip library is borderline insane because there's no structure or way to create groups of them (I know I can turn ordering off, but still, it's not a very nice way to have that many things stored).
Also, say I was working on a PHP/HTML project. I could define one clip library with two top level trees named "PHP" and "HTML" with my most commonly used clips from both libraries.. without them all being in one big mixed list.
I just think a lot can be done with this area of the application, and it doesn't just benefit someone like me using it for PHP work. Additional ideas are to have a 'Common Clips' section that shows the clips used the most. Sometimes you can make a huge library, but only use a few commonly. Also adding a search option for the clip library would increase it's efficiency greatly.
My second idea which I'll throw in here is about syntax processing. You already have syntax coloring, but why not extend that a little more? A structured list of functions, classes, variables, etc would only seem to be the next logical step. As it seems to me you could do this with literally any API or file structure that has syntax defined.
With syntax highlighting (if done correctly) you should be able to know exactly what things are and how to make a list of them. Also extending the defined syntax highlighting to include personally defined functions and classes. This is more complicated than the Clip Library idea, but if you know what a function structure is with the syntax definition, you should be able to know when a new function has been defined and highlight it appropriately when it's called elsewhere in the same file.
Again, use these ideas if you can. I would love to see one or more of these things as I think it just continues to make TextPad a professional and well rounded application.
Thanks for listening.
Enhanced Clip Library
Moderators: AmigoJack, bbadmin, helios, Bob Hansen, MudGuard
Good suggestions, and you are not (by far) the only person who thinks these things would be a good idea. Here are some points that you may want to consider.
NESTED CLIP LIBRARY
This is doable, but it requires a bit of extra work, and it can be just as cumbersome as the 'no depth' system that is in place now. One example
problem ... how do you distinguish your 'clip content' from
your 'clip markup syntax' ... if you use XML to define the structure, then
you run the risk of 'breaking' the structure when your user tries to create
a clip library that has XML in it. This is why 'clip library' developers typically invent their own syntax from scratch ... and typically why this syntax is 'flat'.
Nested Clip library can also be cumbersome because if you have a lot
of clips, it becomes difficult to remember which "branch" you put a particular clip underneath when working with your "hierarchy". It's a lot like trying to organize files inside folders, sometimes you can not remember which folder is the 'right one' to look for a particular clip. Then you see people making 'duplicate shortcuts' to snippets, and the whole thing can get disorganized and complicated fast (just like a file system).
SEARCHABLE CLIPS
One thing I think would be easier to implement, and perhaps even more useful than 'Nested Clips' is searchable clips. You can use a flat structure and still have the flexibility you want with the typical "tree structure" ("tree structure" often turns out to be more disappointment than it's worth in the long run).
GUI fans hate typing, and love browsing through trees, but if you are serious about finding clip entries fast, and keeping clips organized, this
type of approach proves useful. It is also a lot less work to actually develop (as opposed to a 'tree' structure).
Anyway, it takes quite a bit of thought and tedious work to do this functionality well, and even more work to do it *exceptionally* well ... and still maintain a top-class application, which is why I doubt TextPad will have any of this stuff added in any time soon. Hopefully I'm wrong.
NESTED CLIP LIBRARY
This is doable, but it requires a bit of extra work, and it can be just as cumbersome as the 'no depth' system that is in place now. One example
problem ... how do you distinguish your 'clip content' from
your 'clip markup syntax' ... if you use XML to define the structure, then
you run the risk of 'breaking' the structure when your user tries to create
a clip library that has XML in it. This is why 'clip library' developers typically invent their own syntax from scratch ... and typically why this syntax is 'flat'.
Nested Clip library can also be cumbersome because if you have a lot
of clips, it becomes difficult to remember which "branch" you put a particular clip underneath when working with your "hierarchy". It's a lot like trying to organize files inside folders, sometimes you can not remember which folder is the 'right one' to look for a particular clip. Then you see people making 'duplicate shortcuts' to snippets, and the whole thing can get disorganized and complicated fast (just like a file system).
SEARCHABLE CLIPS
One thing I think would be easier to implement, and perhaps even more useful than 'Nested Clips' is searchable clips. You can use a flat structure and still have the flexibility you want with the typical "tree structure" ("tree structure" often turns out to be more disappointment than it's worth in the long run).
Code: Select all
Allow the user to define the following for each clip entry:
- caption: (the text that appears in the clip window)
- prefix: (a short alphanumeric 'tag' to allow for grouping clips)
- desc: (optional description block for each clip)
- keywords: (optional semicolon-delimited list of keywords for each clip)
- comments: (allow comments in TCL syntax)
- body_prfx: (the first half of the content of the clip)
- body_sufx: (the second half of the content of the clip [if applicable])
Then, when the user wants to see specific clips, she can just type
into a text input box a search term (eg, UpperCase) and see all
clips whose caption, prefix, or keywords fields contain the word
UpperCase.
The important thing to remember is that the current Clip Library GUI
stays exactly the same (except for the new input box) ... It just allows
the user to dynamically "filter out" snippets based on the criteria she
specifies.
type of approach proves useful. It is also a lot less work to actually develop (as opposed to a 'tree' structure).
Anyway, it takes quite a bit of thought and tedious work to do this functionality well, and even more work to do it *exceptionally* well ... and still maintain a top-class application, which is why I doubt TextPad will have any of this stuff added in any time soon. Hopefully I'm wrong.
That's a good point, I guess there'd have to be a better interface to add clips. The interface would have to convert the clip into an xml compliant format.. meaning converting entities etc. Do you think there would be any problems if one took that route? There is also a second layer to consider, because if I was creating an xml clip with an xml entity in it (&) you would have to add something to that entity before processing so you could ignore it when converting back. But from the rest of your reply you don't like the idea so I won't push it.drefty wrote: NESTED CLIP LIBRARY
This is doable, but it requires a bit of extra work, and it can be just as cumbersome as the 'no depth' system that is in place now. One example
problem ... how do you distinguish your 'clip content' from
your 'clip markup syntax' ... if you use XML to define the structure, then
you run the risk of 'breaking' the structure when your user tries to create
a clip library that has XML in it. This is why 'clip library' developers typically invent their own syntax from scratch ... and typically why this syntax is 'flat'.
I agree.. However, I have to say that with a nested library it's really up to the user.. there's nothing forcing the user to make his/her library nested. Top level clips work the same as what's currently in place. Also, when parsing xml it's not that much of a hassle to disregard a tree structure and parse all clips as though they were top level. So adding an option for that is possible.drefty wrote: Nested Clip library can also be cumbersome because if you have a lot
of clips, it becomes difficult to remember which "branch" you put a particular clip underneath when working with your "hierarchy". It's a lot like trying to organize files inside folders, sometimes you can not remember which folder is the 'right one' to look for a particular clip. Then you see people making 'duplicate shortcuts' to snippets, and the whole thing can get disorganized and complicated fast (just like a file system).
Yeah, searching would be great.. and as mentioned earlier could possibly help with people getting lost in a nested structure. =).drefty wrote: SEARCHABLE CLIPS
One thing I think would be easier to implement, and perhaps even more useful than 'Nested Clips' is searchable clips. You can use a flat structure and still have the flexibility you want with the typical "tree structure" ("tree structure" often turns out to be more disappointment than it's worth in the long run).
Code: Select all
Allow the user to define the following for each clip entry:
- caption: (the text that appears in the clip window)
- prefix: (a short alphanumeric 'tag' to allow for grouping clips)
- desc: (optional description block for each clip)
- keywords: (optional semicolon-delimited list of keywords for each clip)
- comments: (allow comments in TCL syntax)
- body_prfx: (the first half of the content of the clip)
- body_sufx: (the second half of the content of the clip [if applicable])
The important thing to remember is that the current Clip Library GUI
stays exactly the same (except for the new input box) ... It just allows
the user to dynamically "filter out" snippets based on the criteria she
specifies.
I agree. The thing I like most about your idea is the 'prefix' grouping. In reality I can't think of a time when I need to have anything more than grouped. So your idea seems to satisfy everything I was looking for providing the entire list isn't shown and the groups are expandable/collapsible.drefty wrote: GUI fans hate typing, and love browsing through trees, but if you are serious about finding clip entries fast, and keeping clips organized, this
type of approach proves useful. It is also a lot less work to actually develop (as opposed to a 'tree' structure).
I just like to see things like this continue to grow. And to be honest, the reason I have these ideas is looking into different editors. These types of features are available to some extent in at least one freeware application. The thing I like about TextPad most is it's speed at loading and lack of bloat. My ideas don't change that I don't think.drefty wrote: Anyway, it takes quite a bit of thought and tedious work to do this functionality well, and even more work to do it *exceptionally* well ... and still maintain a top-class application, which is why I doubt TextPad will have any of this stuff added in any time soon. Hopefully I'm wrong.
Thanks for your reply Drefty.
XML FORMATTED CLIP LIBRARIES
One thing I should disclose, I actually *liked* the idea
of XML markup for a clip library, that is, until I
actually: 1) got to work on developing one; and 2)
tried using one that was already developed (see
JEdit.org and search for XInsert plugin).
XML seems perfect for this at first, but both
experiences showed me that the Devil is in the
details. You already uncovered another of the
(many) hassles, how do you tell the clip library
when to "interpolate" an entity reference into
a single character, and how do you tell it to pass
it through unmodified? You wind up either adding a
bunch of extra syntax to your clips (using a foreign
syntax you invent yourself, to avoid "collisions")
or you completely scramble your clip entries (eg
with base64 encoding) so XML doesn't choke on them.
In either case, you wind up with clip entries that
are unreadable unless you 'de-scramble' them. This
is the approach that the latest version of
Macromedia Dreamweaver takes IIRC.
In the final analysis, it really doesnt matter what
syntax you use. If it isn't all 100% transparent to
the user, most of them will not like it. The only
real advantage of XML is that your power-users can
do custom modifications of the clip library using
an XML-aware editor. (but this advantage vanishes
when you consider all the 'scrambling' and
'descrambling' that you have to do ...)
If you're curious, take a look at YAML.org which
is an alternative to XML that uses indentation
instead of tags. Indentation is good alternative
to 'markup' when you have to worry about content
that might contain *any* concievable type of data,
which is what a clip library is all about.
NESTED LIBRARIES
I think you are actually 100% on with your point
about nested libraries. The end user does not *have*
to use nesting if she does not want to, but that's
no reason to omit the functionality for users who
do want to use it.
I guess the point I was trying
to make is people tend to overestimate the added
flexibility you get from 'tree' structures. There
are other ways to 'show and hide' a subset of your
clips, so it's good to remember that trees are not
the only way to build a forest. :-)
On an interesting side note, take a look at the
TextPad on-line clip library and download the
library for wscript (windows script host). You will
notice that the user tried to shoehorn a tree
structure into the 'flat' TCL syntax structure!
It is a remarkable proof that some people definitely
*demand* trees in their clip library!
CLIP ENTRY FIELDS
I am with you on "keywords" it is
most likely overkill, but it's another one of those
things you can leave blank if you dont want to
use it, but you can fill in if you are gung-ho
about clip libraries ;-)
As far as "a control character" to specify the cursor
point, that's what TextPad does already, and it's
good enough. If you *really* want to provide complete
functionality, though, you will not satisfy everyone
unless you come up with a way to give 'fill in the blank'
style clip entries that allow for *more* than just one
'insertion point' (ironically, NoteTabPro is a competing
product to TextPad that does this, but lacks other things
that TextPad does).
Of course, once you go down the
'fill in the blank' road, you need to introduce a
syntax for specifying 'blanks' and for specifying
'default values' and for specifying default values
that are contingent upon other values and for (etc)
...
OTHER EDITORS
Your ideas make perfect sense, and these replies are
really just for the record for the 80% of people out
there who are reading this and realizing they are not
the only ones who thought of these things.
I already mentioned a couple of other editors out there
that do what you are talking about, but they have clear
disadvantages relative to TextPad. In fact it is quite
amazing. There is no *single* product out there (freeware
or otherwise) that seems to get all of the features and
performance characteristics 'down pat'. (at least I
haven't found it yet ... ) TextPad is the best for what
it does do (IMHO) and the least annoying for what it doesn't
do.
Hats off to you for your ideas which are both
well-considered and well taken.
One thing I should disclose, I actually *liked* the idea
of XML markup for a clip library, that is, until I
actually: 1) got to work on developing one; and 2)
tried using one that was already developed (see
JEdit.org and search for XInsert plugin).
XML seems perfect for this at first, but both
experiences showed me that the Devil is in the
details. You already uncovered another of the
(many) hassles, how do you tell the clip library
when to "interpolate" an entity reference into
a single character, and how do you tell it to pass
it through unmodified? You wind up either adding a
bunch of extra syntax to your clips (using a foreign
syntax you invent yourself, to avoid "collisions")
or you completely scramble your clip entries (eg
with base64 encoding) so XML doesn't choke on them.
In either case, you wind up with clip entries that
are unreadable unless you 'de-scramble' them. This
is the approach that the latest version of
Macromedia Dreamweaver takes IIRC.
In the final analysis, it really doesnt matter what
syntax you use. If it isn't all 100% transparent to
the user, most of them will not like it. The only
real advantage of XML is that your power-users can
do custom modifications of the clip library using
an XML-aware editor. (but this advantage vanishes
when you consider all the 'scrambling' and
'descrambling' that you have to do ...)
If you're curious, take a look at YAML.org which
is an alternative to XML that uses indentation
instead of tags. Indentation is good alternative
to 'markup' when you have to worry about content
that might contain *any* concievable type of data,
which is what a clip library is all about.
NESTED LIBRARIES
I think you are actually 100% on with your point
about nested libraries. The end user does not *have*
to use nesting if she does not want to, but that's
no reason to omit the functionality for users who
do want to use it.
I guess the point I was trying
to make is people tend to overestimate the added
flexibility you get from 'tree' structures. There
are other ways to 'show and hide' a subset of your
clips, so it's good to remember that trees are not
the only way to build a forest. :-)
On an interesting side note, take a look at the
TextPad on-line clip library and download the
library for wscript (windows script host). You will
notice that the user tried to shoehorn a tree
structure into the 'flat' TCL syntax structure!
It is a remarkable proof that some people definitely
*demand* trees in their clip library!
CLIP ENTRY FIELDS
I am with you on "keywords" it is
most likely overkill, but it's another one of those
things you can leave blank if you dont want to
use it, but you can fill in if you are gung-ho
about clip libraries ;-)
As far as "a control character" to specify the cursor
point, that's what TextPad does already, and it's
good enough. If you *really* want to provide complete
functionality, though, you will not satisfy everyone
unless you come up with a way to give 'fill in the blank'
style clip entries that allow for *more* than just one
'insertion point' (ironically, NoteTabPro is a competing
product to TextPad that does this, but lacks other things
that TextPad does).
Of course, once you go down the
'fill in the blank' road, you need to introduce a
syntax for specifying 'blanks' and for specifying
'default values' and for specifying default values
that are contingent upon other values and for (etc)
...
OTHER EDITORS
Your ideas make perfect sense, and these replies are
really just for the record for the 80% of people out
there who are reading this and realizing they are not
the only ones who thought of these things.
I already mentioned a couple of other editors out there
that do what you are talking about, but they have clear
disadvantages relative to TextPad. In fact it is quite
amazing. There is no *single* product out there (freeware
or otherwise) that seems to get all of the features and
performance characteristics 'down pat'. (at least I
haven't found it yet ... ) TextPad is the best for what
it does do (IMHO) and the least annoying for what it doesn't
do.
Hats off to you for your ideas which are both
well-considered and well taken.
-
SamuelReynolds
- Posts: 9
- Joined: Tue Dec 28, 2004 10:55 pm
- Location: Colorado
- Contact:
That's the one clip library enhancement I would most like (a nested tree would be the not-too-distant second). It could save me a fair amount of time and aggravation by reducing (mis)typing of common, repetitive code blocks (such as C++ accessor/mutator methods) that differ only in a small number of 100%-repeatable places.As far as "a control character" to specify the cursor
point, that's what TextPad does already, and it's
good enough. If you *really* want to provide complete
functionality, though, you will not satisfy everyone
unless you come up with a way to give 'fill in the blank'
style clip entries that allow for *more* than just one
'insertion point' (ironically, NoteTabPro is a competing
product to TextPad that does this, but lacks other things
that TextPad does).
- Sam
If by "insertion point" you mean what TP calls "hot spot" (see help for Clip Libraries) then I wholeheartedly agree with you, to the extent that I tried suggesting this myself at least two years ago! Perhaps the idea got lost in transmission.
It would be of great benefit to coders, facilitating commenting and block identification. For example, consider the "if" construct, typically spread over many lines (especially when nested). With multiple insertions of the pre-typed and highlighted condition, you can have something like:
if (condition) then
else // (NOT condition)
end // (condition)
to make it absolutely clear which lines correspond to which construct.
Let's hope the multiplcation of support for the idea encourages TP to give it serious consideration.
It would be of great benefit to coders, facilitating commenting and block identification. For example, consider the "if" construct, typically spread over many lines (especially when nested). With multiple insertions of the pre-typed and highlighted condition, you can have something like:
if (condition) then
else // (NOT condition)
end // (condition)
to make it absolutely clear which lines correspond to which construct.
Let's hope the multiplcation of support for the idea encourages TP to give it serious consideration.
-
JohnRudman
- Posts: 3
- Joined: Tue Nov 08, 2011 5:15 pm
I would like to add my voice to this enhancement request.SamuelReynolds wrote:That's the one clip library enhancement I would most like (a nested tree would be the not-too-distant second). It could save me a fair amount of time and aggravation by reducing (mis)typing of common, repetitive code blocks (such as C++ accessor/mutator methods) that differ only in a small number of 100%-repeatable places.As far as "a control character" to specify the cursor
point, that's what TextPad does already, and it's
good enough. If you *really* want to provide complete
functionality, though, you will not satisfy everyone
unless you come up with a way to give 'fill in the blank'
style clip entries that allow for *more* than just one
'insertion point' (ironically, NoteTabPro is a competing
product to TextPad that does this, but lacks other things
that TextPad does).
- Sam
If EVERY occurrency of \^ were replaced by the selected text it would certainly help with several of the language constructs I use every day.