Issue with text entry

Thanks @satikusala and @eastgate - I understand now the context.

Many Thanks @mwra. That lets me do exactly what I want, to view the text of one note conventionally, and write a summary of that text in a text window of another note.

Unfortunately, after adding a few words of text in the text window, Tinderbox repeatedly closes and I get an Apple crash report. I have managed to replicate this in a new Tinderbox doc with two notes with a few paragraphs in each, and it may be associated with creating bullet points and adding further text to these.

However I can work with a less elegant solutions, such as summarising text in Apple Notes and pasting that into the required note later.

1 Like

Sorry to hear that. Do please make sure to get any crash logs and steps for repetition direct to tinderbox@eastgate.com as such info is important to help the developer find the cause.

FWIW, in case it helps: Where are crash and hang logs found?

I’m unable to reproduce this.

Please email any crash report to tinderbox@eastgate.com; we can’t fix what we don’t see.

Thanks @eastgate - Just done with a simple test file that replicates the problem
Malcolm

What method are you using to create bullet points—there are several, those most of us only use one. so it helps to know.

I did this check (v10.0.2, macOS 15.1.1):

I have 4 notes selected, one of which “Another Note” is also open as a text window. If I edit in the latter window, the composite text in the text pane is not updated, but, if I click the tab (blue area above the view pane) this refreshes both panes and the edit shows up in the composite.

But, still a bit unclear as your edit configuration. In your demo TBX above (up thread) I don’t see any bullets in the $Text.

Might it be a good idea at this point to send the discussion of Text Window to its own thread? People might have more to contribute about Tinderbox for longform writing…

[admin] I’ve moved this branch to a new thread to de-interleave with original topic. Boty remain open for further discussion.

Thanks @mwra, and thanks also for moving the thread, I was thinking the same about contaminating the previous thread, I wasn’t expecting an issue to take up space.

Re your question, I was selecting bullet point entry via the ruler. However bullet points seem to be a red herring; I found I can get the crash, in a new document with one note, with vanilla text entry into the text window, after about 100 characters at most. I’ve sent the crash reports and files to @eastgate. The challenge is that he can’t replicate it (even with the sent file) and unless someone else encounters the problem I’m not sure how this can be furthered.

FWIW, I can’t replicate it either. Certainly it is not as simple a trigger as typing in the $Text of a stand-alone window. This suggests either we don’t have the causal steps accurately enough or something else running on your Mac is unexpectedly a factor in this. No fault on your part here. The challenge at this point is to replicate your issue in the same software on a different computer.

I’ve tried generating the effect in both the v10.0.2b693 public release and the most recent beta (though the latter hasn’t yet addressed this as we don’t know the cause!). Both have no problem with text entry. I also have TextExpander running (following the input key stream) so I’d strike that out as a possible factor.

For clarity, by ‘text window’ do you mean the $Text area of the text pane of a document window or the text are of a stand-alone text window?

If I understand you correctly, if you make a new TBX file, add a single note and start typing, after c.100 characters of input the app crashes? If not, what else has to be present (extra notes, different focus/selection, etc.)? If there are multiple windows we need to know what type they are.

Sorry for all the questions. It’s a matter of narrowing down the causal context, which may be accidental to your maaer of use but may not be so used by others. Murphy’s Law. It would appear the crash logs also aren’t (again, not anyone’s fault!) giving the developer any clue as to the context of the crash.

Thanks for the response, Mark

The text area of a stand-alone text window.

Correct. No other complications.

So …

to explore this, I’ve just shut down my Mac, restarted, opened Tinderbox only, added a first note to the default Tinderbox ‘Untitled’ window, called it ‘Test’ and then opened a Text Window and started typing. This time I got about 150 characters entered before Tinderbox crashed.

OK, the is definitely not repeatable here. This would suggest (not proof!) that the issue is something special to your Mac’s set-up, as opposed to a Macs in general. If you have any utilities that are monitoring the overall text input to you Mac it is worth quitting those sand seeing if there is any difference.

I have a potential candidate for the problem.

I tried turning off anything that might be jumping in and causing a problem, even when no other apps were running. My intial focus was Devonthink’s menu bar items, which keeps going even when Devonthink isn’t running. I also tried turning off every other menu bar item that wasn’t part of the standard Apple installation (iMenus etc., though I couldn’t see why that would intefere.

I then noticed that Apple Shortcuts had become a menu item with a Tinderbox shortcut that I hadn’t intentionallly put there, although it was stalling because I hadn’t given permissions

Anyway, the crashes still kept happening.

Then I also noticed, in the Tinderbox Text window, that I started getting unpredictable behaviour with the cursor suddenly jumping back to the previous location, and substituting the text that I had just written with some half formed word, as I wrote, with no other feedback.

That made me suspect Predictive text. Going to System Settings I searched for ‘predictive’ and in the ‘Keyboard’ sub-dialogue I saw that all four options, from Correct spelling automatically to ‘Add full stop with double space’ were on. I turned them off, so:

Since then I haven’t had a crash, nor any other unexpected behavioiur, when using the Text Window.

If anybody fancies experimenting with turning these four options on, and seeing if they get crashes when using Tinderbox’s Text Window that would be interesting and helpful, but not vital.

Hopefully I won’t be coming back on and saying the problem is still there after all!

Ah, yes. Anything that thinks it knows how to write better than I do gets turned off instantly with any device that I own.

I hope the problem is solved for you.

1 Like

Writing Tools in Sequoia 15.2 are often buggy and crashy in Tinderbox and elsewhere.

Glad the issue seems fixed. FWIW, this my Settings pane for this:

The inline predictive text does seem to cause an issue, though I use it very rarely. I think it was new to Sequoia and arrived with a default ‘on’ setting. But if I uses it and see crashes, I’ll likely turn it off. not least, it only knows/suggests school-level vocabulary so fails against my English … whose vocabulary has expanded since schooling back in a previous millennium. :open_mouth:

1 Like

Another thing that sneaked in without my really noticing. I’ve turned it off now. Apart from it being limited, I think it is also more American than I am (see “sneaked”).

1 Like

I fear that is more due to the ‘available’ (i.e. borrowed/stolen) data used for training than overt parochialism. AmE is probably the largest corpus is recent (i.e. likely digital) English.

I’d love to see the continuation if trained on Elizabethan, Georgian or late Victorian (British) English. :slight_smile:

Yrs obediently,
etc. etc…