Is it possible to show an NSPopover using a custom nib and the dialog command? Or does the NSPopover require some code to show it?
My use case is a command I’m working on for displaying generated documentation, i.e. JavaDoc, for a given symbol. So far I’ve been using a tooltip, It’s working fine but the problem with the tooltip is that it doesn’t support scrolling, when the content gets too long. Ideally I would like something that also is interactable, like clicking on links. I would like to avoid the HTML window/view because I think it’s bit too heavy.
--
/Jacob Carlborg
> From: "Allan Odgaard" <mailinglist(a)textmate.org>
> Subject: [TxMt] Re: Weird file not updating problem
> Date: August 21, 2016 at 2:56:20 AM PDT
> To: "TextMate users" <textmate(a)lists.macromates.com>
> Reply-To: TextMate users <textmate(a)lists.macromates.com>
>
>
> On 20 Aug 2016, at 8:57, Jack Royal-Gordon wrote:
>
>> I made some changes to a file that was open as part of a Rails project (the whole project was opened) and saved the changes. TextMate showed the file as having no unsaved changes. However, inspecting the file outside of TextMate, I could see that the the changes were not saved.
>
> And even pressing ⌘S did not change that? ⌘S will always save, even if it shows “no changes”.
Did press ⌘S several times, as when I ran the file and it did not work I thought I had forgotten to save.
>
> Also, when you have a file open, you can use Bundles → Diff → Document With Saved Copy. This will run a diff util on the buffer and the file on disk, that should be able to confirm if somehow TM’s buffer is different with the file on disk after ⌘S.
That’s a good idea. Did not know about that.
>
>> I rebooted my computer and when TextMate reopened, there was the file with my changes showing (but which were not saved although again it showed as having no unsaved changes). I had to close the file, reopen it, and re-apply the changes before saving again in order to actually save the changes
>
> So you rebooted, re-opened the file, and while TM found your (unsaved) changes, it would still not save on ⌘S. But closing file (again) and re-opening now did show the file on disk, and you could save?
Correct. When I reopened, it showed the file without the changes that did not save.
>
>> […] I wanted to see if this was a known issue with 2.0-beta.12.
>
> Nothing I have heard of before, but from the description above, it really sounds like TextMate was operating on a different file than what you was inspect on disk, that would explain all of the behavior perfectly, including rebooting and showing the updated file “with no changes”, yet after closing it and opening the (right) file, you now lost the changes, and had to re-do them.
Since I opened a folder in Textmate and was accessing files via the File Browser, I have a hard time imagining how it was accessing a different file. But I agree that that would explain all of the strange behavior.
>
> So what should probably be looked into is, how did it get to operate on this other file, and where on disk was it?
Yes, that would be the question.
>
> Did anything work on the files on disk (TextMate will track renames, hence if you open /path/to/file and then move it to /path/to/other/place, it will update its reference).
>
> Should it ever happen again, you can right-click the proxy icon to see where the file is on dis, or use File Browser → Reveal Document.
I will do that. Thanks for the response.
Hi All,
I made some changes to a file that was open as part of a Rails project (the whole project was opened) and saved the changes. TextMate showed the file as having no unsaved changes. However, inspecting the file outside of TextMate, I could see that the the changes were not saved. I rebooted my computer and when TextMate reopened, there was the file with my changes showing (but which were not saved although again it showed as having no unsaved changes). I had to close the file, reopen it, and re-apply the changes before saving again in order to actually save the changes (I probably could’ve copied the entire file onto the clipboard before I closed and reopened and made the changes that way, but I didn’t expect the changes to be gone).
Before opening an issue on GitHub, I wanted to see if this was a known issue with 2.0-beta.12. I’m running on OS X 10.11.6. Let me know if you need any other configuration information or have any thoughts that might help me to reliably reproduce this problem (I’ve noticed a couple times where files that were left open while changing GIT branches did not recognize that the underlying files had changed as TextMate 1 did. Might this be an issue with capturing directory change events?
Thanks in advance for helping!
Jack
If I have a command with the following Ruby code:
require ENV['TM_SUPPORT_PATH'] + '/lib/ui'
result = [{ 'match' => 'foo', 'display' => 'foo' }]
TextMate::UI.complete(result)
If I type "f" and then invoke the command the completion menu appears as expected, containing "foo". If I type a non-matching character, like "s" then it takes around three seconds for the menu to disappear and the "s" to appear in the editor.
Not sure if it's related, but if I select some other text in the meantime the "s" appears immediately.
—
/Jacob Carlborg
Hi,
When I do a "Find in Project" and click "Replace All", the dialog states "2
replacements made across 1 file(s)".
But when I run the search again, I get the same results. When I open the
concerning file, and click "Replace All", the replace goes just fine.
Also, turns out it's possible to click on "n replacements made ...", which
makes it blue. Does this serve a purpose?
– Koen
Sent from [Nylas N1](https://link.nylas.com/link/33wd9n5m5l3cdcz4d1oikbwcz
/local-58ab6731-da97/0?redirect=https%3A%2F%2Fnylas.com%2Fn1%3Fref%3Dn1&r=dGV4
dG1hdGVAbGlzdHMubWFjcm9tYXRlcy5jb20=), the extensible, open source mail
client.
I got used to being able to write short documents in Markdown, preview and then print to PDF. However, this seems to be broken now. I can preview fine, but printing to PDF (or opening in preview) causes Textmate to crash. Is this a bug, or something I’ve done wrong?
Thanks
João
I like the new feature in v2.0-beta.11.10 where targeted settings for
untitled files use file patterns that match the file's directory. It does
not, however, seem to pick up the fileType setting.
Would be nice to specify that new files created in various directories in
the project each have a given fileType based on their location.
I just started TextMate and it prompted me to install this new version 2.0
beta 12. That's all great. But I'd like to know what changed from the
previous version. I've looked at the various TextMate places (textmate.org
and github) but can't find any kind of list of "what changed" in the new
version, and not even a list of issues that got closed.
Just curious because TextMate is a great tool that I rely on and I'd like
to know what's going on.
I’m currently working on adding some new features to the D bundle. These are features like code completion, go-to-definition and similar features. These commands are using a parser tool which expects the current cursor position in bytes from the start of the source file. TextMate only provides the cursor position in the form of column and line number. This requires the commands to convert to and from cursor position in bytes to cursor position in column/line number. Is this information something that TextMate already has and can provide or, if not, provide it in a more efficient way then the conversion performed by the command?
I would also need to be able to specify the cursor position in bytes using the “mate” tool. I’ve also looked at the implementation of the Go bundle for the same commands and it has the same issue.
—
/Jacob Carlborg
