From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
To: tromey@redhat.com
Cc: emacs-devel@gnu.org
Subject: Re: RFC: status icon support
Date: Wed, 16 Jan 2008 20:55:04 +0900 (JST) [thread overview]
Message-ID: <20080116.205504.254233330.mituharu@math.s.chiba-u.ac.jp> (raw)
In-Reply-To: <m3myr6bmcu.fsf@fleche.redhat.com>
>>>>> On Tue, 15 Jan 2008 18:17:05 -0700, Tom Tromey <tromey@redhat.com> 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
mituharu@math.s.chiba-u.ac.jp
next prev parent reply other threads:[~2008-01-16 11:55 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-11 23:28 RFC: status icon support Tom Tromey
2008-01-12 1:57 ` Dan Nicolaescu
2008-01-12 1:28 ` Tom Tromey
2008-01-12 1:38 ` Tom Tromey
2008-01-12 8:45 ` Ulrich Mueller
2008-01-12 17:45 ` Tom Tromey
2008-01-14 2:01 ` Richard Stallman
2008-01-14 1:35 ` Tom Tromey
2008-01-14 17:26 ` Richard Stallman
2008-01-19 5:18 ` Tom Tromey
2008-01-20 6:14 ` Richard Stallman
2008-01-23 4:00 ` Michael Olson
2008-01-14 1:41 ` Tom Tromey
2008-01-14 1:03 ` Michael Olson
2008-01-14 1:01 ` Tom Tromey
2008-01-14 7:03 ` Jan Djärv
2008-01-15 6:01 ` Michael Olson
2008-01-16 1:10 ` Tom Tromey
2008-01-16 4:10 ` Michael Olson
2008-01-12 11:11 ` Richard Stallman
2008-01-12 11:25 ` David Kastrup
2008-01-12 11:27 ` Andreas Schwab
2008-01-12 11:46 ` David Kastrup
2008-01-12 14:10 ` Andreas Schwab
2008-01-12 14:19 ` David Kastrup
2008-01-12 17:33 ` Andreas Schwab
2008-01-14 2:00 ` Richard Stallman
2008-01-14 2:25 ` Stefan Monnier
2008-01-14 7:05 ` Jan Djärv
2008-01-12 13:52 ` Dan Nicolaescu
2008-01-12 14:13 ` Andreas Schwab
2008-01-12 14:26 ` Dan Nicolaescu
2008-01-12 17:36 ` Andreas Schwab
2008-01-12 18:59 ` Dan Nicolaescu
2008-01-12 14:33 ` David Kastrup
2008-01-12 17:45 ` Andreas Schwab
2008-01-12 18:07 ` David Kastrup
2008-01-12 18:16 ` Andreas Schwab
2008-01-14 2:01 ` Richard Stallman
2008-01-14 2:47 ` Dan Nicolaescu
2008-01-14 17:26 ` Richard Stallman
2008-01-14 9:14 ` David Kastrup
2008-01-14 17:26 ` Richard Stallman
2008-01-14 3:47 ` YAMAMOTO Mitsuharu
2008-01-14 3:49 ` Tom Tromey
2008-01-14 13:35 ` Stefan Monnier
2008-01-14 21:40 ` YAMAMOTO Mitsuharu
2008-01-16 1:17 ` Tom Tromey
2008-01-16 11:55 ` YAMAMOTO Mitsuharu [this message]
2008-01-14 17:26 ` Richard Stallman
2008-01-14 17:10 ` Tom Tromey
2008-01-16 2:42 ` Richard Stallman
-- strict thread matches above, loose matches on Subject: below --
2007-12-30 19:56 Tom Tromey
2007-12-31 17:18 ` Dan Nicolaescu
2007-12-31 18:29 ` Tom Tromey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080116.205504.254233330.mituharu@math.s.chiba-u.ac.jp \
--to=mituharu@math.s.chiba-u.ac.jp \
--cc=emacs-devel@gnu.org \
--cc=tromey@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.