It could be that the application in question is busylooping until it receives the MapNotify event. Perhaps for_window [class="Emacs"] move to workspace 2, workspace 2, workspace back_and_forth works? (but it will flicker)
If so, file a bug upstream with the application(s) in question. On Mon, Apr 27, 2015 at 7:48 PM, Antonio-M. Corbi Bellot < antonio.co...@ua.es> wrote: > Hi all, > > I am currently using i3 version 4.10.2. > > Since a few months I've been observing a strange behaviour in i3 when I > assign a window from emacs or chromium to a specific workspace. The > behaviour I'm describing here was also the same with i3 4.[7,8,9].x. > > For example, I assign emacs to this key combination: > > bindsym $mod+Shift+m exec "emacs" > > And the workspace assignment is this: > > assign [class="Emacs"] 2 > > Assuming I'm working in workspace 1, when I press $mod+Shift+m (I don't > change to ws 2 for the moment), emacs starts in workspace 2 but I see > an increment in cpu usage being the main culprits emacs (approx. 60% > cpu usage) and xorg (approx. 90% cpu usage). And this cpu usage is > sustained...it doesn't slow down until I change to workspace 2 ($mod+2) > and then I observe that emacs hasn't finished starting and in the very > moment I've changed to workspace 2 it is like it resumes execution and > it finishes starting normally. It is then that cpu usage from xorg and > emacs slow down to their normal values. > > I've also observed this behaviour with chromium, no other applications > suffer from this 'strange' behaviour, i.e I use claws-mail in workspace > 4 and it opens there without a glitch. Also I use glade (3.18.1) in > this way, assigned to workspace 2, and it starts nicely. > > I'm not sure if it is an emacs/chromium bug or an i3 bug or even a xorg > bug, but I've observed it only with i3 and these applications. > > Has anyone observed this? > > Antonio Corbi. > -- Best regards, Michael
