On Fri, Jul 27, 2018 at 8:50 AM jason jgavris@gmail.com wrote:

This actually sounds exactly like the problem I was trying to address with this PR. I'm glad someone else is experiencing it!

https://github.com/textmate/textmate/pull/1405

On Fri, Jul 27, 2018 at 9:03 AM, Daniel Vollmer lists@maven.de wrote:

...

Hello list,

when opening (existing) files from Terminal.app using the `mate` command, it occasionally (but not always) takes a fairly long time (more than 5secs) to open the file in TextMate. TM in all these instances is already running, but doesn't necessarily have any open windows.

<snip>

I have also encountered this. But it is very rare. I can recall less than 5 times total and I use mate from the command line a lot. For the record I use iTerm rather than terminal, but I don't think that is relevant.

Hi Allan,

I’ve observed the following (which is from memory, so may not be 100% accurate), I’ll try to take notes from now on.

On 29. Jul 2018, at 09:34, Allan Odgaard mailinglist@textmate.org wrote:

People with this issue, can you let me know:

• What is the earliest version of macOS where you noticed the issue?

I’m confident of it happening back to macOS 10.12 at least, not sure about earlier.

• Is TextMate hidden when the problem happens?

I think yes, so either no open windows or all of them hidden. Not completely sure about this though. TM is indicated as running by the Dock (via the dot), but usually doesn’t have any open windows (at least on the current desktop).

• Is it likely that the file does open in TextMate and the delay is related to unhiding TextMate (or bringing it to front)?

