[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC: status icon support
From: |
YAMAMOTO Mitsuharu |
Subject: |
Re: RFC: status icon support |
Date: |
Wed, 16 Jan 2008 20:55:04 +0900 (JST) |
>>>>> On Tue, 15 Jan 2008 18:17:05 -0700, Tom Tromey <address@hidden> said:
>>> A tool bar is represented as a keymap. If status icons are
>>> similar to tool bar icons (application-level as opposed to
>>> frame-level), the use of the keymap data structure looks more
>>> consistent to me.
> Thanks for responding. I've been thinking about this a bit, and I
> don't understand the benefits of this versus just using a simple
> cons. (I do understand, I think, why you would prefer not to make a
> new type.)
I think it would be obviously beneficial if the same data structure is
used for similar concepts (I'm not so familiar with status icons, so
please point out if they are not so similar to tool bar icons). Emacs
Lisp programmers who have get used to the tool bars can easily
learn/imagine how to operate on the status icons. Some implementation
codes can be shared and that reduces the chance of bugs. Also, there
would be possible to complement some missing features in tool bars by
analogy from those in status icons.
> Also, I do not know how to implement this.
You can look at the implementation of tool bars. Of course, it's not
as easy as creating some black-box Lisp objects for GTK+ objects and
direct bridges/wrappers to GTK+ functions. It might be helpful to
understand the basic strategy of Emacs redisplay:
* Lisp functions basically modify buffers and/or Lisp data
structures (i.e., models), but don't usually do immediate display
operations. (Of course, there are several exceptions.)
* When `redisplay' is triggered, it calculates the changes from the
previous redisplay in the models and do appropriate display
operations.
YAMAMOTO Mitsuharu
address@hidden
Re: RFC: status icon support, YAMAMOTO Mitsuharu, 2008/01/13
Re: RFC: status icon support, Richard Stallman, 2008/01/14