In general, Mac applications that are expecting text input from the keyboard do not handle C-S combinations or C-digit combinations. Programs that work with control-shift combos (like anything running under X11) do so by handling key events as events, not character input. This is how they can differentiate between Tab and Ctrl-i, which both generate the same ASCII character. (You can read in detail how Lion (really Cocoa) handles key events if you really want to know.)
Historically (back in the Teletype days), there were only uppercase letters on the keyboard, and there were no caret (^) or underscore (_) characters on the keyboard (instead there were up-arrow and back-arrow). The shift key worked by toggling the 16's bit and the control key worked by zeroing the 64's bit of the 7-bit ASCII codes the keyboard produced.
What this means is that the control key had no effect for the 32 characters on the keyboard that already had their 64's bit set to zero (most of the non-alphabetic characters, including digits), and since the teletype was purposefully limited to upper-case letters only, the shift key had no effect on most of the alphabetic characters (and where it did have an effect, it produced a special character like @).
Additional weirdness was added in the migration to supporting lower-case text, as the control key combos were all typed without using the shift key but now the letter typed without using the shift key had changed, so the decision was to map control-lower-case to what had been control-upper-case. But then what do you do with control-shift?
For a while the problem was handled by having the control key also zero out the 32's bit, which is what differentiated lower case letters from upper case letters. But eventually ASCII was replaced with Unicode and those kinds of duplicate key assignments were too much of a waste of keyboard space to be allowed to continue, so they got different mappings, and on the standard Mac US keyboard most C-S combos are unassigned.
So what you have run into is the legacy support for keyboard input running back to Teletype days. The characters Terminal (and other OS X apps) do not support are characters you could not type on the Teletype keyboard. As evidence of this, note that C-S-2 (C-@), C-S-6 (C-^), and C-S-- (C-_) all work, because those keys have been re-mapped since the ASR-33, where S-2 was " (and @ was S-P), S-6 was &, and S-- was =, but in general control-shift combos do not produce characters of any kind.
I've gotten at least a usable approach, tho not perfect.
The best I could do is the following:
1) don't ever use emacsclient and take start server out of init.el
2) in mission control preferences, uncheck the boxes for "when switching to an application..." and "group windows by application"
If I am editing more than one doc, in different desktops I end up with more than one instance of emacs running, but I can live with this. Also, the startup seems to be fast enough for me without emacsclient.
It doesn't look like cocoa emacs is impemented as a document based cocoa app. Is that the case?
Seems like Macvim handles the multiple document without multiple instance case more gracefully.
Best regards.
JRV
Best Answer
The problem you are having is a constant for Emacs. It's due to Emacs relying on a couple of things that are set in a
bashshell that aren't available in the GUI.The most notable of these is the PATH variable. That's why pdflatex isn't being found.
Check https://www.emacswiki.org/emacs/EmacsApp for a better explanation and some things you can do to make it easier.