headers
Lennart Borgman | 1 May 2010 01:22
Picon
Gravatar

Re: Add function to make frame topmost?

On Sat, May 1, 2010 at 12:32 AM, David De La Harpe Golden
<david <at> harpegolden.net> wrote:
> Stefan:
>>
>> I see, thanks.  I don't know if there's a word for such things
>> under X11 (I guess we should ask the freedesktop guys).
>
> Not affiliated with freedesktop as such, just familiar with specs:
>
> ITYM "Always on top" or "above other windows", or technically asking that
> _NET_WM_STATE include _NET_WM_STATE_ABOVE

Thanks.

> N.B. For "normal" windows (such as ordinary emacs frames), this is something
>  usually configured by the user via the window manager's menu, setting it
> within emacs for normal frames would not be something I would particularly
> want or need to do, though possible (*** below), and setting it for special
> framey things is not AFAIK a good idea (following):
>
> http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#STACKINGORDER
>
> [lennart]
>> My use case for something like this is reminders that pops up at a
>> certain times.
>
> Note that X11 apps (or more usually the gui toolkit the app uses) specify
> the purpose of the window in higher-level terms _NET_WM_WINDOW_TYPE, like
> "this is a tooltip", "this is a notification" _NET_WM_WINDOW_TYPE_TOOLTIP,
> _NET_WM_WINDOW_TYPE_NOTIFICATION
(Continue reading)

Permalink | Reply | 50 comments |
headers
Chong Yidong | 1 May 2010 03:41
Favicon

Next pretest (release candidate) May 3

The emacs-23 branch seems to have stabilized.  I propose to make the
final Emacs 23.2 pretest (23.1.97) next Monday, May 3.  This will be the
"release candidate"; after this, no more changes should be made to the
emacs-23 branch---unless a severe last-minute problem is discovered.
Barring that, we'll make the 23.2 release next Friday (May 7).
Permalink | Reply | 0 comments |
headers
David De La Harpe Golden | 1 May 2010 03:48

Re: Add function to make frame topmost?

