TaskPaper 3.5 Preview (266)

Update Just changed this post from 265 to 266 … which makes a change to fix the frequent crashes when changing sidebar item. But otherwise should be same as 265

I’m aiming to start the final stretch here and release 3.5 before too long. This release allows you to edit saved searches in the sidebar, and works with macOS 10.12 tabs quite a bit better. Also saves your editor state (collapsed items, etc) once again. As always, let me know how it works and report any bugs that you run into.

  • Added “Open in New Window” option for sidebar items
  • Added “Open in New Tab Bar” option for sidebar items
  • Added Sidebar menu options for managing saved searches
  • Added Allow delete backward to un-indent items preference
  • Changed Autoexpand sidebar groups when going from 0 to more items
  • Reorganized menu items to better fit 10.12’s “Show Tab Bar” item
  • Fixed Edit > Copy Displayed (for real this time!)
  • Fixed Crash when closing window while mouse ponter is in window
  • Fixed Rare sidebar redisplay probem when moving projects
  • Fixed Crash when fully replacing text of focused item
  • Fixed Crash when reording items in sidebar with empty editor view
  • Fixed Once again remember outline state: focused and collapsed items, etc
  • Fixed Window restoration when there are multiple windows (or tabs) for a single document
  • Fixed Relative file path links
  • Fixed Undo problems x3!

Issue Tracker

If you don’t see your problem in the issue tracker then I’ve missed it. Please help by adding an issue or sending me a reminder. Issues in Ready and In Progress states are for v3.5.

Download

1 Like

Not sure if this is the right place to mention it: v265 crashes on me whenever I click something in the sidebar. I cannot reproduce the crashes with a test document, maybe it’s because my main doc is somewhat large. Happy to send a crash report.

Also, I have these searches in the document; they no longer show up as searches in the sidebar (worked fine in v260). Did the format change?

Searches:
    Today @search(\(\(@today or @due<=[d]today\) and not @done\))
    Due soon @search(\(@due>[d]today and @due<[d]+5 day and not @done\))
    Overdue @search(\(@due<[d]today and not @done\))

Yes, please send crash report to jesse@hogbaysoftware.com. There also might be a some useful info in Console.app. Thanks!

Instead you can store custom searches through the sidebar … right click on the “Searches” section in the sidebar to get started creating a new search.

By default new searches that you create will be saved to user defaults, so they will be displayed for all documents that you open. There’s also an option to “Use for current document only” in which case the search is saved as an extended file attribute, so it will only show up in that document.

Like @pascal, I’m getting a lot of crash while interacting with the sidebar. @jessegrosjean, I just sent you some crash reports by email. Also, I was wondering, would it be possible to change the order of the searches in the sidebar ? Since I would prefer to put the order that I want and now I can’t seem to be able… Thanks for your work!

I forgot to say… I’m on OS X El Capitan (10.11.6)

Alright, reports sent, hope they are useful!

The “New Search” is quite well hidden, I did not find it myself, I was looking for a menu item. I’m also missing a “Save search” feature when I have a search in the search bar. Could be useful to have.

@GuiB @pascal Please let me know if you see more of a pattern to this crash. I’m not noticing any crashes when interacting with the sidebar in my own documents. Things I’m interested in:

  1. Can you reproduce in default document?
  2. If not, can you create a document that will reproduce the problem and share it here?
  3. Does the problem happen when you click on any item in the sidebar, or only certain items?

I reverted back yesterday to the 260 build, but I just reinstalled the 265 build to test this, but strangely, today it seems to be way better… I don’t get any crash for the moment, I’ll let you know if I stumble on some, but for the moment, the only way I got a crash is by writing an “old style” searchName @search() embedded in the document and then by clicking on something in the sidebar. So, I guess the new way of defining searches doesn’t like to see the older method… However, yesterday I removed all those embedded searches from my document and I got many crash afterwards and now I’m loading those same documents and now it seems to be working… So, I’ll continue to investigate this, but in the meantime I would say that it looks fine now, for I don’t know exactly for which reason… Or maybe the reinstallation helped something, but I didn’t removed any preference files or cleared any caches.

I have managed to reproduce this bug very consistently. Just create a large document and then run a search from the sidebar or even one using the old @search tag. To create the large document, just copy and paste something several times. I am sending the crash report too.

Ok, thanks, I just reproduced the problem. Will get a fix out early next week I expect.

1 Like

@pascal @GuiB @Victor Thanks all, I’ve just released 266 which I think fixes the crash when changing selection in the sidebar problem.

Thanks, it works. I think that somebody mentioned that it would be a good idea to create more menu options for the new search functions. I second that opinion. Again, thanks

Confirmed fixed for me as well, thanks a lot!

Thanks @jessegrosjean! It seems to be running fine on my side as well! I tried to insert the old embedded search style in my document and it didn’t seem to interfere. So, looking great ! Thanks again for your work!

Adding those now…

Any thoughts on where they should go in the menus? One possibility is in the same place in the View menu as “Hide Sidebar”… since they are located in the sidebar. Would that make sense?

Good question, I’m not sure myself. Maybe it’s even suitable for the “Edit” menu? What I did expect initially is a button in the search field, to the left of the [x] button, that says “save search” or something, similar to the Finder.

Speaking of searches, I chose “Use for current document only”, however on a second Mac, the search does not show up for this document. Isn’t it expected to sync to other Macs?

This update is really looking great.

One request after using tabs for a few days: would it be possible to have the full file name visible in background tabs?

The way it is currently working, the user sees the file name of the active tab in the title bar only and only the selected project name on the tab. The problem comes when the user has lots of tabs open and all just read “Home” when in the background. Finding the right tab without the tab showing the file name as well as the project is pretty tough!

Looking at built-in Apple apps, they all show the full file name on the tab. I realize that there is the added info of the selected project in Taskpaper, but the current solution is hard to track past a couple of files. Any chance of just the file names on the tabs and the file name plus the selected project in the title bar for the active tab?

With the current menu arrangement, yes, View is a logical choice. (I might think about moving the Tag menu items to a sub-section of Item, since everything on that menu is done to one or more items, and then having a separate Sidebar or Search menu. Hey, I just said I’d think about it!)

I’ve got a fix for this in the next release I think. It will show the current UI labels when all tabs refer to the same document (i.e. they were created with File > New Tab), but once you add a tab that has a different document the display will change to include the document title as part of the tab label.

I have to admit that I haven’t played much with multiple tabs from a single document, so I hadn’t thought about what this means for tab naming complexity. Sounds like you have a great solution lined up though. Thanks!

1 Like