What is the newest macOS version that will run (or “support") TextMate 1.5[.11 (1635)]?
(Reason to ask: I never bothered to update my customized LaTeX bundle to TextMate 2, shame on me!)
Remark: I see https://macromates.com/download’s note "For OS X 10.9 and later, TextMate 1.x is not suitable as it relies on system components no longer available”; yet 1.5 is still perfect for me here on Yosemite (10.10.5).
On Feb 28, 2020, at 10:44 PM, FZiegler fz.2009@klacto.net wrote:
What is the newest macOS version that will run (or “support") TextMate 1.5[.11 (1635)]?
(Reason to ask: I never bothered to update my customized LaTeX bundle to TextMate 2, shame on me!)
On Feb 28, 2020, at 9:00 PM, FZiegler fz.2009@klacto.net wrote:
Remark: I see https://macromates.com/download’s note "For OS X 10.9 and later, TextMate 1.x is not suitable as it relies on system components no longer available”; yet 1.5 is still perfect for me here on Yosemite (10.10.5).
On Feb 28, 2020, at 10:44 PM, FZiegler fz.2009@klacto.net wrote:
What is the newest macOS version that will run (or “support") TextMate 1.5[.11 (1635)]?
(Reason to ask: I never bothered to update my customized LaTeX bundle to TextMate 2, shame on me!)
I use TextMate 1.5 on El Capitan, macOS 10.11.6. That is the latest version of the OS that runs on my computer. I keep using TM 1.5 for a couple of reasons and one is that about a year ago I tried switching to TM 2. My modified version of the Ada bundle didn’t work on TM 2 and when I tried to switch back to TM 1.5 I discovered that some stuff that TM 1.5 needs had been clobbered or deleted. I was eventually able to recover but I can’t recall everything that I did.
There was a period around the OS version that you mention where the Apple-supplied version of Ruby was inappropriate and the TM web page gave instructions on how to work around that. I don’t know if you can still find that.
At some point I will have to switch to TM 2 but that probably won’t happen until this Mac breaks and I get a new one that runs TM 2.
TM 1.5 with the Ada bundle currently does not correctly follow the compiler error bug links back to the correct place in the source code window. Instead, it opens a new source code window and scrolls to the correct line there. You can edit your code in the new window but the changes are not reflected in the original window unless you reload the file, a huge PITA.
I know this isn’t terribly helpful to you. This list is not very active but at least you have something to read. :-)
Jerry
On 3 Mar 2020, at 18:09, list_email@icloud.com wrote:
TM 1.5 with the Ada bundle currently does not correctly follow the compiler error bug links back to the correct place in the source code window. Instead, it opens a new source code window and scrolls to the correct line there. You can edit your code in the new window but the changes are not reflected in the original window unless you reload the file, a huge PITA.
This could probably be caused by symbolic links in the path, as it sounds like TextMate 1.5 considers the path from the Ada error output different to the currently open file.
On May 10, 2020, at 6:28 PM, Allan Odgaard mailinglist@textmate.org wrote:
On 3 Mar 2020, at 18:09, list_email@icloud.com wrote:
TM 1.5 with the Ada bundle currently does not correctly follow the compiler error bug links back to the correct place in the source code window. Instead, it opens a new source code window and scrolls to the correct line there. You can edit your code in the new window but the changes are not reflected in the original window unless you reload the file, a huge PITA.
This could probably be caused by symbolic links in the path, as it sounds like TextMate 1.5 considers the path from the Ada error output different to the currently open file.
[I’m not sure how this e-mail got on this thread—I think it’s the wrong thread and I can’t find the original.]
Thanks for understanding my rather poorly-described problem. You figured out that the bug links that I mentioned were in the (HTML?) window that TM makes for some bundles with the links to buggy source lines.
Anyway…
This has been a problem for a long time but not, as far as I can remember, forever. I don’t know when I first noticed it.
I checked anything that I thought could be related to symlinks and didn’t turn up anything.
So… this is weird. The problem happens only when the file name begins with an upper-case letter! So for example,
/Users/jb/Documents/Programs/Ada/Code/My_Projects/TextMate_Sampling/source/Hermite.adb
does _not_ work (it throws up the spurious window while building) but
/Users/jb/Documents/Programs/Ada/Code/My_Projects/TextMate_Sampling/source/hermite.adb
_does_ work.
After I exercised and exorcised all my other superstitions and tried this (changing the case of the file name), I finally noticed that the name in the title of the new, spurious, source window was the source file name but with upper case letters replaced by lower-case letters. So, for example, Test_Hermite_Cubic_Spline was displayed in the new title bar as test_hermite_cubic_spline, and, if I’ve not been clear yet, the malfunction was then present.
Summary: Don’t use upper-case letters in the file name.
Final note: Is this a Ruby thing? I’ll paste the build script below—some of it will look foreign to most. I’ve modified this from the original Ada bundle.
I know I’m weird using TM 1.5 but TM2 doesn’t run on my machine. I’ll make another post about that. I don’t mind if this post doesn’t get noticed because I think I’ve “fixed" the problem.
Jerry
export PATH=$MY_GNAT_BIN:$PATH; . "$TM_SUPPORT_PATH/lib/webpreview.sh" html_header "Building “${TM_FILENAME}”…" $MY_GNAT_BIN/gprbuild $MY_PROJECT_ROOT/build.gpr &> >(ruby -rtm_parser -eTextMate.parse_errors) if [[ $? == 0 ]] then echo "Build succeeded." afplay /System/Library/Sounds/Ping.aiff osascript -e 'say "woo hoo!" volume 0.25' else echo "Build failed." afplay /System/Library/Sounds/Bottle.aiff osascript -e 'say "Crap!" volume 0.25' fi html_footer
On 28 May 2020, at 7:34, list_email@icloud.com wrote:
After I exercised and exorcised all my other superstitions and tried this (changing the case of the file name), I finally noticed that the name in the title of the new, spurious, source window was the source file name but with upper case letters replaced by lower-case letters. So, for example, Test_Hermite_Cubic_Spline was displayed in the new title bar as test_hermite_cubic_spline, and, if I’ve not been clear yet, the malfunction was then present.
Summary: Don’t use upper-case letters in the file name.
Final note: Is this a Ruby thing? I’ll paste the build script below—some of it will look foreign to most. I’ve modified this from the original Ada bundle.
The code to “parse errors” in your build command should not do these case transformations.
But I searched for `gprbuild` and `lowercase` and found this link:
https://docs.adacore.com/gprbuild-docs/html/gprbuild_ug/gnat_project_manager...
So it appears that the Ada build tool might do some case transformations.
-
Allan Odgaard -
FZiegler -
list_email＠icloud.com