Emacs as a desktop environment

Emacs as a desktop environment

[Ted Zlatanov]

I've been very frustrated lately with the memory and resource use of
gnome-panel, XFCE, and the new Unity UI in Ubuntu 11.04.  They use
multiple megabytes of memory for trivial things; they are slow, and they
make a machine with 3 GB of RAM feel slow just doing trivial things.

I think GNU Emacs, at least on GNU/Linux systems, can provide much of
the desktop environment functionality, so Emacs + a window manager like
XMonad is a full desktop experience:

- launch bar: a place to put icons associated with a program (simple toolbar)

- Applications, Places, and System menus: not sure how to connect those

- load indicators (CPU, memory, network load, etc.): can be done with SVG

- date, weather, market indicators: SVG and/or plain text

- workspace indicator: needs to talk to the window manager

- all file management: Dired

- icon dock for application and system indicators

I'd like to know how much of this can be achieved with today's GNU Emacs
plus the external packages (GNU ELPA, Tom Tromey's ELPA, EmacsWiki,
etc.) available, and how much will require new packages or changes to
Emacs' internals.

Thanks
Ted

Re: Emacs as a desktop environment

[joakim]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I've been very frustrated lately with the memory and resource use of
> gnome-panel, XFCE, and the new Unity UI in Ubuntu 11.04.  They use
> multiple megabytes of memory for trivial things; they are slow, and they
> make a machine with 3 GB of RAM feel slow just doing trivial things.
>
> I think GNU Emacs, at least on GNU/Linux systems, can provide much of
> the desktop environment functionality, so Emacs + a window manager like
> XMonad is a full desktop experience:
>
> - launch bar: a place to put icons associated with a program (simple toolbar)
>
> - Applications, Places, and System menus: not sure how to connect those
>
> - load indicators (CPU, memory, network load, etc.): can be done with SVG
>
> - date, weather, market indicators: SVG and/or plain text
>
> - workspace indicator: needs to talk to the window manager
>
> - all file management: Dired
>
> - icon dock for application and system indicators
>
> I'd like to know how much of this can be achieved with today's GNU Emacs
> plus the external packages (GNU ELPA, Tom Tromey's ELPA, EmacsWiki,
> etc.) available, and how much will require new packages or changes to
> Emacs' internals.

You can have a look at the Xembed branch. Its not functional ATM but the
README describes it pretty well I think. What its supposed to do is
allow embedding of applications inside Emacs. Then you wouldn't need a
WM at all :)

I've also been wanting to rewrite the SVG support to use the Cairo
renderer. The current 2 renderers both wind up in librsvg and generate
bitmaps that gets copied a lot. So its slow and memory intensive which
it doesn't havoc to be if you look at Inkscape for instance. This would
also be much simpler if I could get the Xembed branch to work well. The
last thing I was going to do before life stalled me indefinitely was to
allow for a simplified embedding that was owned by a single emacs
window. That should be pretty robust I think and does not exclude the
more advanced possibilities of the branch.



>
> Thanks
> Ted
>

-- 
Joakim Verona

Re: Emacs as a desktop environment

[Ted Zlatanov]

On Wed, 25 May 2011 09:31:24 +0200 joakim@verona.se wrote: 

j> Ted Zlatanov <tzz@lifelogs.com> writes:

>> I've been very frustrated lately with the memory and resource use of
>> gnome-panel, XFCE, and the new Unity UI in Ubuntu 11.04.  They use
>> multiple megabytes of memory for trivial things; they are slow, and they
>> make a machine with 3 GB of RAM feel slow just doing trivial things.
>> 
>> I think GNU Emacs, at least on GNU/Linux systems, can provide much of
>> the desktop environment functionality, so Emacs + a window manager like
>> XMonad is a full desktop experience:
>> 
>> - launch bar: a place to put icons associated with a program (simple toolbar)
>> 
>> - Applications, Places, and System menus: not sure how to connect those
>> 
>> - load indicators (CPU, memory, network load, etc.): can be done with SVG
>> 
>> - date, weather, market indicators: SVG and/or plain text
>> 
>> - workspace indicator: needs to talk to the window manager
>> 
>> - all file management: Dired
>> 
>> - icon dock for application and system indicators
>> 
>> I'd like to know how much of this can be achieved with today's GNU Emacs
>> plus the external packages (GNU ELPA, Tom Tromey's ELPA, EmacsWiki,
>> etc.) available, and how much will require new packages or changes to
>> Emacs' internals.

j> You can have a look at the Xembed branch. Its not functional ATM but the
j> README describes it pretty well I think. What its supposed to do is
j> allow embedding of applications inside Emacs. Then you wouldn't need a
j> WM at all :)

I'm not trying to get rid of the window manager, though several of the
indicators and applets could be written externally and use such
embedding instead of the native Emacs UI.

j> I've also been wanting to rewrite the SVG support to use the Cairo
j> renderer.

That would be nice, indeed.

On Wed, 25 May 2011 08:44:42 +0200 Frank Schmitt <ich@frank-schmitt.net> wrote: 

FS> I felt very much the same and am now using LXDE which is really pretty
FS> nice in my opinion. You might want to give it a try.

Does it provide the things I listed?  Does it integrate well with the
Gnome and Ubuntu system and application menus?

On Wed, 25 May 2011 10:38:53 +0200 Geoffrey Teale <tealeg@member.fsf.org> wrote: 

GT> There is at least one Emacs based window manager out there, though as
GT> I recall it's more for Xemacs than GNU Emacs.  I forget the name, but
GT> a quick search would find it I am sure.

I'm not suggesting to replace the window manager.  That piece has been
pluggable in X for decades so if Emacs can do it, great, but it's not a
resource hog like the other things I listed so it's less of a concern.

GT> For me the biggest issue with Emacs used in this way is that some
GT> tools block and would lock you out from doing things while they do.
GT> Prime example is GNUS - I use two emacs processes in normal operation,
GT> one for GNUs and one for everything else.  I'd love that not to be the
GT> case.

Yes, concurrency will help, but I don't mind launching multiple Emacs
instances to handle the various tasks I listed.

On Wed, 25 May 2011 10:52:27 +0200 Thien-Thi Nguyen <ttn@gnuvola.org> wrote: 

TN> You are not alone!  Here, Emacs + RPX (ratpoison clone in Scheme) + 512MB
TN> => no worries.

TN> My needs are simpler, however:
TN> [launch bar] No need!

Hmm, I find it useful.  It's not essential (dmenu can do it all for
instance) but certainly it's not useless.

TN> [Applications, Places, and System menus] No need!

That's often the only way to find an application.

TN> [load indicators] No need!  OK, "urxvt -e top" works, too.

TN> [date, weather, market indicators] No need!

TN> [workspace indicator] All in the mind.  Or, "work? what's that?
TN> space? nice place!".

I disagree, those are necessary.

TN> [icon dock] No need!

That's necessary for some applications and indicators, e.g. network
connection status.  It's not essential.

TN> What do you think of:
TN>   http://www.emacswiki.org/emacs/XWindowEmacsManager

I think it's not the component I'm looking for.

Ted

Re: Emacs as a desktop environment

[PJ Weisberg]

On Wednesday, May 25, 2011, Ted Zlatanov <tzz@lifelogs.com> wrote:
> On Wed, 25 May 2011 09:31:24 +0200 joakim@verona.se wrote:
> TN> [load indicators] No need!  OK, "urxvt -e top" works, too.
>
> TN> [date, weather, market indicators] No need!
>
> TN> [workspace indicator] All in the mind.  Or, "work? what's that?
> TN> space? nice place!".
>
> I disagree, those are necessary.

Most of those are a waste of space, except for date/time, which is essential.

In other words, everything you could possibly get rid of is going to
be a deal-breaker for some users.  It may be true that no one uses
more than 20% of the features, but everyone uses a *different* 20%.

http://www.joelonsoftware.com/articles/fog0000000020.html

-- 

-PJ

Re: Emacs as a desktop environment

[Ken Raeburn]

On May 24, 2011, at 21:05, Ted Zlatanov wrote:
> I've been very frustrated lately with the memory and resource use of
> gnome-panel, XFCE, and the new Unity UI in Ubuntu 11.04.  They use
> multiple megabytes of memory for trivial things; they are slow, and they
> make a machine with 3 GB of RAM feel slow just doing trivial things.
> 
> I think GNU Emacs, at least on GNU/Linux systems, can provide much of
> the desktop environment functionality, so Emacs + a window manager like
> XMonad is a full desktop experience:

I've been experimenting with doing more inside Emacs at work, since I've been coming back to more Linux desktop use but had grown unfamiliar with the latest flavors of various apps and document/file viewers in the latest desktop environments.  I'd like to move more in that direction, too.  Some of the stuff I've found handy for this with modern Emacs:

* Basic spreadsheet application: ses mode