>> ***
>> One can certainly do this from within emacs as per the spec (note you
>> do this for mapped windows by sending a client message to the root window).
>>  Note however, that window managers may refuse an app's request to be always
>> on top.
>>
>> (defun x-toggle-frame-always-on-top (&optional frame)
>>    (x-send-client-message
>>     frame 0 frame "_NET_WM_STATE" 32
>>     ;; _NET_WM_STATE_REMOVE = 0
>>     ;; _NET_WM_STATE_ADD = 1
>>     ;; _NET_WM_STATE_TOGGLE = 2
>>     '(2 "_NET_WM_STATE_ABOVE" 0 1)))
> 
> 
> Does this work already?

Yes, that's working code, on window managers that honour it.  But I 
don't actually recommend it for the purposes you wanted it for.

Would however be vaguely okay for people who don't want to reach for the 
mouse to use the relevant window manager menu.  If it were to be 
included in emacs it would make more sense to treat it as a frame 
parameter at the elisp api level, similar to the handling of several 
other similar existing parameters, i.e. so one could write

(set-frame-parameter frame 'always-on-top t)

(I think this was what Stefan was saying, pretty much)
(Continue reading)

Permalink | Reply | 40 comments |
headers
Lennart Borgman | 1 May 2010 04:06
Picon
Gravatar

Re: Add function to make frame topmost?

On Sat, May 1, 2010 at 3:48 AM, David De La Harpe Golden
<david <at> harpegolden.net> wrote:
>>> ***
>>> One can certainly do this from within emacs as per the spec (note you
>>> do this for mapped windows by sending a client message to the root
>>> window).
>>>  Note however, that window managers may refuse an app's request to be
>>> always
>>> on top.
>>>
>>> (defun x-toggle-frame-always-on-top (&optional frame)
>>>   (x-send-client-message
>>>    frame 0 frame "_NET_WM_STATE" 32
>>>    ;; _NET_WM_STATE_REMOVE = 0
>>>    ;; _NET_WM_STATE_ADD = 1
>>>    ;; _NET_WM_STATE_TOGGLE = 2
>>>    '(2 "_NET_WM_STATE_ABOVE" 0 1)))
>>
>>
>> Does this work already?
>
> Yes, that's working code, on window managers that honour it.  But I don't
> actually recommend it for the purposes you wanted it for.

Thanks.

> Would however be vaguely okay for people who don't want to reach for the
> mouse to use the relevant window manager menu.  If it were to be included in
> emacs it would make more sense to treat it as a frame parameter at the elisp
> api level, similar to the handling of several other similar existing
(Continue reading)

Permalink | Reply | 39 comments |
headers
David De La Harpe Golden | 1 May 2010 04:10

Re: Add function to make frame topmost?

Lennart Borgman wrote:

 >
 > How does "Urgency" work? Is that appropriate for reminders? I would
 > prefer that to be a frame that pops up but does not get focus until
 > the user choosen it.
 >

A reminder sounds more like a notification than an urgent window.   But
n.b. the window type might still be the wrong level, I'm now vaguely
wondering if you might be wanting system tray balloon notifications for 
which there are typically high-level apis.

http://standards.freedesktop.org/systemtray-spec/systemtray-spec-0.1.html#balloon

(note that gtk then has its implementation/wrapper for systray support, 
GtkStatusIcon, i.e. an even higher level might be appropriate for 
toolkit-using emacs)

Ading systray support to emacs was discussed in the context
of daemon mode a while back, maybe it's worth another look now.
Permalink | Reply | 4 comments |
headers
Lennart Borgman | 1 May 2010 04:32
Picon
Gravatar

Re: Add function to make frame topmost?

On Sat, May 1, 2010 at 4:10 AM, David De La Harpe Golden
<david <at> harpegolden.net> wrote:
> Lennart Borgman wrote:
>
>>
>> How does "Urgency" work? Is that appropriate for reminders? I would
>> prefer that to be a frame that pops up but does not get focus until
>> the user choosen it.
>>
>
> A reminder sounds more like a notification than an urgent window.   But
> n.b. the window type might still be the wrong level, I'm now vaguely
> wondering if you might be wanting system tray balloon notifications for
> which there are typically high-level apis.
>
> http://standards.freedesktop.org/systemtray-spec/systemtray-spec-0.1.html#balloon

I am not sure that systray must be invovled here. Perhaps there are
some specification for just balloons as a notification style? That
could perhaps be integrated easier with Emacs frame, ie perhaps an
Emacs frame could look like a balloon.

> (note that gtk then has its implementation/wrapper for systray support,
> GtkStatusIcon, i.e. an even higher level might be appropriate for
> toolkit-using emacs)
>
> Ading systray support to emacs was discussed in the context
> of daemon mode a while back, maybe it's worth another look now.
>
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
David De La Harpe Golden | 1 May 2010 05:19

Re: Add function to make frame topmost?

Lennart Borgman wrote:

> The problem is that it is not powerful enough for things like menus of
> the type used by for company-mode or completion-ui (see EmacsWiki).

I'm not too familiar with either. I think the tooltip type window hint 
is indeed also used or abused for completion panel display by some 
non-emacs X11 apps (so says xprop). I don't now want to give too much 
weight to it - what emacs puts in and does with an X11 window that it 
tells the window manager is a tooltip is still pretty much up to emacs 
(of course currently emacs might currently only be allowing display of a 
string...)

 > What about having a
> function make-tooltip-type-frame?
>

Hmm. It _might_ make sense to allow it as an elisp-exposed emacs frame 
parameter.  e.g. for argument's sake

(make-frame '((disposition . tooltip))
(make-frame '((disposition . utility)))
etc.

Not sure "disposition" is the right word...

It would probably then also prove necessary to be able to specify 
override-redirect and wm-transient-for at the lisp level as frame 
parameters (though maybe the former could be implied - you're hardly not 
going turn on override-redirect if you're making a tooltip) - the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chong Yidong | 1 May 2010 05:23
Favicon

Proposal for DEL to delete the active region

Here is a proposal for DEL to delete the region when transient-mark-mode
is enabled.  DEL already does this in delete-selection-mode; the idea
here is to move this behavior into transient-mark-mode proper.

This involves getting rid of `mouse-region-delete-keys', moving
`delete-backward-char' from C to Lisp, and introducing a new variable
`delete-backward-char-delete-region'.  Its default value, t, means that
`delete-backward-char' will delete the active region.

Conceptually, this puts `delete-backward-char-delete-region' on the same
footing as other user commands that "act on the region" under Transient
Mark mode.  The additional benefit is getting rid of the
`mouse-region-delete-keys' hack, so that DEL does the same thing for all
active regions.

Something similar would be done with delete-char (not shown in this
patch), so that [delete] deletes active regions too.

Comments, and suggestions for different approaches, welcome.

*** lisp/simple.el	2010-04-28 15:18:37 +0000
--- lisp/simple.el	2010-05-01 03:12:28 +0000
***************
*** 837,842 ****
--- 837,891 ----
  	 (overlay-recenter (point))
  	 (recenter -3))))

+ (defcustom delete-backward-char-delete-region t
+   "If non-nil, `delete-backward-char' deletes active regions.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Lennart Borgman | 1 May 2010 05:49
Picon
Gravatar

Re: Add function to make frame topmost?

On Sat, May 1, 2010 at 4:32 AM, Lennart Borgman
<lennart.borgman <at> gmail.com> wrote:
>
> I am not sure that systray must be invovled here. Perhaps there are
> some specification for just balloons as a notification style? That
> could perhaps be integrated easier with Emacs frame, ie perhaps an
> Emacs frame could look like a balloon.

Looks like a lot of work to make an Emacs frame has a balloon shape,
at least on w32. The code for it is hidden in a window class and is
probably not meant to be combined with some other window class.
Permalink | Reply | 0 comments |
headers
dhruva | 1 May 2010 06:06
Favicon
Gravatar

Improving cscope support in emacs

Hello,
 I am trying to use cscope in emacs using the xcscope.el distributed along with cscope. It starts a cscope
process for each command which makes it very slow compared to vim. There is a line oriented mode for
interacting with a running cscope process which vim uses. This makes it real fast. There is an old
cscope.el which does use the line oriented mode and is fast but it is quite dated.
 I would like to know if others have their own tweaks or hacks on using cscope in emacs or plans to provide
native support to cscope like vim does (it is a build time option).

-dhruva

PS: Is this a wrong list to send this mail (should I be targeting cscope mailing lists)?
Permalink | Reply | 4 comments |

Gmane