[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: just-the-text Emacs frame

From: Ted Zlatanov
Subject: Re: just-the-text Emacs frame
Date: Fri, 10 Jun 2011 15:53:34 -0500
User-agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.50 (gnu/linux)

On Fri, 10 Jun 2011 11:57:37 -0700 chad <address@hidden> wrote: 

c> On Jun 10, 2011, at 9:28 AM, Ted Zlatanov wrote:

>> I did.  They claim it's necessary because other panels have a heart
>> attack when they get the keyboard input focus.  So the solution is to
>> configure it at the user level, since they can't match dock rules to
>> Emacs frames in general (I've asked for more help but it doesn't seem to
>> be a priority to the XMonad developers, and I don't know Haskell enough
>> to do this myself).
>> So unless I get further help, I'll just document that XMonad is not
>> perfect for Emacs docked strut frames and I'll provide mouse bindings to
>> most of the things in such frames, including a binding to pop their
>> buffer up in a normal frame.

c> It ought to be possible to cover this in the configurations; for years, my 
c> window managers thought that I ran programs named (from X's pov) 
c> RightEmacs, LeftEmacs, and MiniBuffer.

I understand, but there is no way to match "Emacs frames that want to be
a panel" unambiguously without making the window title static, and then
you have to put that title in your XMonad user configuration, which is
what I'm trying to avoid.  I need a way to tell XMonad is running, then
I can require static titles for dock panels under that WM alone.  I got
some hints from
and put the following in emacs-panel.el:

#+begin_src lisp
(require 'bindat)

(defmacro emacs-panel-x-property (prop window &optional type vec)
  `(x-window-property ,prop nil ,(or type "AnyPropertyType") ,window nil ,vec))

(defmacro emacs-panel-x-property-nullsepstringarray (prop window &optional type)
  `(split-string (emacs-panel-x-property ,prop ,window ,type) "\0" t))

(defmacro emacs-panel-x-property-u32r (prop window &optional type)
  `(let ((spec '((:v u32r)))
         (bin (emacs-panel-x-property ,prop ,window ,type)))
     (cdr-safe (assq :v (bindat-unpack spec bin)))))

(defun emacs-panel-wm-hints ()
  ;; ask the root window what window to query for the WM name
  (let* ((nqid (emacs-panel-x-property-u32r "_NET_SUPPORTING_WM_CHECK" 0))
         (name (emacs-panel-x-property "_NET_WM_NAME" nqid)))
    `((name ,name)
       ,@(emacs-panel-x-property-nullsepstringarray "_NET_DESKTOP_NAMES" 0))
       ,(emacs-panel-x-property-u32r "_NET_ACTIVE_WINDOW" 0))
       ,(emacs-panel-x-property-u32r "_NET_NUMBER_OF_DESKTOPS" 0))
       ,(emacs-panel-x-property-u32r "_NET_CURRENT_DESKTOP" 0)))))


=> ((name "xmonad") (desktop-names "ext" "db" "web" "emacs" "gnus") 
(active-window 48234572) (desktop-count 5) (current-desktop 4))

so I will be able to tell the user "hey, XMonad doesn't like docked
struts, but here's what you can do..."

c> I don't currently have a good way to test XMonad, and won't for a couple 
c> weeks at least.  If it helps, you could try to figure out what configuration 
c> awesome and metacity have that XMonad does not, probably with some 
c> judicious use of xprop.

Regardless of the X properties of a docked strut Emacs frame (outside of
the WM hints to make it docked and a strut, obviously), awesome and
metacity give it the keyboard input focus and XMonad doesn't, by design.

I didn't get the impression the XMonad developers were interested in
making an exception for Emacs, since to them it seems sufficient that
the user can configure the exception himself.  And perhaps it is.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]