* Screen (or VNC, sort of): emacsclient and daemon mode (but don't build for gtk!)

* Remote login windows: ssh mode, though it could use some updates for ssh multiplexing and better tramp interaction

* Log monitoring window ("tail -f"): auto-revert-mode

* Chat program: emacs-jabber mode

* image viewer: C-x C-f

The emacs-jabber mode was already packaged and installed at work; ssh mode I found via Google.

I still go to external programs for lots of tasks, though:

* viewing .doc files, editing/viewing spreadsheets from others, making presentation slides (OpenOffice); not very common, so not a big deal

* PDF viewing (??? whatever the desktop manager launches for these); Emacs can do it by converting to images, but AFAIK it doesn't support links within the document (click on this entry in the table of contents to jump to that page), and sometimes when I'm skimming documents I want to zip through the pages *really* fast, getting glimpses of each as I go (e.g., so I can see where I am in the alphabetically ordered reference section by the titles), and Emacs isn't fast enough

* general web browsing (firefox/iceweasel); yes, there's w3 mode, and I haven't looked at it in a long time, but the last update to the git repo on gnu.org was three years ago, and it seems like it'd be insufficient these days unless it's got Java and Javascript and Flash and TLS and certificate management and video and (etc); well, maybe not video or Flash much for work specifically

* email, shared calendar, address book (Zimbra server, via iceweasel)
  ** email via Gnus IMAP support is okay, but there's a timeout problem in 23.3, probably fixed in the trunk
  ** calendar interface supports some network protocols (e.g., for Apple's iCal)
  ** meeting scheduling seems to involve getting email and then clicking "accept" or "decline" in the webmail view, and then the calendar is updated; it may be doable through calendar protocols alone
  ** address book I don't care about too much, so far, but it'd be a plus

* long CLI-oriented sessions (gnome-terminal, but I should look at comint's support for automatic truncation)

* bug tracking (Jira server, via iceweasel); and whaddaya know, Google points me to the JiraMode node at EmacsWiki, hmm...


Usually iceweasel turns out to be the memory pig on my system, but I wind up needing it for a bunch of things.

Multithreading in Emacs is sorely lacking; really, having my log viewer and ssh windows freeze, because my spreadsheet is being recomputed or I'm loading a really big file from a slow file server, just isn't acceptable behavior for a desktop environment.  Neither is confining everything I do to one core's worth of processing power on modern multicore systems.

So I suspect I'm going to be stuck with at least OO, iceweasel, and gnome-terminal for a while yet.

> - load indicators (CPU, memory, network load, etc.): can be done with SVG

Ooh, this sounds interesting...

Ken

Re: Emacs as a desktop environment

[Tom Tromey]

Ken> * viewing .doc files, editing/viewing spreadsheets from others,
Ken> making presentation slides (OpenOffice); not very common, so not a
Ken> big deal

I do presentations in Emacs using epresent.el.
It is primitive but more than sufficient for my purposes; YMMV.

Ken> * general web browsing (firefox/iceweasel); yes, there's w3 mode,
Ken> and I haven't looked at it in a long time, but the last update to
Ken> the git repo on gnu.org was three years ago, and it seems like it'd
Ken> be insufficient these days unless it's got Java and Javascript and
Ken> Flash and TLS and certificate management and video and (etc); well,
Ken> maybe not video or Flash much for work specifically

I think Emacs will never be an excellent web browser, but for some
specific things (e.g., Gtk documentation or Bugzilla), I use w3m and a
local setting for browse-url-browser-function that picks what viewer to
use depending on the URL.

Ken> Multithreading in Emacs is sorely lacking; really, having my log
Ken> viewer and ssh windows freeze, because my spreadsheet is being
Ken> recomputed or I'm loading a really big file from a slow file
Ken> server, just isn't acceptable behavior for a desktop environment.

My progress on this is much slower than I'd like :-(

Tom

Re: Emacs as a desktop environment

[Evans Winner]

,------ Ken Raeburn wrote ------
|    emacsclient and daemon mode (but don't build for gtk!)

I use this functionality every day (in fact, I'm writing
this on a tunneled Emacs right now).  I am wondering why you
say not to compile with GTK?  Is it just because it is
slower that generic X over ssh?  I never thought to compile
without GTK.  I find it pretty snappy on my local network at
home, but a it is indeed a bit slow when I connect from
elsewhere through the house DSL connection.  How would you
recommend compiling?  I do use doc-view over ssh quite a
lot, so I need X functionality but nothing particularly
fancy beyond that.

Re: Emacs as a desktop environment

[Lennart Borgman]

Would not a lot more people gain from a better Gnome than from a
better Emacs desktop?

Re: Emacs as a desktop environment

[David Kastrup]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> Would not a lot more people gain from a better Gnome than from a
> better Emacs desktop?

A lot more people would gain from a better Thunderbird than from a
better Emacs desktop.

Let them improve it for all I care.  I'll still not use it rather than
Emacs for dealing with my mail.  Why should Emacs developers bother
about Gnome?

-- 
David Kastrup

Re: Emacs as a desktop environment

[Lennart Borgman]

On Thu, May 26, 2011 at 12:15 AM, David Kastrup <dak@gnu.org> wrote:
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>
>> Would not a lot more people gain from a better Gnome than from a
>> better Emacs desktop?
>
> A lot more people would gain from a better Thunderbird than from a
> better Emacs desktop.
>
> Let them improve it for all I care.  I'll still not use it rather than
> Emacs for dealing with my mail.  Why should Emacs developers bother
> about Gnome?

Because developers time is a scarce resource.

Re: Emacs as a desktop environment

[Christophe Poncy]

On 05/25/2011 11:58 PM, Lennart Borgman wrote:
> Would not a lot more people gain from a better Gnome than from a
> better Emacs desktop?
>
>

I generally use Funtoo GNU/Linux with OpenBox. There's some Gnome 
dependencies, but not too much. Not everybody are using Gnome, some 
Emacs users prefer light desktops. Increasing those dependencies is a 
bad thing for them.

Sorry to be off topic but Steve Yegge talked about the future of Emacs 
three years ago, I found his post rather brilliant, especially the 
"Emacs/Firefox integration", I always wondered what Emacs developers are 
thinking about this:
http://steve-yegge.blogspot.com/2008/04/xemacs-is-dead-long-live-xemacs.html

Re: Emacs as a desktop environment

[Ken Raeburn]

On May 25, 2011, at 15:26, Evans Winner wrote:
> ,------ Ken Raeburn wrote ------
> |    emacsclient and daemon mode (but don't build for gtk!)
> 
> I use this functionality every day (in fact, I'm writing
> this on a tunneled Emacs right now).  I am wondering why you
> say not to compile with GTK?

The GTK code is, apparently, rather poor at supporting multiple displays.  It'll work some of the time, but sometimes -- I forget; maybe when a display goes away unexpectedly -- it'll break.  I got the impression (that other people had gotten the impression) that it wasn't an issue that was getting much attention from the GTK folks.

>   How would you
> recommend compiling?

I use "--with-x-toolkit=lucid", and haven't had any problems.

Ken

Re: Emacs as a desktop environment

[Stefan Monnier]

> goes away unexpectedly -- it'll break.  I got the impression (that other
> people had gotten the impression) that it wasn't an issue that was getting
> much attention from the GTK folks.

I don't know if that's the case, but at least it's the impression I get
from the fact that the bug has been known and reported several years ago
but still doesn't seem to be fixed.  Maybe if more people add their
voice to the gtk bug-report it will get more attention.


        Stefan

Re: Emacs as a desktop environment

[Ulrich Mueller]

>>>>> On Wed, 25 May 2011, Ken Raeburn wrote:

> The GTK code is, apparently, rather poor at supporting multiple
> displays.  It'll work some of the time, but sometimes -- I forget;
> maybe when a display goes away unexpectedly -- it'll break.

If the connection is forcibly closed (e.g. when the X server is
terminated) then Emacs will crash. It's a bug in GTK+ that is open
since 2002:
<https://bugzilla.gnome.org/show_bug.cgi?id=85715>

There are several bugs related to this in the Emacs bug tracker too,
for example <http://debbugs.gnu.org/cgi-bin/bugreport.cgi?bug=4078>.

> I got the impression (that other people had gotten the impression)
> that it wasn't an issue that was getting much attention from the GTK
> folks.

There hasn't been much activity on the GTK+ bug in the last 5 years.
I really wonder why they aren't interested in fixing this.

>> How would you recommend compiling?

> I use "--with-x-toolkit=lucid", and haven't had any problems.

At Gentoo there were already discussions if we should change the
default toolkit of the Emacs package from GTK+ to Lucid, because of
this bug.

Ulrich

Re: Emacs as a desktop environment

[Stephen J. Turnbull]

Ulrich Mueller writes:

 > There hasn't been much activity on the GTK+ bug in the last 5 years.
 > I really wonder why they aren't interested in fixing this.

Why wonder?  You obviously "do" free software, you *could* fix it
(possibly at very high cost to yourself[1]).  If you don't care enough
to fix it yourself, is it really that surprising that they don't?
Clearly, they itch there even less than you do, so they're scratching
something else.

<topical state="on">
Kudos to the Emacs community for caring so much about That Other Guy's
Bugs, and fixing them!
</topical>

Footnotes: 
[1]  Although sometimes it's surprisingly easy.  AFAIK X.org's
"nonblocking mode" _XtWaitForSomething() still can block.  But it took
me less than 15 minutes to interrupt the infloop, locate that function
in the gdb backtrace, download the source, trace the code and realize
there were a minimum of two ways to block in that loop, and verify it.
Another ten minutes to find out where to submit a patch that fixed
both for my purposes, and do it.  I guess the patch was suboptimal;
AFAIK it never was applied. :-/  MacPorts fixed the problem in their
build of Xlib by using select() instead of poll(), so I don't much
care any more.

Hell, I wouldn't even be surprised if the GTK+ bug is related to this
one, since in both cases you're multiplexing on fds.  I wouldn't bet
you can find that relationship in 15 minutes, though. :-)

Re: Emacs as a desktop environment

[Nix]

On 27 May 2011, Stephen J. Turnbull spake thusly:
> [1]  Although sometimes it's surprisingly easy.  AFAIK X.org's
> "nonblocking mode" _XtWaitForSomething() still can block.

If this was in the last few years, I suspect it was never applied
because the X.org people really didn't care much about the old-style
Xlib: stability mattered much more for it than fixes to non-critical
bugs, given that the medium-term plan was to ditch the entire networking
and protocol layer of Xlib and migrate to XCB. These days (Xlib 1.4.x+),
everything goes through XCB, and a huge number of bugs have simply
vanished as a result. I strongly suspect that this is one of them.

-- 
NULL && (void)

Re: Emacs as a desktop environment

[Thien-Thi Nguyen]

() Nix <nix@esperi.org.uk>
() Sat, 28 May 2011 01:09:33 +0100

   These days (Xlib 1.4.x+),
   everything goes through XCB, and a huge number of bugs have simply
   vanished as a result. I strongly suspect that this is one of them.

So i guess it would behoove Emacs to move to XCB as well?

Re: Emacs as a desktop environment

[Nix]

On 28 May 2011, Thien-Thi Nguyen spake thusly:

> () Nix <nix@esperi.org.uk>
> () Sat, 28 May 2011 01:09:33 +0100
>
>    These days (Xlib 1.4.x+),
>    everything goes through XCB, and a huge number of bugs have simply
>    vanished as a result. I strongly suspect that this is one of them.
>
> So i guess it would behoove Emacs to move to XCB as well?

It's using higher-level toolkits. It's their job to move to XCB, really.
XCB's primary benefit (other tham simplicity) is that it exposes the
asynchronous nature of the X protocol, and since Emacs is notably not
asynchronous, I'm not sure how much it would benefit.

(The huge number of bugs that vanished from Xlib when Xlib moved to XCB
will also of course no longer trouble clients of Xlib.)

-- 
NULL && (void)

Re: Emacs as a desktop environment

[David De La Harpe Golden]

On 28/05/11 11:44, Nix wrote:

> It's using higher-level toolkits.

Sortof. gtk+ emacs is a actually a mix of toolkit and direct xlib calls, 
for a variety of reasons, some good, some just historical.  A "pure 
gtk+" (or at least "pure gtk+ and probably cairo and stuff") emacs would 
be a possibility, but AFAIK a currently hypothetical one, and a lot of 
work for dubious return (especially since longstanding gtk+ rather than 
emacs bugs like the famous "closing display? hey, let's kill everything" 
and "hey, don't tell us how scrollbars work" presumably wouldn't go away).

AFAIUI the main thing really stalling wholesale movement to xcb and 
retirement of xlib in general is the absence of an xlib-free replacement 
for GLX. Right now, if an x11 app/toolkit/canvas ever wants to use 
accelerated opengl rendering (and "everyone" wants those fancy 3d 
effects these days...), it /must/ link to xlib (even if xlib itself is 
sitting on top of xcb) - see writeup here:

http://xcb.freedesktop.org/opengl/

(note as the link explains xcb-glx is not sufficient, it's only part of 
the puzzle).  Work on removing the xlib dependency for opengl apps seems 
to proceed in fits and starts, typically coincidental with GSoC projects...

Re: Emacs as a desktop environment

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 1213 bytes --]

On Sat, May 28 2011, David De La Harpe Golden wrote:

> AFAIUI the main thing really stalling wholesale movement to xcb and
> retirement of xlib in general is the absence of an xlib-free replacement for
> GLX. Right now, if an x11 app/toolkit/canvas ever wants to use accelerated
> opengl rendering (and "everyone" wants those fancy 3d effects these
> days...), it /must/ link to xlib (even if xlib itself is sitting on top of
> xcb) - see writeup here:
>
> http://xcb.freedesktop.org/opengl/
>
> (note as the link explains xcb-glx is not sufficient, it's only part of the
> puzzle).  Work on removing the xlib dependency for opengl apps seems to
> proceed in fits and starts, typically coincidental with GSoC projects...

This is less true :-) if you can rely on the Xlib version you'll use
being XCB-enabled.
Then you can use Xlib to connect to the display and call
XGetXCBConnection(3) to get the connection to the display in its XCB
form.

This allows to fake the usage of Xlib while still doing real things with
XCB.

I ported startup-notification to XCB (which does not uses OpenGL but
provides an Xlib API) this way last year.

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: Emacs as a desktop environment

[Nix]

On 25 May 2011, Ken Raeburn spake thusly:

>   ** address book I don't care about too much, so far, but it'd be a plus

This sort of thing is exactly what BBDB is for. You do need an
additional keybinding, though:

(define-key message-minibuffer-local-map (kbd "<tab>") 'bbdb-complete-name)

-- 
NULL && (void)

Re: Emacs as a desktop environment

[Ken Raeburn]

On May 25, 2011, at 18:08, Nix wrote:
> On 25 May 2011, Ken Raeburn spake thusly:
> 
>>  ** address book I don't care about too much, so far, but it'd be a plus
> 
> This sort of thing is exactly what BBDB is for. You do need an
> additional keybinding, though:

I'd probably want to use the data (whether by syncing to BBDB or accessing directly) that's in the Zimbra address book for my account, though.

On my home system, I'd definitely want what's in the Mac Address Book app, which other software keeps in sync with my phone and laptop.  Or at MIT, maybe what's in the LDAP server with MIT-wide account info.  Or, I expect, a lot of people would want contact lists already maintained in their Google accounts to be used.  Etc.  Maybe EUDC has some of what I want...

Ken

Re: Emacs as a desktop environment

[joakim]

Ken Raeburn <raeburn@raeburn.org> writes:

> On May 25, 2011, at 18:08, Nix wrote:
>> On 25 May 2011, Ken Raeburn spake thusly:
>> 
>>>  ** address book I don't care about too much, so far, but it'd be a plus
>> 
>> This sort of thing is exactly what BBDB is for. You do need an
>> additional keybinding, though:
>
> I'd probably want to use the data (whether by syncing to BBDB or accessing directly) that's in the Zimbra address book for my account, though.
>
> On my home system, I'd definitely want what's in the Mac Address Book app, which other software keeps in sync with my phone and laptop.  Or at MIT, maybe what's in the LDAP server with MIT-wide account info.  Or, I expect, a lot of people would want contact lists already maintained in their Google accounts to be used.  Etc.  Maybe EUDC has some of what I want...
>
> Ken

We appear to now have 3 or 4 emacs address books.
- org-contacts
- abook

- 2 bbdb variants

While bbdb is the most mature it can't be included in Emacs AFAICS.
org-contacts is comming along and could possibly be a part of
org and thus included in Emacs. abook stores data in vcards which is
good for interoperability. I think we should get these into ELPA but
this would be the topic for another thread.


-- 
Joakim Verona

Re: Emacs as a desktop environment

[Thierry Volpiatto]

joakim@verona.se writes:

>
> We appear to now have 3 or 4 emacs address books.
> - org-contacts
> - abook
>
> - 2 bbdb variants
>
> While bbdb is the most mature it can't be included in Emacs AFAICS.
> org-contacts is comming along and could possibly be a part of
> org and thus included in Emacs. abook stores data in vcards which is
> good for interoperability. I think we should get these into ELPA but
> this would be the topic for another thread.

FYI emacs-bookmark-extension have his own addressbook linked to emacs bookmarks.

http://mercurial.intuxication.org/hg/emacs-bookmark-extension/

I use it everyday, it provide also completion in message buffers.

You will find also the anything source in anything-config.el.

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

BBDB in the GNU ELPA (was: Emacs as a desktop environment)

[Ted Zlatanov]

On Thu, 26 May 2011 09:27:05 +0200 joakim@verona.se wrote: 

j> While bbdb is the most mature it can't be included in Emacs AFAICS.

It's on my TODO list to look through the BBDB 3.0 Git repository on
Savannah and track down all the contributors for the current source, get
papers from them, and then put BBDB on the GNU ELPA.  Apologies to
everyone who's waiting on me for this, especially Roland Winkler, the
current BBDB maintainer, who's been very patient.

If anyone wants to help with this task, it would be greatly appreciated.
It's not hard work, just time-consuming and I haven't found the time.

Thanks
Ted

Re: BBDB in the GNU ELPA

[Glenn Morris]

Ted Zlatanov wrote:

> It's on my TODO list to look through the BBDB 3.0 Git repository on
> Savannah and track down all the contributors for the current source, get
> papers from them, and then put BBDB on the GNU ELPA.

Do you have a realistic expectation of getting an assignment from (or
rewriting every contribution of) the original author, jwz?

Re: BBDB in the GNU ELPA

[Stephen J. Turnbull]

Glenn Morris writes:
 > Ted Zlatanov wrote:
 > 
 > > It's on my TODO list to look through the BBDB 3.0 Git repository on
 > > Savannah and track down all the contributors for the current source, get
 > > papers from them, and then put BBDB on the GNU ELPA.
 > 
 > Do you have a realistic expectation of getting an assignment from

Asked sufficiently politely, I have 1000 yen that says you'll get it.

*All* of Jamie's lemacs and xemacs code is assigned to the FSF, except
maybe that which is part of lwlib (via his contract with Lucid,
courtesy Richard P. Gabriel, but I've never heard him complain about
it, and I've given him several opportunities).  AFAIK he has nothing
personal against the current maintainership, either of BBDB or Emacs.

 > (or rewriting every contribution of) the original author, jwz?

There's some chance much of that has been done for BBDB 3 anyway.  If
Roland tells Jamie how much, it might improve your chances of getting
an assignment.

It might also amuse Jamie sufficiently if somebody actually sent him
the dollar.  (I *wanted* my dollar, damn it, and it never occurred to
me I wouldn't get it.  I would have happily sent a contribution of $25
by check :-) in return, but I would have framed the dollar I got for
the first, and only, software I've ever sold.)

Re: BBDB in the GNU ELPA

[Ted Zlatanov]

On Thu, 26 May 2011 19:12:58 -0400 Glenn Morris <rgm@gnu.org> wrote: 

GM> Ted Zlatanov wrote:
>> It's on my TODO list to look through the BBDB 3.0 Git repository on
>> Savannah and track down all the contributors for the current source, get
>> papers from them, and then put BBDB on the GNU ELPA.

GM> Do you have a realistic expectation of getting an assignment from (or
GM> rewriting every contribution of) the original author, jwz?

Yes.

Ted

Re: BBDB in the GNU ELPA

[Bernt Hansen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Thu, 26 May 2011 09:27:05 +0200 joakim@verona.se wrote: 
>
> j> While bbdb is the most mature it can't be included in Emacs AFAICS.
>
> It's on my TODO list to look through the BBDB 3.0 Git repository on
> Savannah and track down all the contributors for the current source, get
> papers from them, and then put BBDB on the GNU ELPA.  Apologies to
> everyone who's waiting on me for this, especially Roland Winkler, the
> current BBDB maintainer, who's been very patient.
>
> If anyone wants to help with this task, it would be greatly appreciated.
> It's not hard work, just time-consuming and I haven't found the time.

Hi Ted,

git shortlog -e --summary

should give you a list of all of the contributors on the project.

Regards,
Bernt

Re: BBDB in the GNU ELPA

[Ted Zlatanov]

On Sat, 28 May 2011 10:57:03 -0400 Bernt Hansen <bernt@norang.ca> wrote: 

BH> Ted Zlatanov <tzz@lifelogs.com> writes:
>> On Thu, 26 May 2011 09:27:05 +0200 joakim@verona.se wrote: 
>> 
j> While bbdb is the most mature it can't be included in Emacs AFAICS.
>> 
>> It's on my TODO list to look through the BBDB 3.0 Git repository on
>> Savannah and track down all the contributors for the current source, get
>> papers from them, and then put BBDB on the GNU ELPA.  Apologies to
>> everyone who's waiting on me for this, especially Roland Winkler, the
>> current BBDB maintainer, who's been very patient.
>> 
>> If anyone wants to help with this task, it would be greatly appreciated.
>> It's not hard work, just time-consuming and I haven't found the time.

BH> git shortlog -e --summary

BH> should give you a list of all of the contributors on the project.

It does.  But that's not useful when you're trying to find out who wrote
the last verstion of a specific function or even a single line.  

`git blame' is the best way I know but I need to track content across
files, so it gets pretty tough even with that tool's support for
tracking content.  I wrote some scripts to parse the "porcelain" output
of `git blame' and the -w (ignore whitespace) flag is vital, but it's a
lot of tedious work nevertheless.

Ted

Re: BBDB in the GNU ELPA

[Glenn Morris]

Ted Zlatanov wrote:

> BH> git shortlog -e --summary
>
> BH> should give you a list of all of the contributors on the project.
>
> It does.  But that's not useful when you're trying to find out who wrote
> the last verstion of a specific function or even a single line.  

This information won't be comprehensive, will it, given that the project
is at least 20 years old, so significantly predates git? I woudn't have
thought that you can expect git to reliably reflect the authorship of
changes made when the project was using an older VCS?

Re: BBDB in the GNU ELPA

[Štěpán Němec]

Glenn Morris <rgm@gnu.org> writes:

> Ted Zlatanov wrote:
>
>> BH> git shortlog -e --summary
>>
>> BH> should give you a list of all of the contributors on the project.
>>
>> It does.  But that's not useful when you're trying to find out who wrote
>> the last verstion of a specific function or even a single line.  
>
> This information won't be comprehensive, will it, given that the project
> is at least 20 years old, so significantly predates git? I woudn't have
> thought that you can expect git to reliably reflect the authorship of
> changes made when the project was using an older VCS?

Of course you can, provided you imported all the history, which is
normally the case. You shouldn't lose any information that the original
VCS had (and Git cares about).

The real reason any VCS won't provide comprehensive authorship
information IMO is that it's common with some projects, especially
formerly, to commit other people's changes (patches etc.) under one's
name (some VCSes probably don't even know the difference between author
and committer), so while the real author might (should) be in the change
log file, the VCS committer/author will be different.

  Štěpán

Re: BBDB in the GNU ELPA

[Glenn Morris]

> (some VCSes probably don't even know the difference between author and
> committer), so while the real author might (should) be in the change
> log file, the VCS committer/author will be different.

That's what I meant.

Re: BBDB in the GNU ELPA

[Ted Zlatanov]

On Mon, 30 May 2011 15:42:37 -0400 Glenn Morris <rgm@gnu.org> wrote: 

>> (some VCSes probably don't even know the difference between author and
>> committer), so while the real author might (should) be in the change
>> log file, the VCS committer/author will be different.

GM> That's what I meant.

Yes, it's a pain in the neck.  But the CVS-to-Git conversion at least
tells us when the change happened.

Ted

Re: Emacs as a desktop environment

[Ted Zlatanov]

On Wed, 25 May 2011 12:33:55 -0400 Ken Raeburn <raeburn@raeburn.org> wrote: 

KR> I still go to external programs for lots of tasks, though:

KR> * viewing .doc files, editing/viewing spreadsheets from others, making presentation slides (OpenOffice); not very common, so not a big deal

Thankfully I have avoided that plague so far.

KR> * general web browsing (firefox/iceweasel)

I don't think external programs are avoidable for this nowadays.

KR> * bug tracking (Jira server, via iceweasel); and whaddaya know, Google points me to the JiraMode node at EmacsWiki, hmm...

That's really outside the "desktop environment" discussion.

>> - load indicators (CPU, memory, network load, etc.): can be done with SVG

KR> Ooh, this sounds interesting...

Yeah, several people have mentioned this one.  So I guess it's the first
piece I'll tackle.

On Wed, 25 May 2011 23:58:17 +0200 Lennart Borgman <lennart.borgman@gmail.com> wrote: 

LB> Would not a lot more people gain from a better Gnome than from a
LB> better Emacs desktop?

I think both are good things, but Gnome has a different direction from
what I've described and so my suggestions are unlikely to be adopted there.
Plus I am much happier writing Lisp than other languages.

On Wed, 25 May 2011 09:45:18 -0700 PJ Weisberg <pjweisberg@gmail.com> wrote: 

PW> On Wednesday, May 25, 2011, Ted Zlatanov <tzz@lifelogs.com> wrote:
>> On Wed, 25 May 2011 09:31:24 +0200 joakim@verona.se wrote:
TN> [load indicators] No need!  OK, "urxvt -e top" works, too.
>> 
TN> [date, weather, market indicators] No need!
>> 
TN> [workspace indicator] All in the mind.  Or, "work? what's that?
TN> space? nice place!".
>> 
>> I disagree, those are necessary.

PW> Most of those are a waste of space, except for date/time, which is essential.

Let's put it this way: I will implement some indicators since several
people have said that's a good thing, and it's not a lot of work.  Then
you and everyone else can choose not to use them.  Everyone's happy that
way, especially me, since I don't have to argue about it.

Ted

Re: Emacs as a desktop environment

[Tom Tromey]

Ted> Let's put it this way: I will implement some indicators since several
Ted> people have said that's a good thing, and it's not a lot of work.  Then
Ted> you and everyone else can choose not to use them.  Everyone's happy that
Ted> way, especially me, since I don't have to argue about it.

I have a hack to put things in the system tray from Emacs.
It isn't very well done; it would be nice if Emacs could do this, too.
Maybe this is related to what you are interested in, but maybe not.. ?

Tom

Re: Emacs as a desktop environment

[PJ Weisberg]

On Wednesday, May 25, 2011, Ted Zlatanov <tzz@lifelogs.com> wrote:
> On Wed, 25 May 2011 09:45:18 -0700 PJ Weisberg <pjweisberg@gmail.com> wrote:
>
> PW> On Wednesday, May 25, 2011, Ted Zlatanov <tzz@lifelogs.com> wrote:
>>> On Wed, 25 May 2011 09:31:24 +0200 joakim@verona.se wrote:
> TN> [load indicators] No need!  OK, "urxvt -e top" works, too.
>>>
> TN> [date, weather, market indicators] No need!
>>>
> TN> [workspace indicator] All in the mind.  Or, "work? what's that?
> TN> space? nice place!".
>>>
>>> I disagree, those are necessary.
>
> PW> Most of those are a waste of space, except for date/time, which is essential.
>
> Let's put it this way: I will implement some indicators since several
> people have said that's a good thing, and it's not a lot of work.  Then
> you and everyone else can choose not to use them.  Everyone's happy that
> way, especially me, since I don't have to argue about it.

Oh, you never have to argue about anything if you don't want to.  ;-)

My point was really that "smaller, without all the unnecessary
features" isn't a very useful goal, because for every feature you cut,
there's a group of people who consider it essential.  Because those
features are not meant for people who use the computer the way you use
the computer, it's hard for you to guess how important they are.

Once you start cutting out useless features, you're heading towards a
desktop that's useful only to you.

-- 

-PJ

Re: Emacs as a desktop environment

[Ted Zlatanov]

On Thu, 26 May 2011 08:36:27 -0700 PJ Weisberg <pjweisberg@gmail.com> wrote: 

PW> My point was really that "smaller, without all the unnecessary
PW> features" isn't a very useful goal, because for every feature you cut,
PW> there's a group of people who consider it essential.  Because those
PW> features are not meant for people who use the computer the way you use
PW> the computer, it's hard for you to guess how important they are.

PW> Once you start cutting out useless features, you're heading towards a
PW> desktop that's useful only to you.

I'm OK with that.  Since Emacs is the engine that drives it, it's easy
to extend or modify my desktop environment to suit other people's needs.
That, in fact, is the chief difference between an Emacs-based approach
to the desktop environment and the Gnome/KDE/XFCE/etc. approach with
hard-coded binary blobs and skin-deep themes and HTML+CSS visual
customizations.  The latter seems to eventually evolve into a Mac OS X
clone or a W32 clone; let's see what a fresh Emacs-based approach can
do.

Ted

Re: Emacs as a desktop environment

[Eric M. Ludlam]

As a part of Emacsifying your desktop, there is XWEM, which puts your 
emacs into a window manager implemented in Emacs.  If I recall, you can 
put some regular X widgets in the tray to get the time and battery and a 
few other things.

http://www.nongnu.org/xwem/

Eric

On 05/24/2011 09:05 PM, Ted Zlatanov wrote:
> I've been very frustrated lately with the memory and resource use of
> gnome-panel, XFCE, and the new Unity UI in Ubuntu 11.04.  They use
> multiple megabytes of memory for trivial things; they are slow, and they
> make a machine with 3 GB of RAM feel slow just doing trivial things.
>
> I think GNU Emacs, at least on GNU/Linux systems, can provide much of
> the desktop environment functionality, so Emacs + a window manager like
> XMonad is a full desktop experience:
>
> - launch bar: a place to put icons associated with a program (simple toolbar)
>
> - Applications, Places, and System menus: not sure how to connect those
>
> - load indicators (CPU, memory, network load, etc.): can be done with SVG
>
> - date, weather, market indicators: SVG and/or plain text
>
> - workspace indicator: needs to talk to the window manager
>
> - all file management: Dired
>
> - icon dock for application and system indicators
>
> I'd like to know how much of this can be achieved with today's GNU Emacs
> plus the external packages (GNU ELPA, Tom Tromey's ELPA, EmacsWiki,
> etc.) available, and how much will require new packages or changes to
> Emacs' internals.
>
> Thanks
> Ted
>
>
>

Re: Emacs as a desktop environment

[Ted Zlatanov]

On Wed, 25 May 2011 20:58:15 -0400 "Eric M. Ludlam" <eric@siege-engine.com> wrote: 

EML> As a part of Emacsifying your desktop, there is XWEM, which puts your
EML> emacs into a window manager implemented in Emacs.  If I recall, you
EML> can put some regular X widgets in the tray to get the time and battery
EML> and a few other things.

EML> http://www.nongnu.org/xwem/

I looked at it and it looks abandoned, plus the window manager is the
one piece that doesn't need to replaced in my view.

On Wed, 25 May 2011 19:33:11 -0600 Tom Tromey <tromey@redhat.com> wrote: 

Tom> I have a hack to put things in the system tray from Emacs.
Tom> It isn't very well done; it would be nice if Emacs could do this, too.
Tom> Maybe this is related to what you are interested in, but maybe not.. ?

No, that's going the other way.  I want an Emacs instance to *be* the
system tray (and workspace indicator, and basically everything that
makes a desktop environment except the window manager and the
applications themselves).  Can the system tray interface be implemented
as a protocol or does it need C code?

Thanks
Ted

Re: Emacs as a desktop environment

[joakim]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Wed, 25 May 2011 20:58:15 -0400 "Eric M. Ludlam" <eric@siege-engine.com> wrote: 
>
> EML> As a part of Emacsifying your desktop, there is XWEM, which puts your
> EML> emacs into a window manager implemented in Emacs.  If I recall, you
> EML> can put some regular X widgets in the tray to get the time and battery
> EML> and a few other things.
>
> EML> http://www.nongnu.org/xwem/
>
> I looked at it and it looks abandoned, plus the window manager is the
> one piece that doesn't need to replaced in my view.
>
> On Wed, 25 May 2011 19:33:11 -0600 Tom Tromey <tromey@redhat.com> wrote: 
>
> Tom> I have a hack to put things in the system tray from Emacs.
> Tom> It isn't very well done; it would be nice if Emacs could do this, too.
> Tom> Maybe this is related to what you are interested in, but maybe not.. ?
>
> No, that's going the other way.  I want an Emacs instance to *be* the
> system tray (and workspace indicator, and basically everything that
> makes a desktop environment except the window manager and the
> applications themselves).  Can the system tray interface be implemented
> as a protocol or does it need C code?

I'm not really sure what you mean but I think most things can be done
using dbus. If you mean actualy docking the applets inside Emacs that
can't be done yet. OTOH it is interesting to note that the trend, as
illustrated by Gnome 3, is to remove nearly everything from the desktop.

My approach is to run Emacs in fullscreen, using zen-mode on
github. When I want to know the time or network connectivity or
something I press F5 to bring up a temporary Emacs buffer with that
information. That way I can supposedly concentrate on work rather than
staring at the clock. I solved the need for a system load meter by
getting a faster laptop...

>
> Thanks
> Ted
>

-- 
Joakim Verona

Re: Emacs as a desktop environment

[Ted Zlatanov]

On Thu, 26 May 2011 18:38:16 +0200 joakim@verona.se wrote: 

j> When I want to know the time or network connectivity or something I
j> press F5 to bring up a temporary Emacs buffer with that
j> information. That way I can supposedly concentrate on work rather
j> than staring at the clock.

Can you show the code you use for F5?

Ted

Re: Emacs as a desktop environment

[joakim]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Thu, 26 May 2011 18:38:16 +0200 joakim@verona.se wrote: 
>
> j> When I want to know the time or network connectivity or something I
> j> press F5 to bring up a temporary Emacs buffer with that
> j> information. That way I can supposedly concentrate on work rather
> j> than staring at the clock.
>
> Can you show the code you use for F5?

(require 'battery)
(require 'timeclock)
(defun modeline-depopulator ()
  (interactive)
  (message "%s\n%s\n%s\n%s"
           (format-time-string "%H:%M %Y-%m-%d" (current-time))
           (battery-format battery-echo-area-format (funcall
                                                     battery-status-function))
           (timeclock-status-string)
           (shell-command-to-string "nmcli -p dev")

           ))
(global-set-key [f5] 'modeline-depopulator)


>
> Ted
>

-- 
Joakim Verona

just-the-text Emacs frame (was: Emacs as a desktop environment)

[Ted Zlatanov]

I just want to display some text, nothing else.  How about this (based
on your code) to show some arbitrary text in a popup (no menus,
modeline, etc., just the buffer is visible)?  I think it will DTRT
whether the frame is shown already or not.  I can use this to show the
indicators, icons, and status messages.

#+begin_src lisp
(require 'battery)
(require 'timeclock)

(defvar popup-info-frame)

(defun popup-info-string ()
  (format "%s\n%s\n%s\n%s"
          (format-time-string "%H:%M %Y-%m-%d" (current-time))
          (battery-format battery-echo-area-format (funcall
                                                    battery-status-function))
          (timeclock-status-string)
          (shell-command-to-string "nmcli -p dev")))

(defun popup-info ()
  (interactive)
  (popup-info--1 " *popup status*"))

(defun popup-info--1 (bufname)
  (with-current-buffer (get-buffer-create bufname)
    (make-local-variable 'popup-info-frame)
    (if (and (boundp 'popup-info-frame)
             popup-info-frame
             (member popup-info-frame (frame-list)))
        (select-frame popup-info-frame)
      (let ((default-frame-alist '((minibuffer . nil)
                                   (width . 20)
                                   (border-width . 0)
                                   (menu-bar-lines . 0)
                                   (tool-bar-lines . 0)
                                   (unsplittable . t)
                                   (left-fringe . 0))))
        (switch-to-buffer-other-frame bufname)
        (setq popup-info-frame (selected-frame))))
    (erase-buffer)
    (setq mode-line-format nil)
    (redraw-modeline)
    (insert (popup-info-string))))

#+end_src

Let me know what you think.  It supports any number of status buffers by
name and behaves correctly even if the frame is closed.

Thanks!
Ted

Emacs24 Mobile (was: Re: just-the-text Emacs frame (was: Emacs as a desktop environment))

[Mohsen BANAN]

>>>>> On Sat, 28 May 2011 12:49:59 -0500, Ted Zlatanov <tzz@lifelogs.com> said:

  Ted> Let me know what you think.  It supports any number of status buffers by
  Ted> name and behaves correctly even if the frame is closed.

  Ted> Thanks!

I tried your code. 

It worked great for me. Thanks.

I think the concept of Emacs as a desktop
environment is very powerful and you are on the
right track. 

Let me suggest a particular environment where what
you are proposing has immense potential. 

Emacs as the desktop on Handsets/Mobile Phones.

Please permit me to set the stage first.

For about 3 years now I have been using emacs on 
a Nokia 810 and more recently on Nokia 900.

Nokia 810's native OS was called Maemo. It is a
debian dertivative (not totally Halaal(حلال)/free).
The Windows Manager+Desktop is Hildon (Gnome's
desktop for handheld devices).

Naturally I have put emacs on it and have been using
the handset exclusively from within emacs. My main
usages are:

 - Personal Information Management (org-mode, bbdb, calendar, ...)
 - Interpersonal Communications (Gnus, ...)
 - Music/Media Playing (EMMS + mplayer)
 - Garage door opener (APC9211 + snmp + a relay, ...)

All of that I have been using with various emacs
drop down menus. 

The current emacs user interface does not work well
with the finger's touch. I have been living with it
but ...

With that preface and the direction that you are
going, let's consider the following.

  - On a bare handset, we start with a debian
    GNU/Linux without any GUI.

  - We add X and a windows manager (no desktop).

  - We add Emacs as a desktop.

  - We add a new touch oriented emacs menu system.

This last piece of a "touch oriented emacs menu
system" is what I am proposing you consider adding
to your popup-info code. Let's call it popup-menu.

For example: 

a popup-info frame is customized to fit the
handset's full screen. Then the frame is broken
into a say 3x6 grid of buttons forming a set of
nested menus.

For now we can assume that there is no gesture in
place and drive it all with popup frames and 
touch oriented menus (popup-menus).

In emacs we already have richer apps than iPhone,
Android and WindowsMobile7 combined.

So, it really is just a matter of rethinking the
menu interface and desktop behavior on touch
oriented small screens. 

Your thoughts?

...Mohsen

Re: Emacs24 Mobile

[Ted Zlatanov]

On Sat, 28 May 2011 13:01:53 -0700 Mohsen BANAN <list-general@mohsen.1.banan.byname.net> wrote: 

MB> a popup-info frame is customized to fit the handset's full
MB> screen. Then the frame is broken into a say 3x6 grid of buttons
MB> forming a set of nested menus.

MB> For now we can assume that there is no gesture in place and drive it
MB> all with popup frames and touch oriented menus (popup-menus).

That's fine.  Finger touches are just mouse events, right?  There will
have to be a `popup-info-maximized' version of my function that creates
a maximized frame.

Laying out the frame contents as a 3x6 grid of buttons is pretty easy,
too.  I don't think I should be going as far as actual UI and launchers
with my work yet, rather I'll try to provide some basic facilities that
can be customized for each screen size and user.

MB> In emacs we already have richer apps than iPhone, Android and
MB> WindowsMobile7 combined.

MB> So, it really is just a matter of rethinking the menu interface and
MB> desktop behavior on touch oriented small screens.

I'm glad you are looking in that direction.  My challenge will be to do
work that's generally useful, so both desktop users with large screens
and mobile users with small screens will benefit.  I'll keep your needs
in mind.

Ted

Re: Emacs24 Mobile

[T.V. Raman]

Would also be interesting to augment emacs on mobile with spoken
output -- fo rinstance, see the platform TTS API  on Android.

If all of emacs runs on Android, getting emacspeak
http://emacspeak.sf.net running on Android would be a matter of
writing a speech server atop that TTS  API.
-- 
Best Regards,
--raman

-- 
Best Regards,
--raman


On 5/28/11, Ted Zlatanov <tzz@lifelogs.com> wrote:
> On Sat, 28 May 2011 13:01:53 -0700 Mohsen BANAN
> <list-general@mohsen.1.banan.byname.net> wrote:
>
> MB> a popup-info frame is customized to fit the handset's full
> MB> screen. Then the frame is broken into a say 3x6 grid of buttons
> MB> forming a set of nested menus.
>
> MB> For now we can assume that there is no gesture in place and drive it
> MB> all with popup frames and touch oriented menus (popup-menus).
>
> That's fine.  Finger touches are just mouse events, right?  There will
> have to be a `popup-info-maximized' version of my function that creates
> a maximized frame.
>
> Laying out the frame contents as a 3x6 grid of buttons is pretty easy,
> too.  I don't think I should be going as far as actual UI and launchers
> with my work yet, rather I'll try to provide some basic facilities that
> can be customized for each screen size and user.
>
> MB> In emacs we already have richer apps than iPhone, Android and
> MB> WindowsMobile7 combined.
>
> MB> So, it really is just a matter of rethinking the menu interface and
> MB> desktop behavior on touch oriented small screens.
>
> I'm glad you are looking in that direction.  My challenge will be to do
> work that's generally useful, so both desktop users with large screens
> and mobile users with small screens will benefit.  I'll keep your needs
> in mind.
>
> Ted
>
>
>

Re: Emacs24 Mobile

[Lars Magne Ingebrigtsen]

"T.V. Raman" <tv.raman.tv@gmail.com> writes:

> If all of emacs runs on Android, getting emacspeak
> http://emacspeak.sf.net running on Android would be a matter of
> writing a speech server atop that TTS  API.

Does Emacs run on a (non-jailbroken) Android phone?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: just-the-text Emacs frame

[Thierry Volpiatto]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I just want to display some text, nothing else.  How about this (based

Do you know popup.el? (you should find it on emacswiki in auto-complete).

--8<---------------cut here---------------start------------->8---
(require 'popup)

(defun popup-info-string ()
  (format "%s\n%s\n%s\n%s"
          (format-time-string "%H:%M %Y-%m-%d" (current-time))
          (battery-format battery-echo-area-format (funcall
                                                    battery-status-function))
          (timeclock-status-string)
          (shell-command-to-string "nmcli -p dev")))

(popup-tip (popup-info-string))
--8<---------------cut here---------------end--------------->8---

> on your code) to show some arbitrary text in a popup (no menus,
> modeline, etc., just the buffer is visible)?  I think it will DTRT
> whether the frame is shown already or not.  I can use this to show the
> indicators, icons, and status messages.
>
> #+begin_src lisp
> (require 'battery)
> (require 'timeclock)
>
> (defvar popup-info-frame)
>
> (defun popup-info-string ()
>   (format "%s\n%s\n%s\n%s"
>           (format-time-string "%H:%M %Y-%m-%d" (current-time))
>           (battery-format battery-echo-area-format (funcall
>                                                     battery-status-function))
>           (timeclock-status-string)
>           (shell-command-to-string "nmcli -p dev")))
>
> (defun popup-info ()
>   (interactive)
>   (popup-info--1 " *popup status*"))
>
> (defun popup-info--1 (bufname)
>   (with-current-buffer (get-buffer-create bufname)
>     (make-local-variable 'popup-info-frame)
>     (if (and (boundp 'popup-info-frame)
>              popup-info-frame
>              (member popup-info-frame (frame-list)))
>         (select-frame popup-info-frame)
>       (let ((default-frame-alist '((minibuffer . nil)
>                                    (width . 20)
>                                    (border-width . 0)
>                                    (menu-bar-lines . 0)
>                                    (tool-bar-lines . 0)
>                                    (unsplittable . t)
>                                    (left-fringe . 0))))
>         (switch-to-buffer-other-frame bufname)
>         (setq popup-info-frame (selected-frame))))
>     (erase-buffer)
>     (setq mode-line-format nil)
>     (redraw-modeline)
>     (insert (popup-info-string))))
>
> #+end_src
>
> Let me know what you think.  It supports any number of status buffers by
> name and behaves correctly even if the frame is closed.
>
> Thanks!
> Ted
>
>
>

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: just-the-text Emacs frame

[Ted Zlatanov]

On Sat, 28 May 2011 22:18:14 +0200 Thierry Volpiatto <thierry.volpiatto@gmail.com> wrote: 

TV> Ted Zlatanov <tzz@lifelogs.com> writes:
>> I just want to display some text, nothing else.  How about this (based

TV> Do you know popup.el? (you should find it on emacswiki in auto-complete).
TV> (require 'popup)
...
TV> (popup-tip (popup-info-string))

I think a standalone frame (note all the details in my code that make it
as bare as possible) is more useful, but I'll keep this in mind as well.

Thanks
Ted

Re: just-the-text Emacs frame

[joakim]

Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

> Ted Zlatanov <tzz@lifelogs.com> writes:
>
>> I just want to display some text, nothing else.  How about this (based
>
> Do you know popup.el? (you should find it on emacswiki in auto-complete).

I tried this and it was nice. I use a fullscreen Emacs ond the popup
lets me not move the focus from where I am in the buffer. I will try
Teds frame solution next.

>
> (require 'popup)
>
> (defun popup-info-string ()
>   (format "%s\n%s\n%s\n%s"
>           (format-time-string "%H:%M %Y-%m-%d" (current-time))
>           (battery-format battery-echo-area-format (funcall
>                                                     battery-status-function))
>           (timeclock-status-string)
>           (shell-command-to-string "nmcli -p dev")))
>
> (popup-tip (popup-info-string))
>
>> on your code) to show some arbitrary text in a popup (no menus,
>> modeline, etc., just the buffer is visible)?  I think it will DTRT
>> whether the frame is shown already or not.  I can use this to show the
>> indicators, icons, and status messages.
>>
>> #+begin_src lisp
>> (require 'battery)
>> (require 'timeclock)
>>
>> (defvar popup-info-frame)
>>
>> (defun popup-info-string ()
>>   (format "%s\n%s\n%s\n%s"
>>           (format-time-string "%H:%M %Y-%m-%d" (current-time))
>>           (battery-format battery-echo-area-format (funcall
>>                                                     battery-status-function))
>>           (timeclock-status-string)
>>           (shell-command-to-string "nmcli -p dev")))
>>
>> (defun popup-info ()
>>   (interactive)
>>   (popup-info--1 " *popup status*"))
>>
>> (defun popup-info--1 (bufname)
>>   (with-current-buffer (get-buffer-create bufname)
>>     (make-local-variable 'popup-info-frame)
>>     (if (and (boundp 'popup-info-frame)
>>              popup-info-frame
>>              (member popup-info-frame (frame-list)))
>>         (select-frame popup-info-frame)
>>       (let ((default-frame-alist '((minibuffer . nil)
>>                                    (width . 20)
>>                                    (border-width . 0)
>>                                    (menu-bar-lines . 0)
>>                                    (tool-bar-lines . 0)
>>                                    (unsplittable . t)
>>                                    (left-fringe . 0))))
>>         (switch-to-buffer-other-frame bufname)
>>         (setq popup-info-frame (selected-frame))))
>>     (erase-buffer)
>>     (setq mode-line-format nil)
>>     (redraw-modeline)
>>     (insert (popup-info-string))))
>>
>> #+end_src
>>
>> Let me know what you think.  It supports any number of status buffers by
>> name and behaves correctly even if the frame is closed.
>>
>> Thanks!
>> Ted
>>
>>
>>

-- 
Joakim Verona

Re: just-the-text Emacs frame

[Ted Zlatanov]

[-- Attachment #1: Type: text/plain, Size: 831 bytes --]

On Sat, 28 May 2011 12:49:59 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> I just want to display some text, nothing else.  How about this (based
TZ> on your code) to show some arbitrary text in a popup (no menus,
TZ> modeline, etc., just the buffer is visible)?  I think it will DTRT
TZ> whether the frame is shown already or not.  I can use this to show the
TZ> indicators, icons, and status messages.

Attached is emacs-panel.el, which does the above.  It support arbitrary
frames, each one showing a specific buffer and refreshing its content on
a timer with a function associated with that buffer.

There's an example in the commentary that shows how it's used.  It works
for me.  Let me know what you think; next I will start adding pieces to
this framework to implement each of the tasks I listed earlier.

Thanks
Ted


[-- Attachment #2: emacs-panel.el --]
[-- Type: application/emacs-lisp, Size: 4268 bytes --]

Re: just-the-text Emacs frame

[Leo]

On 2011-06-02 02:01 +0800, Ted Zlatanov wrote:
> Attached is emacs-panel.el, which does the above.  It support arbitrary
> frames, each one showing a specific buffer and refreshing its content on
> a timer with a function associated with that buffer.
>
> There's an example in the commentary that shows how it's used.  It works
> for me.  Let me know what you think; next I will start adding pieces to
> this framework to implement each of the tasks I listed earlier.
>
> Thanks
> Ted

Can this pop up a frame without a title bar, much like what tooltip
does?

Leo

Re: just-the-text Emacs frame

[Eli Zaretskii]

> From: Leo <sdl.web@gmail.com>
> Date: Thu, 02 Jun 2011 10:43:35 +0800
> 
> Can this pop up a frame without a title bar, much like what tooltip
> does?

Not without some help from the display engine on the C level, AFAICT.
Tooltips are special kind of frame treated specially by redisplay.

Re: just-the-text Emacs frame

[Ted Zlatanov]

On Thu, 02 Jun 2011 00:05:28 -0400 Eli Zaretskii <eliz@gnu.org> wrote: 

>> From: Leo <sdl.web@gmail.com>
>> Date: Thu, 02 Jun 2011 10:43:35 +0800
>> 
>> Can this pop up a frame without a title bar, much like what tooltip
>> does?

EZ> Not without some help from the display engine on the C level, AFAICT.
EZ> Tooltips are special kind of frame treated specially by redisplay.

I always thought frame decorations came from the window manager; is
there a way to tell it "I draw my own title bar"?  I think Google Chrome
does that.  If there's a frame property we can add at the C level to
hint this, it would make emacs-panel popups better and probably be nice
for Emacs in general.

I wouldn't go as far as a tooltip, though.  I think it's important that
the emacs-panel popup frames be like any other Emacs frame, simply
displaying a buffer.  That way we can use all the normal buffer-level
facilities when we display things inside emacs-panel popups, like text
properties and image overlays and UI elements.

Ted

Re: just-the-text Emacs frame

[Mohsen BANAN]

>>>>> On Thu, 02 Jun 2011 08:15:31 -0500, Ted Zlatanov <tzz@lifelogs.com> said:

  Ted> I wouldn't go as far as a tooltip, though.  I think it's important that
  Ted> the emacs-panel popup frames be like any other Emacs frame, simply
  Ted> displaying a buffer.  That way we can use all the normal buffer-level
  Ted> facilities when we display things inside emacs-panel popups, like text
  Ted> properties and image overlays and UI elements.

I request for a bit more inside of an emacs-panel.

Please let live emacs-panels consist of live emacs-tiles.

Live meaning updated (as you are already doing it
with the timer).

A live emacs-tile being a rectangle. Associated
with a buffer.

Each emacs-tile has an "update" function.

A live emacs-tile may optionally have a clickable
(touchable) function. So, in addition to being
"live" it is optionally "active". Each emacs-tile
may have an "activate" function.

So, an emacs-panel would not be simply displaying
a buffer, but possibly a series of buffers
(tiles).

With tiles available inside of panels, we would be
one more step closer towards making Emacs24 Mobile.

With "live" and "active" emacs-tiles available within
emacs-panels, we could then provide a parallel to
(easy-menu-define) where even existing menus are also
emacs-panel/tile based.

The process of splitting an emacs-panel into
emacs-tiles can be based on something like Lars's
(gnus-add-configuration).

All of that would let Emacs24-Mobile to compete
with Windows7-Mobile UI.

Your thoughts?

...Mohsen

Re: just-the-text Emacs frame

[Ted Zlatanov]

On Thu, 02 Jun 2011 08:43:55 -0700 Mohsen BANAN <list-general@mohsen.1.banan.byname.net> wrote: 

>>>>>> On Thu, 02 Jun 2011 08:15:31 -0500, Ted Zlatanov <tzz@lifelogs.com> said:

Ted> I wouldn't go as far as a tooltip, though.  I think it's important that
Ted> the emacs-panel popup frames be like any other Emacs frame, simply
Ted> displaying a buffer.  That way we can use all the normal buffer-level
Ted> facilities when we display things inside emacs-panel popups, like text
Ted> properties and image overlays and UI elements.

MB> I request for a bit more inside of an emacs-panel.

MB> Please let live emacs-panels consist of live emacs-tiles.
...
MB> So, an emacs-panel would not be simply displaying a buffer, but
MB> possibly a series of buffers (tiles).

Should those tiles be Emacs windows or buffer-level facilities?

At the buffer level we can manage and decorate them better, but the
Emacs windows may have advantages too.  I can't think of any for this
case.

MB> Each emacs-tile has an "update" function.

OK.

MB> A live emacs-tile may optionally have a clickable (touchable)
MB> function. So, in addition to being "live" it is optionally
MB> "active". Each emacs-tile may have an "activate" function.

That should be a property of the text produced by the "update" function.

MB> With "live" and "active" emacs-tiles available within emacs-panels,
MB> we could then provide a parallel to (easy-menu-define) where even
MB> existing menus are also emacs-panel/tile based.

MB> The process of splitting an emacs-panel into emacs-tiles can be
MB> based on something like Lars's (gnus-add-configuration).

Can you provide an example?  I don't know exactly what you mean here.

Thanks
Ted

Re: just-the-text Emacs frame

[Mohsen BANAN]

>>>>> On Thu, 02 Jun 2011 12:41:25 -0500, Ted Zlatanov <tzz@lifelogs.com> said:
  Ted> On Thu, 02 Jun 2011 08:43:55 -0700 Mohsen BANAN <list-general@mohsen.1.banan.byname.net> wrote: 
  >>>>>>> On Thu, 02 Jun 2011 08:15:31 -0500, Ted Zlatanov <tzz@lifelogs.com> said:


  MB> Please let live emacs-panels consist of live emacs-tiles.
  Ted> ...
  MB> So, an emacs-panel would not be simply displaying a buffer, but
  MB> possibly a series of buffers (tiles).

  Ted> Should those tiles be Emacs windows or buffer-level facilities?

I wrote that poorly.

Usually not emacs windows.

In the concrete, emacs-panel would be simply
displaying a buffer but in the abstract the
emacs-panel buffer is the aggregation of a series
of emacs-tiles (likely buffers). 

I'll be expanding on this in the context of an
example below.

  MB> A live emacs-tile may optionally have a clickable (touchable)
  MB> function. So, in addition to being "live" it is optionally
  MB> "active". Each emacs-tile may have an "activate" function.

  Ted> That should be a property of the text produced by the "update" function.

Possible to do it that way but there are also
advantages for an entire emacs-tile to be declared
active to the emacs-panel. 

More on this in the example below.


  MB> The process of splitting an emacs-panel into emacs-tiles can be
  MB> based on something like Lars's (gnus-add-configuration).

  Ted> Can you provide an example?  I don't know exactly what you mean here.

Gnus provides a facility for structuring a frame
into multiple windows based on horizontal/vertical
box specifications.

On a wide screen, mine is this:

(defun bystar:mail:display:frame-wide ()
  "On a Wide Frame"
  (interactive)

  (gnus-add-configuration
   '(summary
     (horizontal 1.0
		 (vertical 0.6 (summary 1.0 point))
		 (vertical 1.0 (group 1.0)))))

  (gnus-add-configuration
   '(article
     (horizontal 1.0
		 (vertical 0.6 (summary 0.25 point) (article 1.0) )
		 (vertical 1.0  ("*BBDB*" 1.0) (score-trace 0.1)))))
  )

So, I am proposing that similarly an emacs-panel can be
devided into emacs-tiles.

The example below explains it more.

Panel of Tiles Example:
-----------------------

Consider that we were trying to mimic what 
Windows 7 Mobile is doing in:
  
  http://www.blogcdn.com/www.engadget.com/media/2010/02/02-15-10winphone2.jpg

There will be 1 emacs-panel containing 7
emacs-tiles.

So, we need to:

    - Specify 7 emacs-tiles. (6 squares 1 rectangle
      in that picture.)
    - Specify lay out and sizes of the tiles within the
      panel. Based on something similar to gnus-add-configuration.
    - Specify the emacs-panel's overall size ... and
      make it contain the 7 emacs-tiles.

As you said, a tile in a panel is not same as a 
window in a frame.

The horizontal/vertical dividers for the tiles
could be as simple as lines (thin dividers -- not scroll bars).

I have a preference for the "active" abstraction
for the entire tile to be optionally deligated to
the panel manager as opposed to always being a
property of the text inside of the tile.

The idea is that on a handset you would always
take it for granted that touching (clicking) a
tile will always do something. 

My motivation is to facilitate getting things
started towards Emacs Mobile. The maping between
the container of a set of tiles into a panel can
be at frame or window level. May be we need a
separate abstraction name for the container of a
set of tiles.

With something like this (panels of tiles) in
place, emacs can quickly be made quite usable on a
touch based handset.

On a large screen, outside of the handset usage,
using you own example:

(emacs-panel-popup-add
 "status" :function
 (lambda ()
   (format "%s\n%s\n%s\n%s"
           (format-time-string "%H:%M %Y-%m-%d" (current-time))
           (battery-format battery-echo-area-format (funcall
                                                     battery-status-function))
           (timeclock-status-string)
           (shell-command-to-string "nmcli -p  dev"))))

Using tiles, you could be creating 4 tiles for 
each of:

           (format-time-string "%H:%M %Y-%m-%d" (current-time))

           (battery-format battery-echo-area-format (funcall
                                                     battery-status-function))

           (timeclock-status-string)

           (shell-command-to-string "nmcli -p  dev")

With tile dividers between them and separate
update functions ...

What do you think?

Thanks.

...Mohsen

Re: just-the-text Emacs frame

[Ted Zlatanov]

On Thu, 02 Jun 2011 13:19:49 -0700 Mohsen BANAN <list-general@mohsen.1.banan.byname.net> wrote: 

MB> Panel of Tiles Example:
MB> -----------------------

MB> Consider that we were trying to mimic what 
MB> Windows 7 Mobile is doing in:
  
MB>   http://www.blogcdn.com/www.engadget.com/media/2010/02/02-15-10winphone2.jpg

I'll reply to the rest later, but please let's not try to mimic
anything.  If we create something, let it be the right fit for our
needs, not a rehash of other people's ideas.  These tiles are just large
buttons with HTML and other dynamic content, aren't they?  Emacs can do
it 100x better, and we don't need kinetic scolling or visual candy to
make it useful.

I bring this up here because emacs-panel.el is intended to fix some of
the things I dislike about Gnome and other desktop environments,
especially how they mimic the Windows and Mac OS X desktop environments
and how expensive their resource usage is.  So I hope you will agree.

Thanks
Ted

Re: just-the-text Emacs frame

[Mohsen BANAN]

>>>>> On Thu, 02 Jun 2011 16:06:22 -0500, Ted Zlatanov <tzz@lifelogs.com> said:

  Ted> On Thu, 02 Jun 2011 13:19:49 -0700 Mohsen BANAN <list-general@mohsen.1.banan.byname.net> wrote: 
  MB> Panel of Tiles Example:
  MB> -----------------------

  MB> Consider that we were trying to mimic what 
  MB> Windows 7 Mobile is doing in:
  
  MB> http://www.blogcdn.com/www.engadget.com/media/2010/02/02-15-10winphone2.jpg

  Ted> I'll reply to the rest later, but please let's not try to mimic
  Ted> anything.  If we create something, let it be the right fit for our
  Ted> needs, not a rehash of other people's ideas.  These tiles are just large
  Ted> buttons with HTML and other dynamic content, aren't they?  Emacs can do
  Ted> it 100x better, and we don't need kinetic scolling or visual candy to
  Ted> make it useful.

  Ted> I bring this up here because emacs-panel.el is intended to fix some of
  Ted> the things I dislike about Gnome and other desktop environments,
  Ted> especially how they mimic the Windows and Mac OS X desktop environments
  Ted> and how expensive their resource usage is.  So I hope you will agree.

My goal has been to add considerations for emacs
on handsets (small screen + touch) into the mix.

In that context I am convinced that tiles, larger
buttons, keypads and full screen menus have a
place towards adapting emacs to handsets.

This does not mean that we should abandon the
emacs paradigm and mimic the iPhone/Android/WinMob/...
paradigms. 

So, I am proposing experimentation with the following
hierarchy:

  - Bare-Frames (no mini-buf, no menu, ...)
     - Related Windows
        - Panels (Collection of Tiles)
           - Tiles (Optionally Live and Active)

If such facilities were in place, I think we could
move towards making emacs more usable on a
handset.

The purpose of my citing the Windows 7 Mobile
screen was to point applicability of the above to
a common full screen menu model.

Let's now throw Microsoft Windows 7 Mobile
completely out of the picture.

Consider use of emacs's calc on a handset.

In that case, the prefered UI is likely :
(calc-keypad)

The basic structure of (calc-keypad) is:

  - 2 related windows in the current frame.
  - A custom made text grid functioning as a keypad

In this case, I am saying let's add to emacs
necessary abstraction and facilities so that:

  - The two related windows can fit properly in a
    Bare-Frame without any waste of screen space
    on the handset.

  - Instead of a custom made grid functioning as a
    keypad let's provide tiles such that keypads 
    are done nicer and better.

If these ideas fit in the direction that you are
headed, please consider my requests.

Thanks.

...Mohsen

Re: just-the-text Emacs frame

[Ted Zlatanov]

On Thu, 02 Jun 2011 13:19:49 -0700 Mohsen BANAN <list-general@mohsen.1.banan.byname.net> wrote: 

MB> Gnus provides a facility for structuring a frame
MB> into multiple windows based on horizontal/vertical
MB> box specifications.
...
MB>   (gnus-add-configuration
MB>    '(summary
MB>      (horizontal 1.0
MB> 		 (vertical 0.6 (summary 1.0 point))
MB> 		 (vertical 1.0 (group 1.0)))))

Oh right, so it's a tree of H and V splits.

MB> So, I am proposing that similarly an emacs-panel can be
MB> devided into emacs-tiles.

OK.

MB>     - Specify 7 emacs-tiles. (6 squares 1 rectangle
MB>       in that picture.)
MB>     - Specify lay out and sizes of the tiles within the
MB>       panel. Based on something similar to gnus-add-configuration.
MB>     - Specify the emacs-panel's overall size ... and
MB>       make it contain the 7 emacs-tiles.

MB> The horizontal/vertical dividers for the tiles
MB> could be as simple as lines (thin dividers -- not scroll bars).

There is no need for dividers.  Just set the background to a different
color and give each tile a little padding or margin.

MB> I have a preference for the "active" abstraction for the entire tile
MB> to be optionally deligated to the panel manager as opposed to always
MB> being a property of the text inside of the tile.

Maybe we can write a tiling panel manager, then, which can run inside
any buffer and tile any content using the configurations you showed.
That would be generally useful, not just for mobile devices.

MB> My motivation is to facilitate getting things started towards Emacs
MB> Mobile. The maping between the container of a set of tiles into a
MB> panel can be at frame or window level. May be we need a separate
MB> abstraction name for the container of a set of tiles.

It would be simplest to call tiles by name (symbol or string) and nest
them inside frames (always using just one buffer per frame).  So you'd
define a tile with margin, padding, etc. properties:

(emacs-panel-tile-add "myfeeds" :margin 3 :text ... :call ...)
(emacs-panel-tile-add 'mychat :padding 2 :update-function ... :call ...)

and then use it in a tiled 3x3 layout:

(emacs-panel-popup-add "status" :tiles '(nil "myfeeds" nil 'mychat)
                                :background "black"
                                :layout-manager '(tile :x 3 :y 3))

Does that API seem OK?  Or do you still think a H/V split tree is needed
and we should support irregular grids?  Remember, they are more powerful
but also harder to use and configure...  So maybe we should start with
simple tiling and add irregular grids later.

On Fri, 03 Jun 2011 08:09:39 -0700 Mohsen BANAN <list-general@mohsen.1.banan.byname.net> wrote: 

MB> So, I am proposing experimentation with the following
MB> hierarchy:

MB>   - Bare-Frames (no mini-buf, no menu, ...)
MB>      - Related Windows
MB>         - Panels (Collection of Tiles)
MB>            - Tiles (Optionally Live and Active)

Yes.  We're at bare frames now, slowly moving towards panels and tiles.
I think a panel should be a frame.  I'm not sure what related windows
are.

MB> Consider use of emacs's calc on a handset.

Your example is useful, but you're jumping too far ahead.  Let's work on
the general panel and tiling functionality first.

Ted

Re: just-the-text Emacs frame

[Mohsen BANAN]

>>>>> On Fri, 03 Jun 2011 15:56:20 -0500, Ted Zlatanov <tzz@lifelogs.com> said:

  Ted> It would be simplest to call tiles by name (symbol or string) and nest
  Ted> them inside frames (always using just one buffer per frame).  So you'd
  Ted> define a tile with margin, padding, etc. properties:

  Ted> (emacs-panel-tile-add "myfeeds" :margin 3 :text ... :call ...)
  Ted> (emacs-panel-tile-add 'mychat :padding 2 :update-function ... :call ...)

  Ted> and then use it in a tiled 3x3 layout:

  Ted> (emacs-panel-popup-add "status" :tiles '(nil "myfeeds" nil 'mychat)
  Ted>                                 :background "black"
  Ted>                                 :layout-manager '(tile :x 3 :y 3))

  Ted> Does that API seem OK?  Or do you still
  Ted> think a H/V split tree is needed and we
  Ted> should support irregular grids?  Remember,
  Ted> they are more powerful but also harder to
  Ted> use and configure...  So maybe we should
  Ted> start with simple tiling and add irregular
  Ted> grids later.

Agreed.

Let's start simple and see how things develop.

The API that you suggested is a fine starting point.

  MB> So, I am proposing experimentation with the following
  MB> hierarchy:

  MB> - Bare-Frames (no mini-buf, no menu, ...)
  MB>    - Related Windows
  MB>        - Panels (Collection of Tiles)
  MB>            - Tiles (Optionally Live and Active)

  Ted> Yes.  We're at bare frames now, slowly moving towards panels and tiles.
  Ted> I think a panel should be a frame.  I'm not sure what related windows
  Ted> are.

By related windows I meant things similar to the
(calc-keypad) where one window is the keypad
(panel of tiles) and the related window is the RPN
stack.

We can see how things evolve and revisit.

Thanks for considering my requests.

...Mohsen

Re: just-the-text Emacs frame

[Eli Zaretskii]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Date: Thu, 02 Jun 2011 08:15:31 -0500
> 
> >> Can this pop up a frame without a title bar, much like what tooltip
> >> does?
> 
> EZ> Not without some help from the display engine on the C level, AFAICT.
> EZ> Tooltips are special kind of frame treated specially by redisplay.
> 
> I always thought frame decorations came from the window manager; is
> there a way to tell it "I draw my own title bar"?

I'm not an expert on this, so I don't know.  However, if you grep the
Emacs sources for "tip_frame", you will see how many places give
special treatment to tooltip frames.

GTK "decorated" and "deletable" properties (was: just-the-text Emacs frame)

[Ted Zlatanov]

On Thu, 02 Jun 2011 21:00:13 +0300 Eli Zaretskii <eliz@gnu.org> wrote: 

>> From: Ted Zlatanov <tzz@lifelogs.com>
>> Date: Thu, 02 Jun 2011 08:15:31 -0500
>> 
>> >> Can this pop up a frame without a title bar, much like what tooltip
>> >> does?
>> 
EZ> Not without some help from the display engine on the C level, AFAICT.
EZ> Tooltips are special kind of frame treated specially by redisplay.
>> 
>> I always thought frame decorations came from the window manager; is
>> there a way to tell it "I draw my own title bar"?

EZ> I'm not an expert on this, so I don't know.  However, if you grep the
EZ> Emacs sources for "tip_frame", you will see how many places give
EZ> special treatment to tooltip frames.

According to http://developer.gnome.org/gtk/2.24/GtkWindow.html, we
could use gtk_window_set_decorated() and gtk_window_set_deletable()
before the frame's GTK Window is shown.

Can these be exposed through frame parameters?  It's the last missing piece
for the emacs-panel popup frames.

Thanks
Ted

Re: GTK "decorated" and "deletable" properties (was: just-the-text Emacs frame)

[Eli Zaretskii]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Date: Thu, 02 Jun 2011 13:53:28 -0500
> 
> According to http://developer.gnome.org/gtk/2.24/GtkWindow.html, we
> could use gtk_window_set_decorated() and gtk_window_set_deletable()
> before the frame's GTK Window is shown.
> 
> Can these be exposed through frame parameters?

This is software.  We can do anything we like.

Re: GTK "decorated" and "deletable" properties

[Ted Zlatanov]

On Thu, 02 Jun 2011 23:49:54 +0300 Eli Zaretskii <eliz@gnu.org> wrote: 

>> From: Ted Zlatanov <tzz@lifelogs.com>
>> Date: Thu, 02 Jun 2011 13:53:28 -0500
>> 
>> According to http://developer.gnome.org/gtk/2.24/GtkWindow.html, we
>> could use gtk_window_set_decorated() and gtk_window_set_deletable()
>> before the frame's GTK Window is shown.
>> 
>> Can these be exposed through frame parameters?

EZ> This is software.  We can do anything we like.

Let me rephrase.  Could someone who knows the GTK interface do it?
Please?

Thanks
Ted

Re: GTK "decorated" and "deletable" properties

[Jan Djärv]

Ted Zlatanov skrev 2011-06-02 22.59:
> On Thu, 02 Jun 2011 23:49:54 +0300 Eli Zaretskii<eliz@gnu.org>  wrote:
>
>>> From: Ted Zlatanov<tzz@lifelogs.com>
>>> Date: Thu, 02 Jun 2011 13:53:28 -0500
>>>
>>> According to http://developer.gnome.org/gtk/2.24/GtkWindow.html, we
>>> could use gtk_window_set_decorated() and gtk_window_set_deletable()
>>> before the frame's GTK Window is shown.
>>>
>>> Can these be exposed through frame parameters?
>
> EZ>  This is software.  We can do anything we like.
>
> Let me rephrase.  Could someone who knows the GTK interface do it?
> Please?

These functions just set the MotifWMHints.  So we should make sure it works on 
all X11 ports, not just Gtk+.  Also, can these new frame parameters be 
generalized into something that makes sense on all ports (W32, Nextstep)?

	Jan D.

Re: GTK "decorated" and "deletable" properties

[Ted Zlatanov]

On Fri, 03 Jun 2011 17:21:19 +0200 Jan Djärv <jan.h.d@swipnet.se> wrote: 

JD> Ted Zlatanov skrev 2011-06-02 22.59:
>> On Thu, 02 Jun 2011 23:49:54 +0300 Eli Zaretskii<eliz@gnu.org>  wrote:
>> 
>>>> From: Ted Zlatanov<tzz@lifelogs.com>
>>>> Date: Thu, 02 Jun 2011 13:53:28 -0500
>>>> 
>>>> According to http://developer.gnome.org/gtk/2.24/GtkWindow.html, we
>>>> could use gtk_window_set_decorated() and gtk_window_set_deletable()
>>>> before the frame's GTK Window is shown.
>>>> 
>>>> Can these be exposed through frame parameters?
>> 
EZ> This is software.  We can do anything we like.
>> 
>> Let me rephrase.  Could someone who knows the GTK interface do it?
>> Please?

JD> These functions just set the MotifWMHints.  So we should make sure it
JD> works on all X11 ports, not just Gtk+.  Also, can these new frame
JD> parameters be generalized into something that makes sense on all ports
JD> (W32, Nextstep)?

GTK on W32 respects the decorated hint and passes it on correctly,
according to the docs.  It's not clear from the docs if W32 itself will
display the window without decorations, but it seems so: "On Windows,
this function always works, since there's no window manager policy
involved."

On NextStep / Cocoa, according to
http://www.cocoadev.com/index.pl?BorderlessWindow it's possible but such
a window can't have a toolbar (does it crash or simply ignore the
toolbar?  that's not clear).  For my purposes that's OK, the pop-up
frames I need won't have toolbars.

It would be nice if each port offered even more control through native
frame properties, of course, e.g. ns-borderless and gtk-deletable.  I
can then set each native property and it has no effect otherwise.  But a
general name convention is useful too.

Thanks
Ted

Re: GTK "decorated" and "deletable" properties

[Eli Zaretskii]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Date: Fri, 03 Jun 2011 11:29:12 -0500
> 
> JD> These functions just set the MotifWMHints.  So we should make sure it
> JD> works on all X11 ports, not just Gtk+.  Also, can these new frame
> JD> parameters be generalized into something that makes sense on all ports
> JD> (W32, Nextstep)?
> 
> GTK on W32 respects the decorated hint and passes it on correctly,
> according to the docs.  It's not clear from the docs if W32 itself will
> display the window without decorations, but it seems so: "On Windows,
> this function always works, since there's no window manager policy
> involved."

Emacs cannot yet use GTK on Windows (except in the Cygwin build).  We
use the Windows native "toolkit" for the native w32 build.

Re: GTK "decorated" and "deletable" properties

[Ted Zlatanov]

On Fri, 03 Jun 2011 19:39:36 +0300 Eli Zaretskii <eliz@gnu.org> wrote: 

>> From: Ted Zlatanov <tzz@lifelogs.com>
>> Date: Fri, 03 Jun 2011 11:29:12 -0500
>> 
JD> These functions just set the MotifWMHints.  So we should make sure it
JD> works on all X11 ports, not just Gtk+.  Also, can these new frame
JD> parameters be generalized into something that makes sense on all ports
JD> (W32, Nextstep)?
>> 
>> GTK on W32 respects the decorated hint and passes it on correctly,
>> according to the docs.  It's not clear from the docs if W32 itself will
>> display the window without decorations, but it seems so: "On Windows,
>> this function always works, since there's no window manager policy
>> involved."

EZ> Emacs cannot yet use GTK on Windows (except in the Cygwin build).  We
EZ> use the Windows native "toolkit" for the native w32 build.

OK, so we can respect a few generic properties like "decorated" and also
offer some w32-* properties for that toolkit specifically.  Same as what
I proposed for the NextStep/Cocoa port.

Ted

Re: GTK "decorated" and "deletable" properties

[Jan Djärv]

Ted Zlatanov skrev 2011-06-03 18.29:
> On Fri, 03 Jun 2011 17:21:19 +0200 Jan Djärv<jan.h.d@swipnet.se>  wrote:
>
>
> JD>  These functions just set the MotifWMHints.  So we should make sure it
> JD>  works on all X11 ports, not just Gtk+.  Also, can these new frame
> JD>  parameters be generalized into something that makes sense on all ports
> JD>  (W32, Nextstep)?
>
> GTK on W32 respects the decorated hint and passes it on correctly,
> according to the docs.  It's not clear from the docs if W32 itself will
> display the window without decorations, but it seems so: "On Windows,
> this function always works, since there's no window manager policy
> involved."
>

Emacs does not suppoty Gtk+ on anything but X11.

> On NextStep / Cocoa, according to
> http://www.cocoadev.com/index.pl?BorderlessWindow it's possible but such
> a window can't have a toolbar (does it crash or simply ignore the
> toolbar?  that's not clear).  For my purposes that's OK, the pop-up
> frames I need won't have toolbars.
>
> It would be nice if each port offered even more control through native
> frame properties, of course, e.g. ns-borderless and gtk-deletable.  I
> can then set each native property and it has no effect otherwise.  But a
> general name convention is useful too.
>

For X11 you can do it in lisp.  Here is a function from an earlier bug report 
about Motif WM Hints (4363).  Gtk+ (as far as I know) only manipulates 
functions and decorations.

Motif wm hits is just a property with 5 values. Just use x-change-window-property.

(defun make-special-frame (data)
   (let ((ff (make-frame '((visibility . nil)))))
     (progn
       (x-change-window-property "_MOTIF_WM_HINTS" data ff
                                 "_MOTIF_WM_HINTS" 32 t)
        (make-frame-visible ff))))

To make a frame without decoration (gtk_window_decorated):

(make-special-frame '(2 0 0 0 0))

To make a frame without delete (gtk_window_deletable):

(make-special-frame '(1 33 0 0 0))

The first value tells what to change (from /usr/include/Xm/MwmUtils.h):
#define MWM_HINTS_FUNCTIONS     (1L << 0)
#define MWM_HINTS_DECORATIONS   (1L << 1)
#define MWM_HINTS_INPUT_MODE    (1L << 2)
#define MWM_HINTS_STATUS        (1L << 3)

The second is the functions:
#define MWM_FUNC_ALL            (1L << 0)
#define MWM_FUNC_RESIZE         (1L << 1)
#define MWM_FUNC_MOVE           (1L << 2)
#define MWM_FUNC_MINIMIZE       (1L << 3)
#define MWM_FUNC_MAXIMIZE       (1L << 4)
#define MWM_FUNC_CLOSE          (1L << 5)

The third is the decorations:
#define MWM_DECOR_ALL           (1L << 0)
#define MWM_DECOR_BORDER        (1L << 1)
#define MWM_DECOR_RESIZEH       (1L << 2)
#define MWM_DECOR_TITLE         (1L << 3)
#define MWM_DECOR_MENU          (1L << 4)
#define MWM_DECOR_MINIMIZE      (1L << 5)
#define MWM_DECOR_MAXIMIZE      (1L << 6)

Note that most wm:s just check MWM_HINTS when the window is mapped, thats why 
the function creates it invisible at first.
If a frame is visible, you must (make-frame-invisble), 
(x-change-window-properties...) (make-frame-visible).

	Jan D.

Re: GTK "decorated" and "deletable" properties

[Ted Zlatanov]

On Fri, 03 Jun 2011 19:39:05 +0200 Jan Djärv <jan.h.d@swipnet.se> wrote: 

JD> Ted Zlatanov skrev 2011-06-03 18.29:
>> On NextStep / Cocoa, according to
>> http://www.cocoadev.com/index.pl?BorderlessWindow it's possible but such
>> a window can't have a toolbar (does it crash or simply ignore the
>> toolbar?  that's not clear).  For my purposes that's OK, the pop-up
>> frames I need won't have toolbars.
>> 
>> It would be nice if each port offered even more control through native
>> frame properties, of course, e.g. ns-borderless and gtk-deletable.  I
>> can then set each native property and it has no effect otherwise.  But a
>> general name convention is useful too.

JD> For X11 you can do it in lisp.  Here is a function from an earlier bug
JD> report about Motif WM Hints (4363).  Gtk+ (as far as I know) only
JD> manipulates functions and decorations.

JD> Motif wm hits is just a property with 5 values. Just use x-change-window-property.

Thank you very much for the exhaustive X11 example.  I think it's
sufficient to get me what I need, at least for now.  I also hope the W32
and NextStep/Cocoa ports implement comparable functionality as I
suggested above and in my reply to Eli Zaretskii.

Thanks
Ted

sending X client messages from Emacs (was: GTK "decorated" and "deletable" properties)

[Ted Zlatanov]

On Fri, 03 Jun 2011 19:39:05 +0200 Jan Djärv <jan.h.d@swipnet.se> wrote: 

JD> Motif wm hits is just a property with 5 values. Just use x-change-window-property.

Jan, I added those hints to emacs-panel.el.  I was wondering if Emacs
has functions to send X client messages, e.g. to set
_NET_CURRENT_DESKTOP as shown in
http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html

I don't see functions for that currently and would love to have them.

Thanks
Ted

Re: sending X client messages from Emacs

[Chong Yidong]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Jan, I added those hints to emacs-panel.el.  I was wondering if Emacs
> has functions to send X client messages

You mean, like x-send-client-message?

Re: sending X client messages from Emacs

[Ted Zlatanov]

On Fri, 10 Jun 2011 17:27:51 -0400 Chong Yidong <cyd@stupidchicken.com> wrote: 

CY> Ted Zlatanov <tzz@lifelogs.com> writes:
>> Jan, I added those hints to emacs-panel.el.  I was wondering if Emacs
>> has functions to send X client messages

CY> You mean, like x-send-client-message?

I swear that wasn't there when I checked! :)

Thanks
Ted

Re: just-the-text Emacs frame

[Leo]

On 2011-06-02 21:15 +0800, Ted Zlatanov wrote:
> I wouldn't go as far as a tooltip, though.  I think it's important that
> the emacs-panel popup frames be like any other Emacs frame, simply
> displaying a buffer.  That way we can use all the normal buffer-level
> facilities when we display things inside emacs-panel popups, like text
> properties and image overlays and UI elements.

tooltip uses buffer to show the contents so it is very flexible. We only
need to change it to receive mouse-click event and then it is turned
into a capable notification system.

Leo

Re: just-the-text Emacs frame

[Ted Zlatanov]

On Fri, 03 Jun 2011 10:40:50 +0800 Leo <sdl.web@gmail.com> wrote: 

L> On 2011-06-02 21:15 +0800, Ted Zlatanov wrote:
>> I wouldn't go as far as a tooltip, though.  I think it's important that
>> the emacs-panel popup frames be like any other Emacs frame, simply
>> displaying a buffer.  That way we can use all the normal buffer-level
>> facilities when we display things inside emacs-panel popups, like text
>> properties and image overlays and UI elements.

L> tooltip uses buffer to show the contents so it is very flexible. We only
L> need to change it to receive mouse-click event and then it is turned
L> into a capable notification system.

Can you show an example of displaying arbitrary text with font
properties and images in a tooltip immediately, please?  I don't see it
in the manual.

Thanks
Ted

Re: just-the-text Emacs frame

[Leo]

On 2011-06-03 19:36 +0800, Ted Zlatanov wrote:
[snipped 13 lines]
> Can you show an example of displaying arbitrary text with font
> properties and images in a tooltip immediately, please?  I don't see it
> in the manual.
>
> Thanks
> Ted

Add them as properties to TEXT to tooltip-show. Note the text is
inserted into " *tip*" buffer.

Leo

Re: just-the-text Emacs frame

[Ted Zlatanov]

On Fri, 03 Jun 2011 19:55:34 +0800 Leo <sdl.web@gmail.com> wrote: 

L> On 2011-06-03 19:36 +0800, Ted Zlatanov wrote:
L> [snipped 13 lines]
>> Can you show an example of displaying arbitrary text with font
>> properties and images in a tooltip immediately, please?  I don't see it
>> in the manual.
>> 
>> Thanks
>> Ted

L> Add them as properties to TEXT to tooltip-show. Note the text is
L> inserted into " *tip*" buffer.

(btw, I realized "immediately" could be seen as a rude demand to provide
the info immediately.  I meant the code should bring the tooltip up
immediately :)

There can only be one tooltip at a time.  That's not so good.  It could
be used for quick notifications but not for persistent desktop elements,
since it will conflict with any regular tooltips.

Ted

Re: just-the-text Emacs frame

[Leo]

On 2011-06-03 23:15 +0800, Ted Zlatanov wrote:
> There can only be one tooltip at a time.  That's not so good.  It could
> be used for quick notifications but not for persistent desktop elements,
> since it will conflict with any regular tooltips.

tooltip-hide is called in pre-command-hook and x-show-tip. The facility
provided cannot not be readily used for notifications but it does not
require much change.

Leo

Re: just-the-text Emacs frame

[Eli Zaretskii]

> From: Leo <sdl.web@gmail.com>
> Date: Sat, 04 Jun 2011 11:51:40 +0800
> 
> On 2011-06-03 23:15 +0800, Ted Zlatanov wrote:
> > There can only be one tooltip at a time.  That's not so good.  It could
> > be used for quick notifications but not for persistent desktop elements,
> > since it will conflict with any regular tooltips.
> 
> tooltip-hide is called in pre-command-hook and x-show-tip.

But you can increase tooltip-hide-delay to a very large value, right?

Re: just-the-text Emacs frame

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 1087 bytes --]

On Thu, Jun 02 2011, Ted Zlatanov wrote:

> I always thought frame decorations came from the window manager; is
> there a way to tell it "I draw my own title bar"?  I think Google Chrome
> does that.  If there's a frame property we can add at the C level to
> hint this, it would make emacs-panel popups better and probably be nice
> for Emacs in general.

What you may want ultimately, is to be able to set various window types¹
on an Emacs frame.

Setting an Emacs frame the type DOCK will allow it to be attracted to
one of the frame edge, directly by the window manager. Setting it the
STRUT parameter will allow to reserve some place in the screen.

I've started to work on that 6 months ago, my work is available in a
branch². I can't recall if it's working totally, but I remember it was
at least in a good way. However it might be a start.


¹  http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2551529

²  http://git.naquadah.org/?p=~jd/emacs.git;a=shortlog;h=refs/heads/jd/strut-dock

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: just-the-text Emacs frame

[Ted Zlatanov]

On Fri, 03 Jun 2011 11:24:48 +0200 Julien Danjou <julien@danjou.info> wrote: 

JD> On Thu, Jun 02 2011, Ted Zlatanov wrote:
>> I always thought frame decorations came from the window manager; is
>> there a way to tell it "I draw my own title bar"?  I think Google Chrome
>> does that.  If there's a frame property we can add at the C level to
>> hint this, it would make emacs-panel popups better and probably be nice
>> for Emacs in general.

JD> What you may want ultimately, is to be able to set various window types¹
JD> on an Emacs frame.

JD> Setting an Emacs frame the type DOCK will allow it to be attracted to
JD> one of the frame edge, directly by the window manager. Setting it the
JD> STRUT parameter will allow to reserve some place in the screen.

That would be useful, although I still want to directly set the GTK
decorated and deletable properties.  All of these abilities will combine
to give emacs-panel.el the flexibility it needs to provide a desktop
environment.

JD> I've started to work on that 6 months ago, my work is available in a
JD> branch². I can't recall if it's working totally, but I remember it was
JD> at least in a good way. However it might be a start.

JD> ¹  http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2551529

JD> ²  http://git.naquadah.org/?p=~jd/emacs.git;a=shortlog;h=refs/heads/jd/strut-dock

I would really like it if someone who works with the Emacs GTK code
could look at your work.  It would be really useful to me and seems like
a low-risk feature.

Ted

Re: just-the-text Emacs frame

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 658 bytes --]

On Fri, Jun 03 2011, Ted Zlatanov wrote:

> That would be useful, although I still want to directly set the GTK
> decorated and deletable properties.  All of these abilities will combine
> to give emacs-panel.el the flexibility it needs to provide a desktop
> environment.

Actually, you may need that. Setting a correct window type is enough to
not have the window manager decorating the window.

I clearly had the same (kind of) idea as you have about creating an
Emacs based DE. To me what was missing was the possibility to make a
panel, this is why I've started my strut-dock branch. :)

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: just-the-text Emacs frame

[Ted Zlatanov]

On Fri, 03 Jun 2011 15:16:22 +0200 Julien Danjou <julien@danjou.info> wrote: 

JD> I clearly had the same (kind of) idea as you have about creating an
JD> Emacs based DE. To me what was missing was the possibility to make a
JD> panel, this is why I've started my strut-dock branch. :)

emacs-panel.el will be a package in the GNU ELPA (I hope), so if you can
commit there you can work on it too.  I'd like to avoid depending on any
particular features like your WM strut+dock support, the GTK
decorated+deletable properties I asked for, etc.  That way it can be
used in older Emacs versions and in XEmacs.  So if you can merge your
strut+dock work into the Emacs trunk that's great, but it's not critical.

Ted

Re: just-the-text Emacs frame

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 708 bytes --]

On Fri, Jun 03 2011, Ted Zlatanov wrote:

> emacs-panel.el will be a package in the GNU ELPA (I hope), so if you can
> commit there you can work on it too.  I'd like to avoid depending on any
> particular features like your WM strut+dock support, the GTK
> decorated+deletable properties I asked for, etc.  That way it can be
> used in older Emacs versions and in XEmacs.  So if you can merge your
> strut+dock work into the Emacs trunk that's great, but it's not critical.

I understand. Sure it's not critical, but it'll be a lot better if you
can use it! :) I'll try to rework and merge it someday. Maybe your
package will motivate me. :-)

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: just-the-text Emacs frame

[Jan Djärv]

Ted Zlatanov skrev 2011-06-03 17.11:
> On Fri, 03 Jun 2011 15:16:22 +0200 Julien Danjou<julien@danjou.info>  wrote:
>
> JD>  I clearly had the same (kind of) idea as you have about creating an
> JD>  Emacs based DE. To me what was missing was the possibility to make a
> JD>  panel, this is why I've started my strut-dock branch. :)
>
> emacs-panel.el will be a package in the GNU ELPA (I hope), so if you can
> commit there you can work on it too.  I'd like to avoid depending on any
> particular features like your WM strut+dock support, the GTK
> decorated+deletable properties I asked for, etc.  That way it can be
> used in older Emacs versions and in XEmacs.  So if you can merge your
> strut+dock work into the Emacs trunk that's great, but it's not critical.

I'm not so positive to the strut+windw type modifications for three reasons:

1) It can all be done in Lisp in a current Emacs without code modifications 
(well you have to unmap and remap for window type to take effect, so that is a 
bit ugly).
2) Strut is intended for pagers, panel and such, Emacs is not that kind of 
application.
3) Window types interract with override redirect and just setting the window 
type might not do the expected thing for all window managers.

Window type might have uses, but then override redirect should be handeled 
correctly also.  I don't think strut is suitable in Emacs.

	Jan D.

Re: just-the-text Emacs frame

[Ted Zlatanov]

On Fri, 03 Jun 2011 18:30:42 +0200 Jan Djärv <jan.h.d@swipnet.se> wrote: 

JD> Ted Zlatanov skrev 2011-06-03 17.11:
>> emacs-panel.el will be a package in the GNU ELPA (I hope), so if you can
>> commit there you can work on it too.  I'd like to avoid depending on any
>> particular features like your WM strut+dock support, the GTK
>> decorated+deletable properties I asked for, etc.  That way it can be
>> used in older Emacs versions and in XEmacs.  So if you can merge your
>> strut+dock work into the Emacs trunk that's great, but it's not critical.

JD> I'm not so positive to the strut+windw type modifications for three reasons:

JD> 1) It can all be done in Lisp in a current Emacs without code
JD> modifications (well you have to unmap and remap for window type to
JD> take effect, so that is a bit ugly).

If so, that's good news; it doesn't matter if it's ugly if it can be
abstracted inside emacs-panel.el.

JD> 2) Strut is intended for pagers, panel and such, Emacs is not that
JD> kind of application.

I want emacs-panel.el to do the job of gnome-panel.  So I'd like Emacs
to look like a panel.  Specifically, it would be ideal if the WM could
automatically place a special Emacs frame on a screen edge and keep it
on top of others (which IIUC is a strut).  I also need the frame to have
no decorations but that's another thread :)

JD> 3) Window types interract with override redirect and just setting the
JD> window type might not do the expected thing for all window managers.

JD> Window type might have uses, but then override redirect should be
JD> handeled correctly also.  I don't think strut is suitable in Emacs.

If you think it's not going to work, OK.  But it would be nice.

Ted

Re: just-the-text Emacs frame

[Jan Djärv]

Ted Zlatanov skrev 2011-06-03 19.37:

>
> I want emacs-panel.el to do the job of gnome-panel.  So I'd like Emacs
> to look like a panel.  Specifically, it would be ideal if the WM could
> automatically place a special Emacs frame on a screen edge and keep it
> on top of others (which IIUC is a strut).  I also need the frame to have
> no decorations but that's another thread :)

This might not behave as you wish.  Some window managers (metacity at least) 
apply struts to all windows made by an application if one window has struts 
set.  For Emacs that would mean that if you set struts on one frame, it 
applies to all frames.

	Jan D.

Re: just-the-text Emacs frame

[Ted Zlatanov]

On Fri, 03 Jun 2011 20:06:02 +0200 Jan Djärv <jan.h.d@swipnet.se> wrote: 

JD> Ted Zlatanov skrev 2011-06-03 19.37:

>> I want emacs-panel.el to do the job of gnome-panel.  So I'd like Emacs
>> to look like a panel.  Specifically, it would be ideal if the WM could
>> automatically place a special Emacs frame on a screen edge and keep it
>> on top of others (which IIUC is a strut).  I also need the frame to have
>> no decorations but that's another thread :)

JD> This might not behave as you wish.  Some window managers (metacity at
JD> least) apply struts to all windows made by an application if one
JD> window has struts set.  For Emacs that would mean that if you set
JD> struts on one frame, it applies to all frames.

It would be strange to run emacs-panel.el in a normal session, it's
intended to be run by itself (its 1-second timer makes it unpleasant
interactively).  So it may actually work OK if the strut treatment is
all-or-none.

Ted

Re: just-the-text Emacs frame

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 635 bytes --]

On Fri, Jun 03 2011, Jan Djärv wrote:

> This might not behave as you wish.  Some window managers (metacity at least)
> apply struts to all windows made by an application if one window has struts
> set.  For Emacs that would mean that if you set struts on one frame, it
> applies to all frames.

I don't believe you. That sounds like an extra amount of code to write
that would break EWMH explicitely. Quickly reading Metacity source code
makes me believe that you're wrong too.

(Now, I don't have time to find/write an app to check that, so, one of
us is wrong! :-)

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: just-the-text Emacs frame

[Jan Djärv]

Julien Danjou skrev 2011-06-06 10.38:
> On Fri, Jun 03 2011, Jan Djärv wrote:
>
>> This might not behave as you wish.  Some window managers (metacity at least)
>> apply struts to all windows made by an application if one window has struts
>> set.  For Emacs that would mean that if you set struts on one frame, it
>> applies to all frames.
>
> I don't believe you. That sounds like an extra amount of code to write
> that would break EWMH explicitely. Quickly reading Metacity source code
> makes me believe that you're wrong too.
>
> (Now, I don't have time to find/write an app to check that, so, one of
> us is wrong! :-)
>

I tried this with Emacs and it does behave the way I described.  If it is a 
metacity bug or not, I don't know.

	Jan D.

Re: just-the-text Emacs frame

[Jan Djärv]

On further testing, what I saw was just the application of struts which was 
confusing.  Ignore my comment about this.

	Jan D.


Jan Djärv skrev 2011-06-06 11.23:
>
>
> Julien Danjou skrev 2011-06-06 10.38:
>> On Fri, Jun 03 2011, Jan Djärv wrote:
>>
>>> This might not behave as you wish. Some window managers (metacity at least)
>>> apply struts to all windows made by an application if one window has struts
>>> set. For Emacs that would mean that if you set struts on one frame, it
>>> applies to all frames.
>>
>> I don't believe you. That sounds like an extra amount of code to write
>> that would break EWMH explicitely. Quickly reading Metacity source code
>> makes me believe that you're wrong too.
>>
>> (Now, I don't have time to find/write an app to check that, so, one of
>> us is wrong! :-)
>>
>
> I tried this with Emacs and it does behave the way I described. If it is a
> metacity bug or not, I don't know.
>
> Jan D.

Re: just-the-text Emacs frame

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 1955 bytes --]

On Mon, Jun 06 2011, Jan Djärv wrote:

> Julien Danjou skrev 2011-06-06 10.38:
>> On Fri, Jun 03 2011, Jan Djärv wrote:
>>
>>> This might not behave as you wish.  Some window managers (metacity at least)
>>> apply struts to all windows made by an application if one window has struts
>>> set.  For Emacs that would mean that if you set struts on one frame, it
>>> applies to all frames.
>>
>> I don't believe you. That sounds like an extra amount of code to write
>> that would break EWMH explicitely. Quickly reading Metacity source code
>> makes me believe that you're wrong too.
>>
>> (Now, I don't have time to find/write an app to check that, so, one of
>> us is wrong! :-)
>>
>
> I tried this with Emacs and it does behave the way I described.  If it is a
> metacity bug or not, I don't know.

So we may not be talking about the same thing. But I just tried (thanks
for the tip, I know see that my old branch is useless) using your hint:

#+begin_src: emacs-lisp
(defun make-special-frame ()
  (let* ((width 200)
         (height 500)
         (ff (make-frame `((visibility . nil)
                           (width . 20)))))
    (x-change-window-property "_NET_WM_STRUT_PARTIAL" `(,width 0 0 0 0 ,height 0 0 0 0 0 0) ff
                              "CARDINAL" 32 t)
    (x-change-window-property "_NET_WM_WINDOW_TYPE" '("_NET_WM_WINDOW_TYPE_DOCK") ff
                              "ATOM" 32 t)
    (make-frame-visible ff)))
#+end_src

This, under awesome and Metacity, creates a new frame and reserves 50
pixels on the left of the screen for the frame. It does not affect any
other Emacs frame.

Both awesome and metacity drops the window decoration because they
recognise the window as a dock, and reserve the space. I think this is
exactly what Ted wants, except portability.

I just miss a way to set the Emacs frame width and height in pixel.

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: just-the-text Emacs frame

[Ted Zlatanov]

On Mon, 06 Jun 2011 12:00:27 +0200 Julien Danjou <julien@danjou.info> wrote: 

#+begin_src: emacs-lisp
(defun make-special-frame ()
  (let* ((width 200)
	 (height 500)
	 (ff (make-frame `((visibility . nil)
			   (width . 20)))))
    (x-change-window-property "_NET_WM_STRUT_PARTIAL" `(,width 0 0 0 0 ,height 0 0 0 0 0 0) ff
			      "CARDINAL" 32 t)
    (x-change-window-property "_NET_WM_WINDOW_TYPE" '("_NET_WM_WINDOW_TYPE_DOCK") ff
			      "ATOM" 32 t)
    (make-frame-visible ff)))
#+end_src

JD> This, under awesome and Metacity, creates a new frame and reserves 50
JD> pixels on the left of the screen for the frame. It does not affect any
JD> other Emacs frame.

JD> Both awesome and metacity drops the window decoration because they
JD> recognise the window as a dock, and reserve the space. I think this is
JD> exactly what Ted wants, except portability.

Under XMonad, that creates a strut panel but the panel won't take any
keyboard input, which is a problem.  When I try to close it from the WM,
the WM targets another frame instead (the strut panel is not a normal
window, as expected).  It can be closed from the menus, but if I turn
off the menus as I intend, there will be no way to easily close that
frame.

I guess I can install a right-click handler, but I wonder if it's not
better to let emacs-panel manage all the popup frames it creates,
arranging them along the screen edges.  The lack of keyboard input
handling concerns me.  Does keyboard input work in other WMs?  I realize
this is way beyond the intended use of Emacs, so don't take it as a
complaint, more of an investigation :)

Thanks
Ted

Re: just-the-text Emacs frame

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 1223 bytes --]

On Mon, Jun 06 2011, Ted Zlatanov wrote:

> Under XMonad, that creates a strut panel but the panel won't take any
> keyboard input, which is a problem.

I think this is a XMonad bug. I'd suggest talking to them to figure out
why they are refusing to give the focus to such a window.

> When I try to close it from the WM,
> the WM targets another frame instead (the strut panel is not a normal
> window, as expected).  It can be closed from the menus, but if I turn
> off the menus as I intend, there will be no way to easily close that
> frame.

Yes, it makes sense. XMonad refuses to give it the focus both internally
and in X so it can't logically receive any event.

> I guess I can install a right-click handler, but I wonder if it's not
> better to let emacs-panel manage all the popup frames it creates,
> arranging them along the screen edges.  The lack of keyboard input
> handling concerns me.  Does keyboard input work in other WMs?  I realize
> this is way beyond the intended use of Emacs, so don't take it as a
> complaint, more of an investigation :)

Yeah, it works fine under others WM I tested. Really, I think it's a
bug. :)

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: just-the-text Emacs frame

[Ted Zlatanov]

On Tue, 07 Jun 2011 10:25:54 +0200 Julien Danjou <julien@danjou.info> wrote: 

JD> On Mon, Jun 06 2011, Ted Zlatanov wrote:
>> Under XMonad, that creates a strut panel but the panel won't take any
>> keyboard input, which is a problem.

JD> I think this is a XMonad bug. I'd suggest talking to them to figure out
JD> why they are refusing to give the focus to such a window.

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.

Ted

Re: just-the-text Emacs frame

[T.V. Raman]

I+haven%27t+seen+stumpwm+mentioned+in+this+thread+%2D%2D%2D+I+too%

On 6/10/11, Ted Zlatanov <tzz@lifelogs.com> wrote:
> On Tue, 07 Jun 2011 10:25:54 +0200 Julien Danjou <julien@danjou.info> wrote:
>
> JD> On Mon, Jun 06 2011, Ted Zlatanov wrote:
>>> Under XMonad, that creates a strut panel but the panel won't take any
>>> keyboard input, which is a problem.
>
> JD> I think this is a XMonad bug. I'd suggest talking to them to figure out
> JD> why they are refusing to give the focus to such a window.
>
> 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.
>
> Ted
>
>
>

Re: just-the-text Emacs frame

[chad]

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.

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

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

Hope that helps,
*Chad

Re: just-the-text Emacs frame

[Ted Zlatanov]

On Fri, 10 Jun 2011 11:57:37 -0700 chad <yandros@MIT.EDU> 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
http://stackoverflow.com/questions/758648/find-the-name-of-the-x-window-manager
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)
      (desktop-names
       ,@(emacs-panel-x-property-nullsepstringarray "_NET_DESKTOP_NAMES" 0))
      (active-window
       ,(emacs-panel-x-property-u32r "_NET_ACTIVE_WINDOW" 0))
      (desktop-count
       ,(emacs-panel-x-property-u32r "_NET_NUMBER_OF_DESKTOPS" 0))
      (current-desktop
       ,(emacs-panel-x-property-u32r "_NET_CURRENT_DESKTOP" 0)))))

#+end_src

(emacs-panel-wm-hints)
=> ((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.

Ted

Re: just-the-text Emacs frame

[Philipp Haselwarter]

On 2011-06-10 16:28 UT, Ted Zlatanov <tzz@lifelogs.com> wrote:

TZ> On Tue, 07 Jun 2011 10:25:54 +0200 Julien Danjou <julien@danjou.info> wrote:

JD> On Mon, Jun 06 2011, Ted Zlatanov wrote:
>>> Under XMonad, that creates a strut panel but the panel won't take
>>> any keyboard input, which is a problem.

JD> I think this is a XMonad bug.I'd suggest talking to them to figure
JD> out why they are refusing to give the focus to such a window.

TZ> I did.They claim it's necessary because other panels have a heart
TZ> attack when they get the keyboard input focus.So the solution is to
TZ> configure it at the user level, since they can't match dock rules to
TZ> Emacs frames in general (I've asked for more help but it doesn't
TZ> seem to be a priority to the XMonad developers, and I don't know
TZ> Haskell enough to do this myself).

TZ> So unless I get further help, I'll just document that XMonad is not
TZ> perfect for Emacs docked strut frames and I'll provide mouse
TZ> bindings to most of the things in such frames, including a binding
TZ> to pop their buffer up in a normal frame.

TZ> Ted

I assume you use manageDocks on your manageHook?
manageDocks simply does

#+begin_src haskell
manageDocks :: ManageHook
manageDocks = checkDock --> doIgnore
#+end_src

If you want more fine grained control, just ignore the docks you really
just want out of your way and set windows with  _NET_WM_WINDOW_TYPE_DOCK
to be floating. That way, they can still get focus and input.
And don't forget to put avoidStruts on your layout.

Could give you something like this:

#+begin_src haskell
myManageHook = composeAll . concat $
    [ [ className =? i --> doIgnore | i <- myCIgnores ]
    , [ className =? c --> doFloat  | c <- myCFloats  ]
    , [ title     =? t --> doFloat  | t <- myTFloats  ]
    , [ resource  =? r --> doFloat  | r <- myRFloats  ]
    , [ resource  =? i --> doIgnore | i <- myRIgnores ]
    , [ isFullscreen   --> doFullFloat ]
    , [ isDialog       --> doFloat     ]
    , [ checkDock      --> doFloat     ]
    , [ (className =? x <||> title =? x <||> resource =? x) --> doF (W.shift (myWorkspaces !! 1)) | x <- my1Shifts ]
    , [ (className =? x <||> title =? x <||> resource =? x) --> doShift (myWorkspaces !! 2) | x <- my2Shifts       ]
    ]
    where
    myCFloats  = [ "MPlayer", "Vlc", "Gimp", "Volume-control.py" ]
    myTFloats  = []
    myRFloats  = []
    myCIgnores = [ "dzen", "Avant-window-navigator" ]
    myRIgnores = [ "kdesktop", "desktop_window" ]
    my1Shifts  = [ "Nightly" ]
    my2Shifts  = []
#+end_src

Simply adjust myCIgnores or myRIgnores according to what docks you use.

-- 
Philipp Haselwarter

Re: just-the-text Emacs frame

[Ted Zlatanov]

On Sat, 11 Jun 2011 10:04:59 +0200 Philipp Haselwarter <philipp.haselwarter@gmx.de> wrote: 

PH> I assume you use manageDocks on your manageHook?
PH> manageDocks simply does
#+begin_src haskell
manageDocks :: ManageHook
manageDocks = checkDock --> doIgnore
#+end_src

PH> If you want more fine grained control, just ignore the docks you really
PH> just want out of your way and set windows with  _NET_WM_WINDOW_TYPE_DOCK
PH> to be floating. That way, they can still get focus and input.
PH> And don't forget to put avoidStruts on your layout.

PH> Could give you something like this:
#+begin_src haskell
myManageHook = composeAll . concat $
    [ [ className =? i --> doIgnore | i <- myCIgnores ]
    , [ className =? c --> doFloat  | c <- myCFloats  ]
    , [ title     =? t --> doFloat  | t <- myTFloats  ]
    , [ resource  =? r --> doFloat  | r <- myRFloats  ]
    , [ resource  =? i --> doIgnore | i <- myRIgnores ]
    , [ isFullscreen   --> doFullFloat ]
    , [ isDialog       --> doFloat     ]
    , [ checkDock      --> doFloat     ]
    , [ (className =? x <||> title =? x <||> resource =? x) --> doF (W.shift (myWorkspaces !! 1)) | x <- my1Shifts ]
    , [ (className =? x <||> title =? x <||> resource =? x) --> doShift (myWorkspaces !! 2) | x <- my2Shifts       ]
    ]
    where
    myCFloats  = [ "MPlayer", "Vlc", "Gimp", "Volume-control.py" ]
    myTFloats  = []
    myRFloats  = []
    myCIgnores = [ "dzen", "Avant-window-navigator" ]
    myRIgnores = [ "kdesktop", "desktop_window" ]
    my1Shifts  = [ "Nightly" ]
    my2Shifts  = []
#+end_src

PH> Simply adjust myCIgnores or myRIgnores according to what docks you use.

That sounds good.  I'll put something like that in the emacs-panel
recommendation and docs for when it detects you're running XMonad.

Thanks
Ted

org-src.el begin_src/end_src fontification may have been broken recently (was: just-the-text Emacs frame)

[Ted Zlatanov]

Recently (I haven't been able to find the commit that did it) org-src.el
fontification broke.  I get an error that ":-mode" could not be
executed.  I didn't open a bug because I'm not sure if it's something
wrong with my setup; it's hard to replicate this error with -q because
it involves org-mode and Gnus.  The parent message to this one causes
the error (see at end for actual code block); I fixed it by wrapping the
`org-src-font-lock-fontify-block' funcall in a `condition-case' but
that's not fixing the problem itself.

(defun org-src-font-lock-fontify-block (lang start end)
...
      (condition-case catcher
          (unless (eq major-mode lang-mode) (funcall lang-mode))
        (error (message "Could not run %s, sorry" lang-mode)))
...

Produces:

Could not run :-mode mode, sorry [2 times]

This error happens in Gnus and Emacs as of this morning.  The code block
below is not the only place it happens.

If I try to call `debug' in `org-src-font-lock-fontify-block' I get:

font-lock-mode-internal: Lisp nesting exceeds `max-lisp-eval-depth'

so I couldn't track the calls that are causing the error.

Let me know how I can determine why this is causing an error for me, and
if it's an actual bug.

Thanks
Ted

On Mon, 06 Jun 2011 12:00:27 +0200 Julien Danjou <julien@danjou.info> wrote: 

#+begin_src: emacs-lisp
(defun make-special-frame ()
  (let* ((width 200)
	 (height 500)
	 (ff (make-frame `((visibility . nil)
			   (width . 20)))))
    (x-change-window-property "_NET_WM_STRUT_PARTIAL" `(,width 0 0 0 0 ,height 0 0 0 0 0 0) ff
			      "CARDINAL" 32 t)
    (x-change-window-property "_NET_WM_WINDOW_TYPE" '("_NET_WM_WINDOW_TYPE_DOCK") ff
			      "ATOM" 32 t)
    (make-frame-visible ff)))
#+end_src

Re: org-src.el begin_src/end_src fontification may have been broken recently

[Stefan Monnier]

> If I try to call `debug' in `org-src-font-lock-fontify-block' I get:
> font-lock-mode-internal: Lisp nesting exceeds `max-lisp-eval-depth'

When debugging font-lock problems, start with (setq
font-lock-support-mode nil), after which you may have to
disable&reenable font-lock for the change to take effect.  With this
setting, debug-on-error as well as edebug can be used.


        Stefan

Re: org-src.el begin_src/end_src fontification may have been broken recently

[Ted Zlatanov]

On Tue, 07 Jun 2011 15:02:07 -0300 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> If I try to call `debug' in `org-src-font-lock-fontify-block' I get:
>> font-lock-mode-internal: Lisp nesting exceeds `max-lisp-eval-depth'

SM> When debugging font-lock problems, start with (setq
SM> font-lock-support-mode nil), after which you may have to
SM> disable&reenable font-lock for the change to take effect.  With this
SM> setting, debug-on-error as well as edebug can be used.

Once I did that, I kept getting this error (retyped since nothing worked
for keyboard interactions):

Error in post-command-hook (global-font-lock-mode-check-buffers): (void-function :-mode)

no matter what I did: `M-:', `M-x', etc. I would get this error.  I had
to exit Emacs to recover.  Fun times.

Ted

Re: org-src.el begin_src/end_src fontification may have been broken recently

[Jambunathan K]

I don't think there is a "colon" in begin_src directive.

You can install a babel block with either C-c C-v C-d or by typing <s at
the beginning of an empty line in an orgmode buffer.

Sorry if I misunderstood the mail.

Ted Zlatanov <tzz@lifelogs.com> writes:

> Recently (I haven't been able to find the commit that did it) org-src.el
> fontification broke.  I get an error that ":-mode" could not be
> executed.  I didn't open a bug because I'm not sure if it's something
> wrong with my setup; it's hard to replicate this error with -q because
> it involves org-mode and Gnus.  The parent message to this one causes
> the error (see at end for actual code block); I fixed it by wrapping the
> `org-src-font-lock-fontify-block' funcall in a `condition-case' but
> that's not fixing the problem itself.
>
> (defun org-src-font-lock-fontify-block (lang start end)
> ...
>       (condition-case catcher
>           (unless (eq major-mode lang-mode) (funcall lang-mode))
>         (error (message "Could not run %s, sorry" lang-mode)))
> ...
>
> Produces:
>
> Could not run :-mode mode, sorry [2 times]
>
> This error happens in Gnus and Emacs as of this morning.  The code block
> below is not the only place it happens.
>
> If I try to call `debug' in `org-src-font-lock-fontify-block' I get:
>
> font-lock-mode-internal: Lisp nesting exceeds `max-lisp-eval-depth'
>
> so I couldn't track the calls that are causing the error.
>
> Let me know how I can determine why this is causing an error for me, and
> if it's an actual bug.
>
> Thanks
> Ted
>
> On Mon, 06 Jun 2011 12:00:27 +0200 Julien Danjou <julien@danjou.info> wrote: 
>
> #+begin_src: emacs-lisp
> (defun make-special-frame ()
>   (let* ((width 200)
> 	 (height 500)
> 	 (ff (make-frame `((visibility . nil)
> 			   (width . 20)))))
>     (x-change-window-property "_NET_WM_STRUT_PARTIAL" `(,width 0 0 0 0 ,height 0 0 0 0 0 0) ff
> 			      "CARDINAL" 32 t)
>     (x-change-window-property "_NET_WM_WINDOW_TYPE" '("_NET_WM_WINDOW_TYPE_DOCK") ff
> 			      "ATOM" 32 t)
>     (make-frame-visible ff)))
> #+end_src

-- 

Re: org-src.el begin_src/end_src fontification may have been broken recently

[Ted Zlatanov]

On Tue, 07 Jun 2011 23:35:58 +0530 Jambunathan K <kjambunathan@gmail.com> wrote: 

JK> I don't think there is a "colon" in begin_src directive.

Right, that's the bug :) It used to work and there are no recent changes
to org*.el (according to the ChangeLog, not since 2011-03), so I think
the breakage happened somewhere else.  It's not in Gnus either: the last
suspicious commit is a merge:

commit bc1350c0871a8da4d356861b06020e37692056ef
Author: Stefan Monnier <monnier@iro.umontreal.ca>
Date:   Mon May 30 22:07:14 2011 +0000

    mml1991.el (mml1991-mailcrypt-encrypt): Remove use of ill-designed mm-with-unibyte-current-buffer.  The buffer should not contain any multibyte chars anyway at this stage.

but org-src.el highlighting worked for me in June, I'm positive.

Ted

Re: org-src.el begin_src/end_src fontification may have been broken recently

[Ted Zlatanov]

[-- Attachment #1: Type: text/plain, Size: 1145 bytes --]

On Tue, 07 Jun 2011 10:54:28 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> Recently (I haven't been able to find the commit that did it) org-src.el
TZ> fontification broke.  I get an error that ":-mode" could not be
TZ> executed.

Tha attached patch fixes the problem, which is that the fontification
language is now in position 8 instead of 7, and position 7 has ":".  The
fix is purely a patch, not really addressing why position 7 now has ":"
when it was the language before (there have been no commits to org.el
that could have caused this bug, AFAICT).  So something in this regular
expression:

"^\\([ \t]*#\\+\\(\\([a-zA-Z]+:?\\| \\|$\\)\\(_\\([a-zA-Z]+\\)\\)?\\)[ \t]*\\(\\([^ \t\n]*\\)[ \t]*\\(.*\\)\\)\\)"

broke between May 28 or so and today.  Which is why I made the fix as I
did, so it would keep working in places where the breakage doesn't
happen.

I'd really appreciate it if someone could review and maybe commit this
patch on the Emacs side (or I can commit it if necessary).  I don't
think it's an org-mode issue, but it could be breaking other people's
setups too because it triggers during fontification.

Thanks
Ted


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: org-src-fontification.patch --]
[-- Type: text/x-diff, Size: 561 bytes --]

=== modified file 'lisp/org/org.el'
--- lisp/org/org.el	2011-05-23 17:57:17 +0000
+++ lisp/org/org.el	2011-06-10 00:13:14 +0000
@@ -5109,6 +5109,9 @@
 	      (dc1 (downcase (match-string 2)))
 	      (dc3 (downcase (match-string 3)))
 	      end end1 quoting block-type)
+          ;; fix for the case where lang ends up in position 8
+          (when (and lang (equal ":" lang) (match-string 8))
+            (setq lang (match-string 8)))
 	  (cond
 	   ((member dc1 '("html:" "ascii:" "latex:" "docbook:"))
 	    ;; a single line of backend-specific content

Re: org-src.el begin_src/end_src fontification may have been broken recently

[Ted Zlatanov]

On Thu, 09 Jun 2011 19:20:24 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> On Tue, 07 Jun 2011 10:54:28 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: 
TZ> Recently (I haven't been able to find the commit that did it) org-src.el
TZ> fontification broke.  I get an error that ":-mode" could not be
TZ> executed.

TZ> Tha attached patch fixes the problem, which is that the fontification
TZ> language is now in position 8 instead of 7, and position 7 has ":".  The
TZ> fix is purely a patch, not really addressing why position 7 now has ":"
TZ> when it was the language before (there have been no commits to org.el
TZ> that could have caused this bug, AFAICT).  So something in this regular
TZ> expression:

TZ> "^\\([ \t]*#\\+\\(\\([a-zA-Z]+:?\\| \\|$\\)\\(_\\([a-zA-Z]+\\)\\)?\\)[ \t]*\\(\\([^ \t\n]*\\)[ \t]*\\(.*\\)\\)\\)"

TZ> broke between May 28 or so and today.  Which is why I made the fix as I
TZ> did, so it would keep working in places where the breakage doesn't
TZ> happen.

Sometimes it takes days of debugging and a full patch to see the
problem: Julien Danjou is using begin/end tags like this:

#+begin_src: emacs-lisp
#+end_src

While I'm using (as I was shown by Julien)

#+begin_src lisp
#+end_src

TZ> I'd really appreciate it if someone could review and maybe commit this
TZ> patch on the Emacs side (or I can commit it if necessary).  I don't
TZ> think it's an org-mode issue, but it could be breaking other people's
TZ> setups too because it triggers during fontification.

Julien, are you using that extra ":" because it's legitimate?  Or is it
an accident?  What should I do with my patch?

Thanks
Ted

Re: org-src.el begin_src/end_src fontification may have been broken recently

[Thierry Volpiatto]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Thu, 09 Jun 2011 19:20:24 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: 
>
> TZ> On Tue, 07 Jun 2011 10:54:28 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: 
> TZ> Recently (I haven't been able to find the commit that did it) org-src.el
> TZ> fontification broke.  I get an error that ":-mode" could not be
> TZ> executed.
>
> TZ> Tha attached patch fixes the problem, which is that the fontification
> TZ> language is now in position 8 instead of 7, and position 7 has ":".  The
> TZ> fix is purely a patch, not really addressing why position 7 now has ":"
> TZ> when it was the language before (there have been no commits to org.el
> TZ> that could have caused this bug, AFAICT).  So something in this regular
> TZ> expression:
>
> TZ> "^\\([ \t]*#\\+\\(\\([a-zA-Z]+:?\\| \\|$\\)\\(_\\([a-zA-Z]+\\)\\)?\\)[ \t]*\\(\\([^ \t\n]*\\)[ \t]*\\(.*\\)\\)\\)"
>
> TZ> broke between May 28 or so and today.  Which is why I made the fix as I
> TZ> did, so it would keep working in places where the breakage doesn't
> TZ> happen.
>
> Sometimes it takes days of debugging and a full patch to see the
> problem: Julien Danjou is using begin/end tags like this:
>
> #+begin_src: emacs-lisp
> #+end_src
>
> While I'm using (as I was shown by Julien)
>
> #+begin_src lisp
> #+end_src
>
> TZ> I'd really appreciate it if someone could review and maybe commit this
> TZ> patch on the Emacs side (or I can commit it if necessary).  I don't
> TZ> think it's an org-mode issue, but it could be breaking other people's
> TZ> setups too because it triggers during fontification.
>
> Julien, are you using that extra ":" because it's legitimate?  Or is it
> an accident?  What should I do with my patch?

I use here:

#+BEGIN_SRC lisp
(defun foo (a b)
  (+ a b))

#+END_SRC

See `anything-c-org-keywords-insert' (just commited a fix)


-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: org-src.el begin_src/end_src fontification may have been broken recently

[Bastien]

Hi Ted,

Ted Zlatanov <tzz@lifelogs.com> writes:

> Julien, are you using that extra ":" because it's legitimate?  Or is it
> an accident?  

I think this is just an accident.  The proper syntax is to use
#+begin_src with no ":" -- I've check the manual and the various
examples on Worg, there is no ":" there.

> What should I do with my patch?

Just dismiss it.

HTH,

-- 
 Bastien

Re: org-src.el begin_src/end_src fontification may have been broken recently

[Ted Zlatanov]

On Sat, 11 Jun 2011 01:00:30 +0200 Bastien <bzg@altern.org> wrote: 

B> Ted Zlatanov <tzz@lifelogs.com> writes:

>> Julien, are you using that extra ":" because it's legitimate?  Or is it
>> an accident?  

B> I think this is just an accident.  The proper syntax is to use
B> #+begin_src with no ":" -- I've check the manual and the various
B> examples on Worg, there is no ":" there.

>> What should I do with my patch?

B> Just dismiss it.

Hmm, but Gnus stops displaying articles when that error happens, leaving
them half-shown.  Should I patch Gnus or org.el to avoid that?  We can't
rely on those syntax blocks to always be good, and it's hard(er) to
debug problems in the fontification code.

Ted

Re: org-src.el begin_src/end_src fontification may have been broken recently

[Ted Zlatanov]

On Sat, 11 Jun 2011 05:41:38 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> On Sat, 11 Jun 2011 01:00:30 +0200 Bastien <bzg@altern.org> wrote: 

>>> What should I do with my patch?

B> Just dismiss it.

TZ> Hmm, but Gnus stops displaying articles when that error happens, leaving
TZ> them half-shown.  Should I patch Gnus or org.el to avoid that?  We can't
TZ> rely on those syntax blocks to always be good, and it's hard(er) to
TZ> debug problems in the fontification code.

Unfortunately, when modes not available are quoted
(e.g. "haskell-mode"), the error also happens.  So I think there should
be general protection in org.el against any block fontification failure.
My patch doesn't provide that and can be discarded; can you consider
this a bug then?  Should I submit it as an Emacs bug or to the org-mode
authors?

Thanks
Ted

Re: org-src.el begin_src/end_src fontification may have been broken recently

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 656 bytes --]

On Fri, Jun 10 2011, Ted Zlatanov wrote:

> TZ> I'd really appreciate it if someone could review and maybe commit this
> TZ> patch on the Emacs side (or I can commit it if necessary).  I don't
> TZ> think it's an org-mode issue, but it could be breaking other people's
> TZ> setups too because it triggers during fontification.
>
> Julien, are you using that extra ":" because it's legitimate?  Or is it
> an accident?  What should I do with my patch?

Ah yes, probably a mistake.

If you ask me, I'd say the syntax should allow both, but well, I admit I
do that mistake very often… :-)

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: org-src.el begin_src/end_src fontification may have been broken recently

[Ted Zlatanov]

On Sat, 11 Jun 2011 20:16:59 +0200 Julien Danjou <julien@danjou.info> wrote: 

JD> On Fri, Jun 10 2011, Ted Zlatanov wrote:
TZ> I'd really appreciate it if someone could review and maybe commit this
TZ> patch on the Emacs side (or I can commit it if necessary).  I don't
TZ> think it's an org-mode issue, but it could be breaking other people's
TZ> setups too because it triggers during fontification.
>> 
>> Julien, are you using that extra ":" because it's legitimate?  Or is it
>> an accident?  What should I do with my patch?

JD> Ah yes, probably a mistake.

JD> If you ask me, I'd say the syntax should allow both, but well, I admit I
JD> do that mistake very often… :-)

I'd say a mistake shouldn't break Gnus' article display :)  Can that be
fixed in org.el or in Gnus?  It seems to me org.el is the right place.

Ted

Re: org-src.el begin_src/end_src fontification may have been broken recently

[Štěpán Němec]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Sat, 11 Jun 2011 20:16:59 +0200 Julien Danjou <julien@danjou.info> wrote: 
>
>>> 
>>> Julien, are you using that extra ":" because it's legitimate?  Or is it
>>> an accident?  What should I do with my patch?
>
> JD> Ah yes, probably a mistake.
              ^^^^^^^^
              definitely

> JD> If you ask me, I'd say the syntax should allow both, but well, I admit I
> JD> do that mistake very often… :-)
>
> I'd say a mistake shouldn't break Gnus' article display :)  Can that be
> fixed in org.el or in Gnus?  It seems to me org.el is the right place.

What is there to fix in org.el? In Org, when you use some bogus
delimiter like #+begin_src:, the block simply won't work. If Gnus
article display is broken, it should obviously be fixed in Gnus, no?

BTW, if you can't remember the correct delimiters, why don't you make
yourself a template/skeleton or something? (In Org, typing `<s' and
pressing TAB will give you that, see (info "(org)Easy Templates").)

  Štěpán

Re: org-src.el begin_src/end_src fontification may have been broken recently

[Eric Schulte]

Štěpán Němec <stepnem@gmail.com> writes:

> Ted Zlatanov <tzz@lifelogs.com> writes:
>
>> On Sat, 11 Jun 2011 20:16:59 +0200 Julien Danjou <julien@danjou.info> wrote: 
>>
>>>> 
>>>> Julien, are you using that extra ":" because it's legitimate?  Or is it
>>>> an accident?  What should I do with my patch?
>>
>> JD> Ah yes, probably a mistake.
>               ^^^^^^^^
>               definitely
>
>> JD> If you ask me, I'd say the syntax should allow both, but well, I admit I
>> JD> do that mistake very often… :-)
>>
>> I'd say a mistake shouldn't break Gnus' article display :)  Can that be
>> fixed in org.el or in Gnus?  It seems to me org.el is the right place.
>
> What is there to fix in org.el? In Org, when you use some bogus
> delimiter like #+begin_src:, the block simply won't work. If Gnus
> article display is broken, it should obviously be fixed in Gnus, no?
>

I have the following altered function definition in my personal
configuration which fixes (well, papers over) the problem.

#+begin_src emacs-lisp
  (defun mm-display-org-inline (handle)
    "Show an Org mode text from HANDLE inline."
    (condition-case nil
        (mm-display-inline-fontify handle 'org-mode)
      (error (mm-insert-part handle))))
#+end_src

It is not clear to me why Org-mode fontification would only throw errors
when called from `mm-display-inline-fontify'.

Best -- Eric

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: org-src.el begin_src/end_src fontification may have been broken recently

[Ted Zlatanov]

On Mon, 13 Jun 2011 10:05:44 +0200 Štěpán Němec <stepnem@gmail.com> wrote: 

ŠN> Ted Zlatanov <tzz@lifelogs.com> writes:
>> I'd say a mistake shouldn't break Gnus' article display :)  Can that be
>> fixed in org.el or in Gnus?  It seems to me org.el is the right place.

ŠN> What is there to fix in org.el? In Org, when you use some bogus
ŠN> delimiter like #+begin_src:, the block simply won't work. If Gnus
ŠN> article display is broken, it should obviously be fixed in Gnus, no?

It throws an error during fontification, which is much harder to find
and debug than a normal error.  IMHO it should warn but not error out.

Also as I mentioned a valid mode that's not installed,
e.g. `haskell-mode', will also throw the error.  So it's not just a
matter of syntax.

It seems to me that org.el should be the one to avoid throwing an
error.  I could be wrong; if so we can use Eric's fix below.

ŠN> BTW, if you can't remember the correct delimiters, why don't you make
ŠN> yourself a template/skeleton or something? (In Org, typing `<s' and
ŠN> pressing TAB will give you that, see (info "(org)Easy Templates").)

Oh, I have ;)  The problem happens when the syntax is incorrect.  Here's
what I use, which picks up the mode automatically.

#+begin_src lisp
(defun tzz-copy-mode (mode)
  (cond
   ((member mode '("emacs-lisp"))
    "lisp")
   (t "text")))

(defun tzz-copy-region-with-mode-property (beg end)
  (interactive "r")
  (let ((text (buffer-substring beg end))
        (mode (symbol-name major-mode)))
    (with-temp-buffer
      (insert text)
      (goto-char (point-min))
      (insert "#+begin_src"
              (if (string-match "\\(.+\\)-mode" mode)
                  (concat " " (tzz-copy-mode (match-string 1 mode)))
                "")
              "\n")
      (goto-char (point-max))
      (insert "\n"
              "#+end_src"
              "\n")
      (copy-region-as-kill (point-min) (point-max)))))
#+end_src

On Mon, 13 Jun 2011 07:38:31 -0700 Eric Schulte <schulte.eric@gmail.com> wrote: 

ES> I have the following altered function definition in my personal
ES> configuration which fixes (well, papers over) the problem.
#+begin_src emacs-lisp
  (defun mm-display-org-inline (handle)
    "Show an Org mode text from HANDLE inline."
    (condition-case nil
        (mm-display-inline-fontify handle 'org-mode)
      (error (mm-insert-part handle))))
#+end_src

ES> It is not clear to me why Org-mode fontification would only throw errors
ES> when called from `mm-display-inline-fontify'.

I'm OK with your fix but also wonder if org.el should be throwing errors
during fontification.  Julien, since you added this to Gnus, can you
please decide on the best place to fix it?

Ted

Re: org-src.el begin_src/end_src fontification may have been broken recently

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 508 bytes --]

On Mon, Jun 13 2011, Ted Zlatanov wrote:

> I'm OK with your fix but also wonder if org.el should be throwing errors
> during fontification.  Julien, since you added this to Gnus, can you
> please decide on the best place to fix it?

To me this is an Org bug and it should be fixed in Org. We can
definitively hides it in Gnus with `ignore-errors', but I think it would
not help anyone to understand why the hell a fontification is not
working.

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: org-src.el begin_src/end_src fontification may have been broken recently

[Ted Zlatanov]

On Tue, 14 Jun 2011 11:41:13 +0200 Julien Danjou <julien@danjou.info> wrote: 

JD> On Mon, Jun 13 2011, Ted Zlatanov wrote:
>> I'm OK with your fix but also wonder if org.el should be throwing errors
>> during fontification.  Julien, since you added this to Gnus, can you
>> please decide on the best place to fix it?

JD> To me this is an Org bug and it should be fixed in Org. We can
JD> definitively hides it in Gnus with `ignore-errors', but I think it would
JD> not help anyone to understand why the hell a fontification is not
JD> working.

Could you propose a patch to the Org authors?  Do you want me to do it?

Thanks
Ted

Re: org-src.el begin_src/end_src fontification may have been broken recently

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 899 bytes --]

On Tue, Jun 14 2011, Ted Zlatanov wrote:

> On Tue, 14 Jun 2011 11:41:13 +0200 Julien Danjou <julien@danjou.info> wrote: 
>
> JD> On Mon, Jun 13 2011, Ted Zlatanov wrote:
>>> I'm OK with your fix but also wonder if org.el should be throwing errors
>>> during fontification.  Julien, since you added this to Gnus, can you
>>> please decide on the best place to fix it?
>
> JD> To me this is an Org bug and it should be fixed in Org. We can
> JD> definitively hides it in Gnus with `ignore-errors', but I think it would
> JD> not help anyone to understand why the hell a fontification is not
> JD> working.
>
> Could you propose a patch to the Org authors?  Do you want me to do it?

Well, since you've started digging into the code, and I don't have much
time right now, I'd be happy to review and merge your patch into Org. ;-)

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: org-src.el begin_src/end_src fontification may have been broken recently

[Ted Zlatanov]

[-- Attachment #1: Type: text/plain, Size: 403 bytes --]

On Wed, 15 Jun 2011 10:12:26 +0200 Julien Danjou <julien@danjou.info> wrote: 

JD> On Tue, Jun 14 2011, Ted Zlatanov wrote:
>> Could you propose a patch to the Org authors?  Do you want me to do it?

JD> Well, since you've started digging into the code, and I don't have much
JD> time right now, I'd be happy to review and merge your patch into Org. ;-)

The patch is truly trivial, see attached.

Ted


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: org-src-fontification.patch --]
[-- Type: text/x-diff, Size: 524 bytes --]

=== modified file 'lisp/org/org.el'
--- lisp/org/org.el	2011-05-23 17:57:17 +0000
+++ lisp/org/org.el	2011-06-15 14:54:19 +0000
@@ -5096,6 +5096,11 @@
   :group 'org-babel)
 
 (defun org-fontify-meta-lines-and-blocks (limit)
+  (condition-case nil
+      (org-fontify-meta-lines-and-blocks-1 limit)
+    (error (message "org-mode fontification error"))))
+
+(defun org-fontify-meta-lines-and-blocks-1 (limit)
   "Fontify #+ lines and blocks, in the correct ways."
   (let ((case-fold-search t))
     (if (re-search-forward

Re: org-src.el begin_src/end_src fontification may have been broken recently

[Bastien]

Ted Zlatanov <tzz@lifelogs.com> writes:

> The patch is truly trivial, see attached.

Thanks Ted for the patch, and Julien for applying it!

-- 
 Bastien

Re: just-the-text Emacs frame

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 534 bytes --]

On Fri, Jun 03 2011, Jan Djärv wrote:

> 1) It can all be done in Lisp in a current Emacs without code modifications
> (well you have to unmap and remap for window type to take effect, so that is
> a bit ugly).

Do you mean the X primitive are accessible from Lisp? I never saw that
in Emacs, so pointer appreciated!

> 2) Strut is intended for pagers, panel and such, Emacs is not that kind of
> application.

But it could be. I don't see why it could not at least.

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: just-the-text Emacs frame

[Jan Djärv]

Julien Danjou skrev 2011-06-06 10.32:
> On Fri, Jun 03 2011, Jan Djärv wrote:
>
>> 1) It can all be done in Lisp in a current Emacs without code modifications
>> (well you have to unmap and remap for window type to take effect, so that is
>> a bit ugly).
>
> Do you mean the X primitive are accessible from Lisp? I never saw that
> in Emacs, so pointer appreciated!
>

See the other messages in this thread about MotifWMHints.

	Jan D.

Re: Emacs as a desktop environment

[Tom Tromey]

Ted> No, that's going the other way.  I want an Emacs instance to *be* the
Ted> system tray (and workspace indicator, and basically everything that
Ted> makes a desktop environment except the window manager and the
Ted> applications themselves).

Ah.

Ted> Can the system tray interface be implemented
Ted> as a protocol or does it need C code?

I believe tray icons still need C code, or at least some proxy; e.g., it
could probably be done by embedding a bunch of PyGtk code in the elisp
(my approach is hacked up version of "zenity").  In the Gnome 3 shell
maybe the same effect can be had via javascript, I'm not sure.

Tom

taking over global key events (X, NS, W32) (was: Emacs as a desktop environment)

[Ted Zlatanov]

On Tue, 24 May 2011 20:05:28 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> I think GNU Emacs, at least on GNU/Linux systems, can provide much of
TZ> the desktop environment functionality, so Emacs + a window manager like
TZ> XMonad is a full desktop experience
...
TZ> I'd like to know how much of this can be achieved with today's GNU Emacs
TZ> plus the external packages (GNU ELPA, Tom Tromey's ELPA, EmacsWiki,
TZ> etc.) available, and how much will require new packages or changes to
TZ> Emacs' internals.

Can Emacs register to handle some global key events in the X, NS, and
W32 environments, for when it doesn't have the keyboard focus?

Thanks
Ted

Re: taking over global key events (X, NS, W32)

[joakim]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Tue, 24 May 2011 20:05:28 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: 
>
> TZ> I think GNU Emacs, at least on GNU/Linux systems, can provide much of
> TZ> the desktop environment functionality, so Emacs + a window manager like
> TZ> XMonad is a full desktop experience
> ...
> TZ> I'd like to know how much of this can be achieved with today's GNU Emacs
> TZ> plus the external packages (GNU ELPA, Tom Tromey's ELPA, EmacsWiki,
> TZ> etc.) available, and how much will require new packages or changes to
> TZ> Emacs' internals.
>
> Can Emacs register to handle some global key events in the X, NS, and
> W32 environments, for when it doesn't have the keyboard focus?

I'm also interested in this for my Inkmacs project. The easiest way so
far was using the DBus bindings to catch the multimedia keys, which is a
bit limited. I also tried using the Gnome hotkeys to bind it to a
dispatcher, but that was so far not successful in Gnome 3 although it
used to sort of work in earlier Gnomes.

Here's some dbus code. (BTW Emacs dbus support is great!)

(provide 'emms-dbus)
(require 'dbus)


(defun emms-dbus-signal-handler (msg1 signal-name)
  (message "emms-dbus-signal-handler %s %s" msg1 signal-name)
  ;Play Stop Next Previous
  ;emms-seek-forward
  ;emms-next
  (cond
   ((equal "Next" signal-name)
    (emms-next))
   ((equal "Previous" signal-name)
    (emms-previous))
   ((equal "Stop" signal-name)
    (emms-stop))
   ((equal "Play" signal-name)
    (emms-pause))
   )
  )

(dbus-register-signal
 :session ;bus
 nil; "org.gnome.SettingsDaemon.MediaKeys" ;service
 nil; "/org/gnome/SettingsDaemon/MediaKeys" ;path
 "org.gnome.SettingsDaemon.MediaKeys" ;interface
 "MediaPlayerKeyPressed" ;signal
 'emms-dbus-signal-handler ;handler
 )

>
> Thanks
> Ted
>

-- 
Joakim Verona

Re: taking over global key events (X, NS, W32)

[Mathias Dahl]

> I'm also interested in this for my Inkmacs project. The easiest way so
> far was using the DBus bindings to catch the multimedia keys, which is a
> bit limited. I also tried using the Gnome hotkeys to bind it to a
> dispatcher, but that was so far not successful in Gnome 3 although it
> used to sort of work in earlier Gnomes.

If it turns out that it would be unsuitable to have Emacs listen
"globally" like this,
maybe a small program can be written to do the listening, sending dbus commands
that Emacs (or whoever else is listening) on the bus?

Just an idea.

Re: taking over global key events (X, NS, W32)

[Ted Zlatanov]

On Mon, 13 Jun 2011 21:22:46 +0200 Mathias Dahl <mathias.dahl@gmail.com> wrote: 

>> I'm also interested in this for my Inkmacs project. The easiest way so
>> far was using the DBus bindings to catch the multimedia keys, which is a
>> bit limited. I also tried using the Gnome hotkeys to bind it to a
>> dispatcher, but that was so far not successful in Gnome 3 although it
>> used to sort of work in earlier Gnomes.

MD> If it turns out that it would be unsuitable to have Emacs listen
MD> "globally" like this,
MD> maybe a small program can be written to do the listening, sending dbus commands
MD> that Emacs (or whoever else is listening) on the bus?

I would prefer a native interface, since there are other uses besides
mine.  For instance Emacs could have a global hide/show (HUD mode, like
Guake, yakuake, tilda, and other terminals provide) key.  It's best to
provide this inside Emacs itself IMO for the sake of all the potential
users, especially on the NS and W32 platforms.

Ted