It seems to. But at least for me both the window appearing and bringing it to the front both (which I can’t really separate) happens after the delay (or immediately after I manually re-activate TM via the Dock for example.

Daniel.

On 27 Jul 2018, at 15:03, Daniel Vollmer wrote:

Hello list,

when opening (existing) files from Terminal.app using the `mate` command, it occasionally (but not always) takes a fairly long time (more than 5secs) to open the file in TextMate. TM in all these instances is already running, but doesn't necessarily have any open windows.

This is for small files (e.g. 30 short lines of code), so it cannot be the file size making a difference. If I open the files directly through TM's File -> Open... menu, no such delay happens.

During such a delay, if I click on the already running TM in the dock to activate it, the desired document that `mate` is trying to open immediately appears.

If I close the document and retry immediately afterwards, then no delay seems to exist for a while. Swap also doesn't seem to be an issue, my swapfile has size 0 on a 32GB Macbook Pro, with 16GB free. If TM hasn't been activated in a while (even though supposedly running according to the Dock dot) then this seems more likely.

It seems to be the communication / connecting between mate and TM that causes this delay somehow. I've tried removing and reinstalling the `mate` command.

This is on TextMate version 2.0-rc.10, but is not new behavior, I've seen this for quite some time.

Does that sound familiar to anyone or have any diagnosis tips?

Thanks, Daniel.

---

textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate

---

textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate

Hello,

I'm also using a multi-monitor set-up.

One other non-standard thing I'm using is fish shell (with standard Terminal.app) instead of bash. Occasionally it feels like it isn't me "manually" activating TextMate that finally triggers the TM window to pop up, but instead activating any other app (or making anything but the terminal frontmost); but this is guess-work.

On 29. Jul 2018, at 16:57, Kevin Reid kpreid@switchb.org wrote:

On Sun, Jul 29, 2018 at 12:34 AM Allan Odgaard mailinglist@textmate.org wrote: People with this issue, can you let me know:

• What is the earliest version of macOS where you noticed the issue? It started when I upgraded from 10.11 El Capitan to 10.13 High Sierra (I skipped a version). • Is TextMate hidden when the problem happens? No. However, it might be relevant that I use a multi-monitor multi-desktop configuration. • Is it likely that the file does open in TextMate and the delay is related to unhiding TextMate (or bringing it to front)? TextMate is not hidden and so I'm pretty sure that the window is visibly not present (i.e. I can see the desktop behind where it is going to appear). The new window does appear in front of other windows on its own, just not promptly.

I can't confirm right now because the problem is not happening (it's intermittent and I haven't identified a cause).

---

textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate

On Sun, Nov 11, 2018 at 7:42 PM Allan Odgaard mailinglist@textmate.org wrote:

On 29 Jul 2018, at 16:57, Kevin Reid wrote:

I can't confirm right now because the problem is not happening (it's intermittent and I haven't identified a cause).

Try run something like this from a terminal to see if it is reproducible:

for (( i = 1; i < 50; i++ )); do echo -n "Edit $i..."; mate -w "/tmp/test $i.txt"; echo "Done!"; done

I did this myself but only issue I saw was that sometimes TextMate wouldn’t activate, mostly addressed in these two commits: https://github.com/textmate/textmate/compare/cc9faa602...d93972f95 and should only hapen when `mate` is used in succession.

No hang/slow when I ran your test. However, in my experience since the last discussion, the problem seems to come and go on a long time scale. Like there's something else about the system, like maybe the state of Spaces/fullscreen, that determines whether it happens; it isn't random each time.

Hello,

I haven’t really managed to diagnose this further, but occasionally I get the feeling that this might be due to how `fish` shell triggers execution of binaries (but again, I’ve only observed this in conjunction with `mate` — but that’s probably my most-used command-line utility that connects to the WindowServer by a large margin).

Daniel.

On 12. Nov 2018, at 05:30, Kevin Reid kpreid@switchb.org wrote:

On Sun, Nov 11, 2018 at 7:42 PM Allan Odgaard mailinglist@textmate.org wrote: On 29 Jul 2018, at 16:57, Kevin Reid wrote:

I can't confirm right now because the problem is not happening (it's intermittent and I haven't identified a cause).

Try run something like this from a terminal to see if it is reproducible:

for (( i = 1; i < 50; i++ )); do echo -n "Edit $i..."; mate -w "/tmp/test $i.txt"; echo "Done!"; done

I did this myself but only issue I saw was that sometimes TextMate wouldn’t activate, mostly addressed in these two commits: https://github.com/textmate/textmate/compare/cc9faa602...d93972f95 and should only hapen when `mate` is used in succession.

No hang/slow when I ran your test. However, in my experience since the last discussion, the problem seems to come and go on a long time scale. Like there's something else about the system, like maybe the state of Spaces/fullscreen, that determines whether it happens; it isn't random each time.

---

textmate mailing list textmate@lists.macromates.com https://lists.macromates.com/listinfo/textmate

If you're willing to rebuild TM from source, I tried to play with how `mate` launches in this pull request https://github.com/textmate/textmate/pull/1405. Allan suggested this was not the right approach, but I wonder if it was close to exposing the problem.

On Fri, Jul 12, 2019 at 1:50 PM Jay Soffian jaysoffian@gmail.com wrote:

I know I'm bumping an old thread. This behavior happens to me all the time (a few times a day). I haven't been able to figure it out. I don't use fish shell, but rather bash. I do use a multi-monitor setup but I think I've seen it when only using my laptop alone. It probably dates back to High Sierra. My typical use case is "mate ." in a directory, not a specific file. That directory will have a ".tm_properties" file making it a project. I use iTerm2.

So TextMate is running, I switch to a directory in iTerm2, type "mate ." then the command just hangs for 5-10 seconds before TextMate finally comes to the front.

The laptop has an SSD. I think the problem is worse when I have a USB drive attached for Time Machine.

I haven't thought to try clicking TextMate in the dock or command-tab switching to it. I will try that next time this occurs.

I assume the folks who were suffering from this problem in this thread have continued to put up with it? I know how frustrating it is. :-(

j.

On Mon, Nov 12, 2018 at 3:53 AM Daniel Vollmer lists@maven.de wrote:

...

Hello,

I haven’t really managed to diagnose this further, but occasionally I get the feeling that this might be due to how `fish` shell triggers execution of binaries (but again, I’ve only observed this in conjunction with `mate` — but that’s probably my most-used command-line utility that connects to the WindowServer by a large margin).

    Daniel.

...

On 12. Nov 2018, at 05:30, Kevin Reid kpreid@switchb.org wrote:

On Sun, Nov 11, 2018 at 7:42 PM Allan Odgaard mailinglist@textmate.org

wrote:

...

On 29 Jul 2018, at 16:57, Kevin Reid wrote:

I can't confirm right now because the problem is not happening (it's intermittent and I haven't identified a cause).

Try run something like this from a terminal to see if it is

reproducible:

...

for (( i = 1; i < 50; i++ )); do echo -n "Edit $i..."; mate -w

"/tmp/test $i.txt"; echo "Done!"; done

...

I did this myself but only issue I saw was that sometimes TextMate

wouldn’t activate, mostly addressed in these two commits: https://github.com/textmate/textmate/compare/cc9faa602...d93972f95 and should only hapen when `mate` is used in succession.

...

No hang/slow when I ran your test. However, in my experience since the

last discussion, the problem seems to come and go on a long time scale. Like there's something else about the system, like maybe the state of Spaces/fullscreen, that determines whether it happens; it isn't random each time.

...

---

textmate mailing list textmate@lists.macromates.com https://lists.macromates.com/listinfo/textmate

---

textmate mailing list textmate@lists.macromates.com https://lists.macromates.com/listinfo/textmate

---

textmate mailing list textmate@lists.macromates.com https://lists.macromates.com/listinfo/textmate

I have encountered this a lot lately as well. (I am using r27, on MacOS 10.14.5).

It seems that simply pressing a key will somehow signal Textmate to come to the front with the file open. I simply press the command key.

On Fri, Jul 12, 2019 at 1:29 PM Quinn Comendant quinn@strangecode.com wrote:

This happens to me everyday too! Every time, I spend the 5 seconds thinking, “I must be the only one, otherwise this would have been fixed by now.” 🤷‍♂️

Quinn

-- Sent from my mobile device; please excuse the terseness and typos.

---

textmate mailing list textmate@lists.macromates.com https://lists.macromates.com/listinfo/textmate

I don't know how related is this, but after I uninstalled the editorconfig plugin (editorconfig.org) for TextMate, it seems to have gotten better. At least I haven't gotten any hangs after "mate ." in the last couple of days.

Do you also use this plugin by any chance?

-- Sent from: http://textmate.1073791.n5.nabble.com/textmate-users-f3.html

On 12. Jul 2019, at 20:29, Quinn Comendant quinn@strangecode.com wrote:

This happens to me everyday too! Every time, I spend the 5 seconds thinking, “I must be the only one, otherwise this would have been fixed by now.” 🤷‍♂️

What shell is everyone using that has this problem? I’m using `fish`. Maybe it’s something in how the shell launches processes? Does it happen for anyone that uses bash or maybe zsh?

Daniel.

On 12 Jul 2019, at 19:49, Jay Soffian wrote:

I know I'm bumping an old thread. This behavior happens to me all the time (a few times a day). I haven't been able to figure it out. I don't use fish shell, but rather bash. I do use a multi-monitor setup but I think I've seen it when only using my laptop alone. It probably dates back to High Sierra. My typical use case is "mate ." in a directory, not a specific file. That directory will have a ".tm_properties" file making it a project. I use iTerm2.

Please go to Preferences → Software Update and ⌥-click the Check Now.

This should give you TextMate v2.0-rc.28 and mate v2.13.1-beta which does a bit of logging related to `mate` and TextMate’s “bring to front” code.

This is also in the release notes:

- - -

First run `mate --version` to ensure that TextMate auto-updated it to `2.13.1-beta` (if not, go to Preferences → Terminal and uninstall/install it).

When the problem occurs, immediately run `date` in your terminal to get a timestamp to correlate with the debug log.

Then run this command to obtain the log:

log show --predicate 'subsystem = "com.macromates.TextMate" && category = "BringToFront"'

See `man log` for options such as `--start date/time` (to limit the query to e.g. the last 10 minutes).

Follow up in this thread with the log with relevant information, such as whether or not you were using spaces and/or multiple screens at the time.

On 13 Jul 2019, at 4:30, Allan Odgaard wrote:

Please go to Preferences → Software Update and ⌥-click the Check Now.

This should give you TextMate v2.0-rc.28 and mate v2.13.1-beta which does a bit of logging related to `mate` and TextMate’s “bring to front” code.

I wonder if it’s the same issue people have reported for QS.

https://github.com/quicksilver/Quicksilver/issues/2482

As you can see, building with Xcode 10 (or the 10.14 SDK really) mysteriously fixes it.

On 15 Jul 2019, at 19:37, Jay Soffian wrote:

...

This should give you TextMate v2.0-rc.28

Hmm, I'm still seeing: "TextMate 2.0-rc.27 is the latest version available—you have version 2.0-rc.27.".

You need to hold down option (⌥) when clicking the “Check Now” button (as v2.0-rc.28 is a test build).

On 15 Jul 2019, at 22:09, Quinn Comendant wrote:

Any suggestions how I can solve “log archive format is corrupt”?

...

log show --predicate 'subsystem = "com.macromates.TextMate" && category = "BringToFront"'

log: Could not open local log store: The log archive format is corrupt and cannot be read

Based on StackOverflow you may need to call it with `sudo`: https://apple.stackexchange.com/questions/328741/log-could-not-open-local-lo...

https://gist.github.com/jaysoffian/a666f6c97ec05edfa4fb36247a428971

Note the 9 second delay here:

2019-07-15 19:47:13.559623-0400 0x11591cb Default 0x0 25937 0 TextMate: [com.macromates.TextMate:BringToFront] TextMate: Show file browser for /Users/jsoffian/Work/code/ycm/sentry/. 2019-07-15 19:47:22.561110-0400 0x11591cb Default 0x0 25937 0 TextMate: [com.macromates.TextMate:BringToFront] TextMate: Bring to Front requested, NSApp.isActive: NO

Connected to an external display. TextMate was already running and had other windows open on the external display. "mate ." command issued from a bash shell inside iTerm2. That window was also on the external display. The laptop display has only a single Slack window. My "Missing Control" preferences are:

- [X] Automatically rearrange Spaces based on most recent use (enabled) - [X] When switching to an application, switch to a Space with open windows for the application (enabled) - [ ] Group windows by application (disabled) - [X] Displays have separate Spaces (enabled) - Dashboard: off

j.

On Sat, Jul 13, 2019 at 4:30 AM Allan Odgaard mailinglist@textmate.org wrote:

On 12 Jul 2019, at 19:49, Jay Soffian wrote:

I know I'm bumping an old thread. This behavior happens to me all the time (a few times a day). I haven't been able to figure it out. I don't use fish shell, but rather bash. I do use a multi-monitor setup but I think I've seen it when only using my laptop alone. It probably dates back to High Sierra. My typical use case is "mate ." in a directory, not a specific file. That directory will have a ".tm_properties" file making it a project. I use iTerm2.

Please go to Preferences → Software Update and ⌥-click the Check Now.

This should give you TextMate v2.0-rc.28 and mate v2.13.1-beta which does a bit of logging related to mate and TextMate’s “bring to front” code.

This is also in the release notes:

First run mate --version to ensure that TextMate auto-updated it to 2.13.1-beta (if not, go to Preferences → Terminal and uninstall/install it).

When the problem occurs, immediately run date in your terminal to get a timestamp to correlate with the debug log.

Then run this command to obtain the log:

log show --predicate 'subsystem = "com.macromates.TextMate" && category = "BringToFront"'

See man log for options such as --start date/time (to limit the query to e.g. the last 10 minutes).

Follow up in this thread with the log with relevant information, such as whether or not you were using spaces and/or multiple screens at the time.

---

textmate mailing list textmate@lists.macromates.com https://lists.macromates.com/listinfo/textmate

https://gist.github.com/jaysoffian/86a3316892cbca10ff41be15b8691349

19 second delay this time:

2019-07-17 12:16:09.716981-0400 0x12f9658 Default 0x0 37899 0 TextMate: [com.macromates.TextMate:BringToFront] TextMate: Create new window 2019-07-17 12:16:28.001023-0400 0x12f9658 Default 0x0 37899 0 TextMate: [com.macromates.TextMate:BringToFront] TextMate: Check if state restoration has been disabled

j.

On Tue, Jul 16, 2019 at 2:51 AM Allan Odgaard mailinglist@textmate.org wrote:

Thanks for the reports, I’ve added further debug output based on these, as unfortunately they were not enough to pinpoint the exact problem.

Please update to v2.0-rc.29 and send me output from this build, when the problem happens again.

My theory is that this is the OS trying to obtain a lock which is already locked, and there is then a ~10 seconds timeout on this lock, which explains why the delay is always so close to 10 seconds (and so extremely long, compared to normal delays arising from loading data, swapping out memory, etc.).

---

textmate mailing list textmate@lists.macromates.com https://lists.macromates.com/listinfo/textmate

No, I never quite have time to get to it.

On Wed, Jul 17, 2019 at 2:11 PM Jacob Carlborg doob@me.com wrote:

On 17 Jul 2019, at 18:18, Jay Soffian jaysoffian@gmail.com wrote:

https://gist.github.com/jaysoffian/86a3316892cbca10ff41be15b8691349

19 second delay this time:

2019-07-17 12:16:09.716981-0400 0x12f9658 Default 0x0 37899 0 TextMate: [com.macromates.TextMate:BringToFront] TextMate: Create new window 2019-07-17 12:16:28.001023-0400 0x12f9658 Default 0x0 37899 0 TextMate: [com.macromates.TextMate:BringToFront] TextMate: Check if state restoration has been disabled

I haven’t really followed this thread, but have you tried doing a Spindump or Sample Process when this occurs? This is available using Activity Monitor, selecting the process (TextMate in this case) and picking the operation from the gear menu in the toolbar.

-- /Jacob Carlborg

---

textmate mailing list textmate@lists.macromates.com https://lists.macromates.com/listinfo/textmate

On 19 Aug 2019, at 3:06, Jay Soffian wrote:

Bump. Allan, any ideas here?

I have added even more debug output into rc.30 available by option-clicking Check Now in software update.

Unfortunately the previous debug output was not enough to give me any idea of what goes on; was therefore waiting for a second person to provide logging output, I got this today via IRC, and for this person, it is also stalling basically when creating the window, so now I littered the setup code with log statements.

For those with the issue, in addition to capturing the log, it would also be useful to create an alias in your shell a la:

alias s='sample TextMate 3'

Then when you realize it is stalling, immediately create new tab in terminal (⌘T) and run `s` to sample the process.

It is very likely some system code that is failing to obtain a spinlock with a 10s timeout, a sample should make this immediately obvious, where log statements added by me may take a while to pinpoint what exactly is triggering it (and pinpointing alone may not explain why, here a stack trace from sample would be a lot more useful).

On 21 Aug 2019, at 16:04, Curt Sellmer wrote:

I have downloaded rc.30 and will try to capture info when it happens again. What is the preferred way to send the log files to you?

I prefer feedback through this mailing list, alternative channels are listed at https://macromates.com/support

Here's another hang in the same place (between "Created OakTabBarView instance" and "Created OakDocumentView instance") according to the log, along with a five second sample started just before I ran mate:

https://gist.github.com/jaysoffian/b585e3614620db506de306bfc9b55975

It hung for 20 seconds, so the sample has only the first five seconds of the delay.

I'm using this wrapper around the mate command:

#!/bin/sh

find /private/tmp -name 'TextMate_*.sample.txt' -mtime +1h -delete

t0=$(date +%s) sample TextMate 5 -wait >/dev/null 2>&1 & /usr/local/bin/mate "$@" t1=$(date +%s)

dt=$(expr $t1 - $t0)

if test $dt -gt 3 then sample_txt=$(find /private/tmp -name 'TextMate_*.sample.txt' | sort | tail -1) cat <<__EOF__ mate took longer than 3 seconds. Sample here:

$sample_txt

Grab log with:

log show --predicate 'subsystem = "com.macromates.TextMate" && category = "BringToFront"'" __EOF__ fi

j.

On Mon, Aug 26, 2019 at 12:14 PM Jay Soffian jaysoffian@gmail.com wrote:

Thanks. I just had another hang. I accidentally deleted the sample, but the log indicates it happened here:

2019-08-26 12:01:00.422862-0400 0x1b9a4fd Default 0x0 37221 0 TextMate: [com.macromates.TextMate:BringToFront] TextMate: Created OakTabBarView instance 2019-08-26 12:01:10.571943-0400 0x1b9a4fd Default 0x0 37221 0 TextMate: [com.macromates.TextMate:BringToFront] TextMate: Created OakDocumentView instance

I'll report back next time it hangs with a sample.

j.

On Wed, Aug 21, 2019 at 6:09 AM Allan Odgaard mailinglist@textmate.org wrote:

...

On 19 Aug 2019, at 3:06, Jay Soffian wrote:

Bump. Allan, any ideas here?

I have added even more debug output into rc.30 available by option-clicking Check Now in software update.

Unfortunately the previous debug output was not enough to give me any idea of what goes on; was therefore waiting for a second person to provide logging output, I got this today via IRC, and for this person, it is also stalling basically when creating the window, so now I littered the setup code with log statements.

For those with the issue, in addition to capturing the log, it would also be useful to create an alias in your shell a la:

alias s='sample TextMate 3'

Then when you realize it is stalling, immediately create new tab in terminal (⌘T) and run s to sample the process.

It is very likely some system code that is failing to obtain a spinlock with a 10s timeout, a sample should make this immediately obvious, where log statements added by me may take a while to pinpoint what exactly is triggering it (and pinpointing alone may not explain why, here a stack trace from sample would be a lot more useful).

---

TextMate mailing list TextMate@lists.macromates.com https://lists.macromates.com/listinfo/textmate

I've had no hangs since upgrading to rc.31, so optimistically this was the problem and it is now fixed.

Thank you Allan.

j.

On Mon, Aug 26, 2019 at 4:04 PM Allan Odgaard mailinglist@textmate.org wrote:

On 26 Aug 2019, at 19:04, Jay Soffian wrote:

Here's another hang in the same place (between "Created OakTabBarView instance" and "Created OakDocumentView instance") according to the log, along with a five second sample started just before I ran mate:

Thanks, the sample makes it clear that the system is stalling while trying to talk to the shared clipboard server (daemon).

As an attempted workaround I no longer have TextMate read from the clipboard, unless it is active [1].

Please upgrade to rc.31 and let me know if you still see the problem.

[1] https://github.com/textmate/textmate/commit/7116dd777f07a65a675fe8944bc2fc2f...

---

TextMate mailing list TextMate@lists.macromates.com https://lists.macromates.com/listinfo/textmate

Thank you Allan! I have been running rc.31 for a few days myself as well. I have yet to see the hang on `mate -w`. Many happy commit messages written.

On Thu, Aug 29, 2019 at 5:43 PM Tyler Sommer sommertm@gmail.com wrote:

Also want to chime in and confirm rc.31 has been starting up instantly for me. Really quite striking the difference, I have to say! Great work!

Cheers

On Aug 28, 2019, at 10:23 AM, Jay Soffian jaysoffian@gmail.com wrote:

I've had no hangs since upgrading to rc.31, so optimistically this was the problem and it is now fixed.

Thank you Allan.

j.

On Mon, Aug 26, 2019 at 4:04 PM Allan Odgaard mailinglist@textmate.org wrote:

...

On 26 Aug 2019, at 19:04, Jay Soffian wrote:

Here's another hang in the same place (between "Created OakTabBarView instance" and "Created OakDocumentView instance") according to the log, along with a five second sample started just before I ran mate:

Thanks, the sample makes it clear that the system is stalling while trying to talk to the shared clipboard server (daemon).

As an attempted workaround I no longer have TextMate read from the clipboard, unless it is active [1].

Please upgrade to rc.31 and let me know if you still see the problem.

[1] https://github.com/textmate/textmate/commit/7116dd777f07a65a675fe8944bc2fc2f...

---

TextMate mailing list TextMate@lists.macromates.com https://lists.macromates.com/listinfo/textmate

---

TextMate mailing list TextMate@lists.macromates.com https://lists.macromates.com/listinfo/textmate

---

TextMate mailing list TextMate@lists.macromates.com https://lists.macromates.com/listinfo/textmate