Considering removing document embedded searches


#1

I’m just now putting the finishing touches on allowing for saved searches in TaskPaper’s user defaults, along with a user interface to edit them. My question … is it worth while keeping embedded @search() syntax now that user defaults searches are in place.

Benefits

  • Searches travel with the document
  • Each document can have unique set of searches

Costs

  • Confusing tag syntax, creates a search,
  • Often have the problem where search matches itself, which isn’t wanted most of the time
  • Hard to edit embedded searches (escape sequences, etc), causes much user frustration
  • Complicates sidebar user interface, two types of searches listed. Users must understand the difference, need some sort of different styling, etc.

I’m pretty much convinced myself that it will be much better to remove embedded searches. This post is a heads up, and a last chance for anyone to speak up who things embedded searches are a must.


#2

I’ll vote to keep both. I really like the idea to have default searches that will stay between documents, but the embedded searches could help to expand the search for specific documents. I mean, for example, if I have a document that is used to keep track of my development and bugs, I would set a search that could show me the bugs that are set to a certain priority. However, I wouldn’t want this search to be on all of my documents, I think this will add more clutter…

That’s just an idea, but I think that having default searches would be great so we don’t have to copy & paste on every new document and this will help newcomer, but embedded searches could be used for maybe more “advanced/adventurer” users or those who like to set things their way (default searches or default + embedded searches or embedded searches only). And from what I’ve seen in the forum, many seem to like configuring TaskPaper exactly the way they want, so having both ways of search could help them…

Just my 2 cents


#3

can’t help but think my recent question had a little bit to do with this. :wink:

i can see GuiB’s point of needing different searches depending on the document.


#4

Keep both. I also like the ability to have specific searches for specific documents.


#5

If one becomes easier to use, the other will become a power user feature and everybody wins! :slight_smile:


#6

Actually not really… more of a justification :slight_smile: I just got sick of hacking around issues with the way that those searches are implemented… especially now that I’m also saving them to defaults with a clearer interface.

Both… ok, thinking about the user interface more… how about keep both, but for the document specific searches I’ll store them in an extended file attribute instead of embedded in the document with @search tags. This way you’ll get document specific searches, but without the weird @search interface.


#7

I’m fine with this option. I mean, I don’t really mind the interface as long as we can define some document specific’s searches.


#8

I like it, just curious if that will sync across computers.


#9

From my understanding, Jesse wants to put the searches as metadata to the file. So, the file will keep those extra information directly and will move with them… Am I right @jessegrosjean ? I said that I don’t really mind the interface, but actually I would like the searches to follow the file as well if I move them to another computer or hard drive :wink:


#10

Yes, that’s current plan.


#11

[quote=“jessegrosjean, post:1, topic:2373”]
I’m pretty much convinced myself that it will be much better to remove embedded searches. This post is a heads up, and a last chance for anyone to speak up who things embedded searches are a must. [/quote]

If you mean clicking on a tag and getting search results as embedded tags then I vote no to keeping them. At least, I don’t use them. Now that I have understood how to hoist a project to focus on it I don’t have any worries in that department anymore.

The Menubar search seems quite good. Never has failed to find anything and can be brought up with a keystroke so that works for me.

The custom searches I have built are very important to my workflow and I would not like to see them go away.

For my workflow I think the Tags section would do better if it was revealed in a menu window for those times you want to review the tags you have already used. To me it is a clutter on the sidebar and at least could become collapsed so not to clutter the sidebar.

I do use tags for priority and such but I am also making good use of tags to format; lines above, lines below, color according to level of indent, etc. I have zero use for auto searching any style tags. If I want to find all instances of a tag then I hit shift-option-F and put in the tag.

Not seeing the value of keeping this. My .02 cents anyway.


#12

So excited about this!


#13

I really like and use the embedded searches. Each document with it’s own list, tailor-made.


#14

Best idea would be to have a setting in preferences as to which sections to include on your sidebar; Searches, Tags, Projects, all or some.


#15

If I understand you correctly, I think that what you are suggesting would create some confusion; because those searches would not be a part of the files themselves (e.g., sync something across computers and sending the file to someone else), but a setting on the program itself. Also, that option would by design create universal searches. Having that as a metadata (extra information that is part of the taskpaper files), would allow us to just add certain search queries to certain documents.


#16

[quote=“Victor, post:15, topic:2373”]
If I understand you correctly, I think that what you are suggesting would create some confusion; because those searches would not be a part of the files themselves (e.g., sync something across computers and sending the file to someone else), but a setting on the program itself. Also, that option would by design create universal searches. Having that as a metadata (extra information that is part of the taskpaper files), would allow us to just add certain search queries to certain documents. [/quote]

Perhaps I have not understood Jessie’s OP? Embedded search to me means click on a tag and it performs an automatic (embedded) search. If this is about searches specific to a document vs searches that are global vs collaborative (shared) documents then those are all interesting questions. As for me I use it one document at a time and I do not share documents of this nature. When I do collaborate I most often use Word. Not many people I collaborate with use Macs and AFAIK TaskPaper is Mac only.

When I put in a saved search (“@seaerch …”) then it is specific to that document and boilerplate as many searches do of course repeat often. I can and probably will put those boilerplate search strings in a typinator expansion.

There are three areas which now appear on the sidebar as of the beta; Projects, Searches, and Tags. There is a fourth area, Home, at the top. If Jessie was able to put into preferences a way to show or hide these three items in the sidebar - at the same time enabling or disabling them, one would always have to be left on by default but perhaps the user could choose which one, then that might help him in his decision to remove embedded searches.

If you click off [ (x) Projects, (x) Searches, ( ) Tags ] in preferences, Tags doesn’t show in the sidebar and there are no embedded searches with tags for (any) document until you turn it on again.

Remembering preferences by document vs globally is another question but as I am reading this we are talking about a global preference applied to all documents.