[Xquartz-dev] 2.3.0 rc4

Brian Bender 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!).

 - Brian

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
> settings.
>
> 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
> Xterms..
>
> 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
>>
>> --Jeremy
>>
>> 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.
>>>
>>> Regards
>>> _____________________________________________
>>> Peter Collinson
>>>
>>>
>>>
>>> _______________________________________________
>>> Xquartz-dev mailing list
>>> Xquartz-dev at lists.macosforge.org
>>> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
>>
>> _______________________________________________
>> Xquartz-dev mailing list
>> Xquartz-dev at lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
>
> _______________________________________________
> Xquartz-dev mailing list
> Xquartz-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
>



-- 
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 mailing list