[Xquartz-dev] 2.3.0 rc4
zt4q4o402 at sneakemail.com
Mon Jun 16 15:02:47 PDT 2008
Just in case it helps: I believe I saw something similar a while ago
using pwm in an Xnest window, too. If I ran pwm (window manager) from
my .xinitrc, hotkeys (meta-E for an xterm, for example) didn't work,
but if I waited and ran pwm from the xterm that was automatically
started, hotkeys worked as expected. I thought it was just Xnest being
weird, then forgot to follow up on this list (sorry!).
On Mon, Jun 16, 2008 at 5:31 PM, Peter Collinson pc-at-hillside.co.uk
|Xquartz-dev/personal| <...> wrote:
> Here's another side effect of the change - which I have worked around,
> so I can work, and don't really understand.
> If I have a application menu entry
> Terminal => xterm -vb -lc -sb -sl 5000
> The xterm starts and seems OK. However if I use:
> emacs -nw
> I find that Control-O is apparently not working. Emacs is not actually
> seeing it, if I type describe-key ^O into emacs nothing happens. I
> have ^O bound to 'Command open-line'. Emacs in this case is version
> 22.2.1 from macports - although I've not recompiled it against the new
> libraries with 2.3.0 rc4.
> I also get redraw problems in the terminal, as if the terminfo isn't
> working quite correctly - bits of the Emacs minibuffer 'go missing'-
> somewhat as if the terminal is not configured correctly for the
> command sequence it's getting. The terminal type is xterm-color.
> If I start an xterm from this xterm - the sub-shell xterm runs Emacs
> impeccably. This is weird - both the terminals started by X and the
> one started by hand appear to have the same environment and stty
> Well I notice that the xterms are running with luit - well it seems
> that one started by X is - the one I started by hand isn't. I presumed
> that the one started by hand is affected by the locale code in my
> startup sequence - and essentially things are solved by inserting
> locale setting code before calling /usr/X11/bin/xterm - which is what
> uxterm does. So changing the menu setting to call uxterm is the
> solution - except that it doesn't obey my Xresources which talks about
> I've worked around things by adapting the uxterm script into a private
> xterm program.
> On 15 Jun 2008, at 06:12, Jeremy Huddleston wrote:
>> That's right, and it will continue to be that way. The PATH inherited
>> by the application isn't being altered by your .profile. The .app is
>> now (correctly) getting the same environment that any other apps get.
>> Google for environment.plist
>> On Jun 14, 2008, at 12:11, Peter Collinson wrote:
>>> There seems to be a change from previous behaviour - (nearly) all
>>> the commands in my Applications menu have stopped working.
>>> Most are calls to shells scripts in my ~/bin... and so it looks as
>>> if the code has stopped respecting my private PATH. The command
>>> that's working calls xterm - so it's picking up the default PATH.
>>> Sorry if this has been flagged before.
>>> Peter Collinson
>>> Xquartz-dev mailing list
>>> Xquartz-dev at lists.macosforge.org
>> Xquartz-dev mailing list
>> Xquartz-dev at lists.macosforge.org
> Xquartz-dev mailing list
> Xquartz-dev at lists.macosforge.org
Henny Youngman - "When I told my doctor I couldn't afford an
operation, he offered to touch-up my X-rays."
More information about the Xquartz-dev