raise-frame && open local files about emacs_chrome HOT 9 CLOSED

With regards to your first question I'm not sure what you mean. When the edit-server creates a frame it does use (raise-frame) to ensure it's visible. However I'm not sure if there is special magic for Carbon Emacs.

As far as your second suggestion I can see that being useful. However I don't think you'd need magic links. Certainly adding an option to trigger edits for the page source for file:// links should be easy. For web-pages it might be worth doing something with magic like TRAMP to translate a web address to the file to edit.

In future though please raise separate issues for logically separate problems.

from emacs_chrome.

Okay, sorry, so I'll relate to the first issue, and create another ticket for the second one.

I don't like creating new Emacs frames, I think a new buffer is all you need to edit some text, so when your edit-server does not create a new frame (per my config), I still want it to raise the current frame, obviously.

Thank you.

from emacs_chrome.

Ahh I see what you mean. The indentation was out of wack in the function hiding the broken logic. I've added a (raise-frame) call to edit-server-create-frame even when a new frame isn't created.

Can you test and let me know if that works for you?

from emacs_chrome.

re-opening, should of just hit comment button.

from emacs_chrome.

Just tested -- GNU Emacs 22.3.1 (i386-apple-darwin9.8.0, Carbon Version 1.6.0); Google Chrome 8.0.552.231 (Official Build 69188); Mac OS X 10.6.5 (10H574)

Unfortunately, it still doesn't work.

Moreover, I've tested it without (setq edit-server-new-frame nil), and it gives error in process filter: x-create-frame-with-faces: Sorry, this version can only handle one display (I have one display at the moment, so, this may not be your problem, but making raise-frame work is even more important now).

Cheers.

from emacs_chrome.

That's very odd. I wonder if this is a Carbon Emacs issue or an Emacs 22 issue as it works on my 23.2.1 on X. I'm assuming that the behaviour of (raise-frame) hasn't changed too much in the last few versions.

Can you check the help text (C-h f raise-frame) lists only the one optional parameter?

from emacs_chrome.

I've been using Carbon Emacs for quite a few years now, and it's always been fully compatible with other GNU Emacs distros.

Not only raise-frame's signature is the same, but as I said above, emacsclient --eval "(raise-frame)" does raise the current frame.

from emacs_chrome.

Sorry, just double-checked, it doesn't actually work, it's probably Carbon/osx issue still -- the command line raises the frame below the currently running app (but above all others). Well.. You may close the issue I guess. I should write to Carbon Emacs' author or try and switch to Aquamacs...

from emacs_chrome.

Well there have been work arounds added for Aquaemacs handling as it didn't like make-frame-on-display. If there is an equivalent to the X windows _NET_ACTIVE_WINDOW hack for MacOS it can be included.

from emacs_chrome.