Gtk version getting closer

Gtk version getting closer

[Jan D.]

Hello.

I am getting closer to getting a Gtk version done.  I estimate I can
check in something useful in a week or two.

I have some questions about how to proceed.

Shall the code be reviewed by this list or any individual before
a possible checkin?

Does this go in a separate branch (how do you "branch" new files) or
directly to CVS latest?  It should not have any impact on current
toolkits, but perhaps better safe than sorry?

Which version of autoconf is the recommended?  Does that version have
builtin tests for Gtk?  If not, is it OK to add a aclocal.m4 file
with those tests?  I think there was such a file previously, but it
is now gone.

I would like to finish dialogs and a scrolling problem (repeat doesn't
work, some bad interaction with Gtk and Emacs timers) before I start
to merge it into CVS latest.  I am currently working off a CVS from
the middle of June.  If I got the time, I will rewrite the
file dialog from Gtk and hopefully it will be accepted into Gtk proper.
If not, I plan to just put it in Emacs (the Gtk file dialog crashes
Emacs if the current directory contains a Latin-1, or rather non-UTF8,
character).

This port tries to reuse as much as it can of current X code, so
it is very dependent on X.  For example, all drawing is done with
standard X calls.  The event loop is mostly unmodified (split into
two functions, but no major code changes).
This makes this a bit of a bastard when it comes to X resources.
For example, geometry is taken from X resources, but fonts and
colours for Gtk widgets must be specified in the Gtk way (~/.gtkrc-2.0).

The toolbar is not a Gtk toolbar, it is the standard Emacs toolbar. 
I haven't decided if I will try to change that, the advantage would
be the possibility to have a detachable toolbar.  There are detachable
menus already, except detaching popup menus does not work, I don't
know why yet.  Menus could be optimized, it currently rebuilds the
whole tree when menus change, this is not optimal.

I am also not sure if I will do tooltips in menus, I find that to be a bit
of a strange user interface solution.  Mac OSX does not have them
for example.

There are probably tons of bugs, but the more that can run this, the
faster they will be found.  Also, I wan't to get this in such a
shape I can start doing all the other things I have on my TODO list :-)

Thanks,

	Jan D.

Re: Gtk version getting closer

[Kim F. Storm]

"Jan D." <jan.h.d@swipnet.se> writes:

> Hello.
> 
> I am getting closer to getting a Gtk version done.  I estimate I can
> check in something useful in a week or two.

This is good news.

> Does this go in a separate branch (how do you "branch" new files) or
> directly to CVS latest?  It should not have any impact on current
> toolkits, but perhaps better safe than sorry?

Personally, I would prefer if we could release 21.3, make a new branch 
for 21.4, and then you could merge the Gtk support for 21.5 (or whatever
it will be called at that time)...

> There are probably tons of bugs, but the more that can run this, the
> faster they will be found. 

And the more we will delay releasing 21.4 unless we do at I propose
above...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Gtk version getting closer

[jasonr]

> Personally, I would prefer if we could release 21.3, make a new branch 
> for 21.4, and then you could merge the Gtk support for 21.5 (or whatever
> it will be called at that time)...

I don't think we want to make MORE branches. If it is not judged safe
enough to go in 21.4, then it should go straight into the unicode branch IMO. 
We clearly don't have enough resources to keep two new feature branches
and one maintenance branch going at once. I think it is better to
concentrate our non-bugfixing efforts on the unicode branch after
21.4 is released if we want to see it released this decade.

Re: Gtk version getting closer

[Juanma Barranquero]

On Fri, 8 Nov 2002 09:21:03 +0000 (GMT), jasonr@btinternet.com wrote:

> > Personally, I would prefer if we could release 21.3, make a new branch 
> > for 21.4, and then you could merge the Gtk support for 21.5 (or whatever
> > it will be called at that time)...
> 
> I don't think we want to make MORE branches.

I think Kim meant to:

 - release 21.3, and abandon the EMACS_21_1_RC branch forever
 - branch a new EMACS_21_4_RC for the next release
 - apply the Gtk patch to the trunk

so there would be only two "branches" of development, as there are now:
one for the next release, and another one for development.


                                                           /L/e/k/t/u

Re: Gtk version getting closer

[Juanma Barranquero]

On 08 Nov 2002 12:25:19 +0100, storm@cua.dk (Kim F. Storm) wrote:

> I think the unicode branch should be merged to the trunk (shortly)
> after making the 21.4 RC branch -- meaning ONE LESS branch for
> development!

So all succesive releases from the 21_4_RC branch would be only bug
fixes, and the next "features" release, from the trunk, would be 22.1,
you mean?

Neat.

                                                           /L/e/k/t/u

Re: Gtk version getting closer

[Kim F. Storm]

Juanma Barranquero <lektu@terra.es> writes:

> On Fri, 8 Nov 2002 09:21:03 +0000 (GMT), jasonr@btinternet.com wrote:
> 
> > > Personally, I would prefer if we could release 21.3, make a new branch 
> > > for 21.4, and then you could merge the Gtk support for 21.5 (or whatever
> > > it will be called at that time)...
> > 
> > I don't think we want to make MORE branches.
> 
> I think Kim meant to:
> 
>  - release 21.3, and abandon the EMACS_21_1_RC branch forever
>  - branch a new EMACS_21_4_RC for the next release
>  - apply the Gtk patch to the trunk
> 
> so there would be only two "branches" of development, as there are now:
> one for the next release, and another one for development.

Exactly!  The EMACS_21_4_RC branch would be for bug fix releases to 21.4 only.

I think the unicode branch should be merged to the trunk (shortly)
after making the 21.4 RC branch -- meaning ONE LESS branch for
development!

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Gtk version getting closer

[Richard Stallman]

    Shall the code be reviewed by this list or any individual before
    a possible checkin?

Please send the patches here so everyone can look.

    Does this go in a separate branch (how do you "branch" new files) or
    directly to CVS latest?

We could do it either way.  If you have tested building with another
toolkit, and it still works, then I don't see a need for a branch.
However, if you want to make it a branch, I don't think that is
horrible.

    Which version of autoconf is the recommended?  Does that version have
    builtin tests for Gtk?

I don't think we need one.  We don't want to make Gtk the default
at this stage.

    The toolbar is not a Gtk toolbar, it is the standard Emacs toolbar. 

That is ok for now.

    I am also not sure if I will do tooltips in menus, I find that to be a bit
    of a strange user interface solution.

I think they are important.

Re: Gtk version getting closer

[Jan D.]

> 
>     Shall the code be reviewed by this list or any individual before
>     a possible checkin?
> 
> Please send the patches here so everyone can look.

I will do that shortly, probably within a week.

> 
>     Does this go in a separate branch (how do you "branch" new files) or
>     directly to CVS latest?
> 
> We could do it either way.  If you have tested building with another
> toolkit, and it still works, then I don't see a need for a branch.
> However, if you want to make it a branch, I don't think that is
> horrible.

I would rather not make a branch.  I will make sure all other toolkits
on Unix works.

>     Which version of autoconf is the recommended?  Does that version have
>     builtin tests for Gtk?
> 
> I don't think we need one.  We don't want to make Gtk the default
> at this stage.

I was thinking of the code that autoconf needs to detect the path to Gtk
and that the version of Gtk is correct, in case the user specified --with-gtk
to configure.  If we are using an autoconf that doesn't have this built in,
I need to create an aclocal.m4 with that code.  Since I know there was such
a file previously but now is removed, I would like to know if it is okay
to create one again.  I don't know the reason why it was removed.  It can
be as easy as it was redundant, but there might be some other reason.

> 
>     The toolbar is not a Gtk toolbar, it is the standard Emacs toolbar. 
> 
> That is ok for now.

A Gtk toolbar can be added later on I guess.  I think Gtk/Gnome users
expect the toolbar to pick up their Gtk theme, so I will raise the
priority for this.  I don't use the toolbar, so it is not important for
me.

> 
>     I am also not sure if I will do tooltips in menus, I find that to be a bit
>     of a strange user interface solution.
> 
> I think they are important.

For the toolbar I agree.  Icons can mean many things, so a tooltip helps.
For menus, however, the text in the menu should be enough or expanded
so the tip is not needed.  I'll see what I can do, but they might not make
it into the first patch.  A cutomize variable to turn tooltips off just
in menus is something I would like to add later on.

	Jan D.

Re: Gtk version getting closer

[Jan D.]

> 
> Exactly!  The EMACS_21_4_RC branch would be for bug fix releases to 21.4 only.
> 
> I think the unicode branch should be merged to the trunk (shortly)
> after making the 21.4 RC branch -- meaning ONE LESS branch for
> development!

If this is the way to do it, then the 21.4 RC branch should start very soon
I think.  Gtk would then go into 21.5 and the unicode trunk I guess?

	Jan D.

Re: Gtk version getting closer

[Karl Eichwalder]

Richard Stallman <rms@gnu.org> writes:

>     I am also not sure if I will do tooltips in menus, I find that to be a bit
>     of a strange user interface solution.
>
> I think they are important.

Yes, but current behavior is a little bit disturbing.  Often you can
"right-click" (= mouse-3 resp. mouse-2 in Emacs) on some such entities
like menu entries to couse a context menu with a help entry to appear.

-- 
ke@suse.de (work) / keichwa@gmx.net (home):              |
http://www.gnu.franken.de/ke/                            |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)

Re: Gtk version getting closer

[Eli Zaretskii]

> From: storm@cua.dk (Kim F. Storm)
> Date: 08 Nov 2002 01:08:43 +0100
> 
> > There are probably tons of bugs, but the more that can run this, the
> > faster they will be found. 
> 
> And the more we will delay releasing 21.4 unless we do at I propose
> above...

If the Gtk version is not built by default and if it doesn't screw
other toolkits, we don't need to be afraid of that.

Re: Gtk version getting closer

[Eli Zaretskii]

> From: "Jan D." <jan.h.d@swipnet.se>
> Date: Thu, 7 Nov 2002 20:39:07 +0100 (CET)
> 
> This port tries to reuse as much as it can of current X code, so
> it is very dependent on X.  For example, all drawing is done with
> standard X calls.  The event loop is mostly unmodified (split into
> two functions, but no major code changes).

Does this mean the code won't work with the Windows port of Gtk?

Re: Gtk version getting closer

[Jan D.]

> 
> > From: "Jan D." <jan.h.d@swipnet.se>
> > Date: Thu, 7 Nov 2002 20:39:07 +0100 (CET)
> > 
> > This port tries to reuse as much as it can of current X code, so
> > it is very dependent on X.  For example, all drawing is done with
> > standard X calls.  The event loop is mostly unmodified (split into
> > two functions, but no major code changes).
> 
> Does this mean the code won't work with the Windows port of Gtk?

I assume it does not work with MS Windows.  X specific calls in Gtk
are used, as well as a lot of X calls in the ordinary Emacs code for X.

The goal has been to reuse as much code unchanged as possible (see
http://mail.gnu.org/pipermail/emacs-devel/2001-December/004383.html).

Since I don't do MS Windows I don't know what effort would
be required to make it work.  If one used only Gtk code instead of
Xlib I assume it would run on MS Windows as well.  This is what I
started to do, but then changed to the current X specific approach.

	Jan D.

Re: Gtk version getting closer

[Richard Stallman]

    Yes, but current behavior is a little bit disturbing.

Could you explain what is disturbing about it?  Then I can
think about the issue.

							   Often you can
    "right-click" (= mouse-3 resp. mouse-2 in Emacs) on some such entities
    like menu entries to couse a context menu with a help entry to appear.

You can often do this in Emacs, or you can often do this in other
programs?

Re: Gtk version getting closer

[Richard Stallman]

    I was thinking of the code that autoconf needs to detect the path to Gtk
    and that the version of Gtk is correct, in case the user specified --with-gtk
    to configure.  If we are using an autoconf that doesn't have this built in,
    I need to create an aclocal.m4 with that code.

There is no need for an aclocal.m4.  You can put the code directly
into configure.in.  That is how we handle other such issues.

    >     The toolbar is not a Gtk toolbar, it is the standard Emacs toolbar. 
    > 
    > That is ok for now.

    A Gtk toolbar can be added later on I guess.  I think Gtk/Gnome users
    expect the toolbar to pick up their Gtk theme, so I will raise the
    priority for this.

Yes, we definitely want to have it, but we could make a first release
without it.

    For menus, however, the text in the menu should be enough or expanded
    so the tip is not needed.  I'll see what I can do, but they might not make
    it into the first patch.  A cutomize variable to turn tooltips off just
    in menus is something I would like to add later on.

If Emacs supports tooltips in menus for other toolkits, that should
work with GTK too if possible.

Re: Gtk version getting closer

[Richard Stallman]

    > Does this mean the code won't work with the Windows port of Gtk?

    I assume it does not work with MS Windows.  X specific calls in Gtk
    are used, as well as a lot of X calls in the ordinary Emacs code for X.

    The goal has been to reuse as much code unchanged as possible (see
    http://mail.gnu.org/pipermail/emacs-devel/2001-December/004383.html).

    Since I don't do MS Windows I don't know what effort would
    be required to make it work.  If one used only Gtk code instead of
    Xlib I assume it would run on MS Windows as well.  This is what I
    started to do, but then changed to the current X specific approach.

I think that is an ok approach.

Re: Gtk version getting closer

[Karl Eichwalder]

Richard Stallman <rms@gnu.org> writes:

> Could you explain what is disturbing about it?  Then I can
> think about the issue.

Tooltips are poping up and hiding other info.  As somebody else
explained, for menu entries tooltips are not that important, because
menu texts are better to understand than tool bar icons.

Yes, one can get used to the tooltips and their texts are often very
good; nevertheless having an option to disable menu entry tooltips
separately would be nice.

> 							   Often you can
>     "right-click" (= mouse-3 resp. mouse-2 in Emacs) on some such entities
>     like menu entries to couse a context menu with a help entry to appear.
>
> You can often do this in Emacs, or you can often do this in other
> programs?

I know you can often call a context menu in Emacs, but it's impossible
to jump from a menu entry directly to the manual where this menu entry
will be explained.

-- 
ke@suse.de (work) / keichwa@gmx.net (home):              |
http://www.gnu.franken.de/ke/                            |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)

Re: Gtk version getting closer

[Eli Zaretskii]

On Mon, 11 Nov 2002, Karl Eichwalder wrote:

> As somebody else
> explained, for menu entries tooltips are not that important, because
> menu texts are better to understand than tool bar icons.

Where the menu item's text is self-explanatory, there usually is no 
tooltip that pops up.  In other words, tooltips for menu items should be 
defined only where they are really needed.

> I know you can often call a context menu in Emacs, but it's impossible
> to jump from a menu entry directly to the manual where this menu entry
> will be explained.

You should be able to do a "C-h k", then click the menu item and get its 
explanation.  Another C-h function jumps to the manual for a description 
of any key, but the problem in using this with menu items is that menu 
items are generally not described at all in the manual.  So this is a 
documentation problem rather than a functionality problem; if someone 
writes an appendix for the manual with the description of all the menu 
items, it would be instantly available for the purpose you want it.

Re: Gtk version getting closer

[Karl Eichwalder]

Eli Zaretskii <eliz@is.elta.co.il> writes:

> Where the menu item's text is self-explanatory, there usually is no 
> tooltip that pops up.  In other words, tooltips for menu items should be 
> defined only where they are really needed.

That's even worth ;)  If you want to sell a product consistency is an
important issue.  The ideal goal should be: all or nothing.  If
tooltips appear only now and then, the user might think there is
something broken.

> You should be able to do a "C-h k", then click the menu item and get its 
> explanation.

Sure, that's a good way for the advanced user (to be more precise: for
the keyboard user).  You are not going to convince the mouse user he
wants to learn those key combos ;-)

> Another C-h function jumps to the manual for a description of any key,
> but the problem in using this with menu items is that menu items are
> generally not described at all in the manual.  So this is a
> documentation problem rather than a functionality problem;

Yes and no.  For the moment it would be good enough if Emacs would jump
to the documentation of the function; just print a message want you
intend to do.

> if someone writes an appendix for the manual with the description of
> all the menu items, it would be instantly available for the purpose
> you want it.

Sounds useful.  Maybe, I can spend some time on it next year.  Is it
okay to write it in German and to wait for someone to translate it?  Or
shall I try it in English and hope for corrections?

-- 
ke@suse.de (work) / keichwa@gmx.net (home):              |
http://www.gnu.franken.de/ke/                            |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)

Re: Gtk version getting closer

[Jan D.]

> Where the menu item's text is self-explanatory, there usually is no 
> tooltip that pops up.  In other words, tooltips for menu items should be 
> defined only where they are really needed.
> 

This isn't always the case.  Maybe the help texts should be
reviewed and expanded/removed as a result?  For example,
in Options we have:
  "Save Place in Files between Sessions"

The tooltip for that is "Save Emacs state for next session".
I think that the menu entry is much clearer hear, the tip is confusing.

Much of the tips doesn't add anything IMHO.  If a user has used any
other GUI-based application, things such as "Open File", "Insert File",
"Save As" does not need any tip.

Sometimes the tips uses a different concept than the menu item.  In
the Tools -> PCL-CVS submenu, we have "Examine Directory".  The tip
says "Examine the current state of a workarea".  Directory is
understandable, but what is workarea?  If it is the same as directory,
why not use directory?  The PCL-CVS submenu itself can be made clearer
by renaming it to "CVS operations" or something like that.

Also, there is the problem with inconsistency.  Some menu items have
tips, other doesn't as pointed out elsewhere.  I do agree with the
view that the user might think something is broken when no tips
appear for some things.  For submenus there are no tips.  The PCL-CVS
entry could use one, since PCL-CVS is kind of cryptic.  But of course
I'd prefer PCL-CVS to be renamed in the menu instead.

The tips appear in the wrong places (i.e. under the pointer)
sometimes.  I don't have a Lucid version available, but in the Motif and
Gtk version you can click and release on a menubar item to make the menu
appear.  Then you can navigate the menus with arrow keys.  The
tip displayed is for the menu item marked with the arrow keys, but
the tip appears where the pointer is.  The pointer can be on the other side
of the screen, so this looks funny.

I do think tips can have a negative effect on menu item strings.  It is
too easy to make a menu with cryptic strings and then fully explain the
items in the tip instead.  This forces the user to select the menu item
and then wait for the tip to appear for the full explanation.  If tips
did not exist, more thought would be going into selecting good
menu item strings.

I really would like to see tips for menus removed, but a customize
item to turn them off for menus is okay too.

	Jan D.

Re: Gtk version getting closer

[Eli Zaretskii]

> From: Karl Eichwalder <keichwa@gmx.net>
> Date: Tue, 12 Nov 2002 08:24:23 +0100
> 
> If you want to sell a product consistency is an
> important issue.  The ideal goal should be: all or nothing.  If
> tooltips appear only now and then, the user might think there is
> something broken.

I see the point, but I actually thought about this before and I
disagree.  I find it disgusting when a GUI program sticks into my face
a tooltip that doesn't add any useful information.  I think Emacs's
paradigm is better.

> > You should be able to do a "C-h k", then click the menu item and get its 
> > explanation.
> 
> Sure, that's a good way for the advanced user (to be more precise: for
> the keyboard user).  You are not going to convince the mouse user he
> wants to learn those key combos ;-)

Each of those C-h functions has a menubar equivalent; see the "Help"
menu and its submenus.

> For the moment it would be good enough if Emacs would jump
> to the documentation of the function; just print a message want you
> intend to do.

But that's just it: there _is_ no documentation for those functions,
only doc strings (and even those are sometimes absent, since some of
the menu items invoke lambda-expressions).

> Is it
> okay to write it in German and to wait for someone to translate it?  Or
> shall I try it in English and hope for corrections?

I think it's better to write English.  It's much easier for someone to
fix English than to translate from German.

Re: Gtk version getting closer

[Eli Zaretskii]

> From: "Jan D." <jan.h.d@swipnet.se>
> Date: Tue, 12 Nov 2002 13:34:06 +0100 (MET)
> 
> Maybe the help texts should be reviewed and expanded/removed as a
> result?

Yes, of course.

> Also, there is the problem with inconsistency.  Some menu items have
> tips, other doesn't as pointed out elsewhere.  I do agree with the
> view that the user might think something is broken when no tips
> appear for some things.  For submenus there are no tips.

I think most of the problems are with menus defined by packages
outside menu-bar.el.  In particular, packages maintained by their own
maintainers.  I do agree that consistency is important (provided that
we agree about what should tooltips in menus do ;-).

> I do think tips can have a negative effect on menu item strings.  It is
> too easy to make a menu with cryptic strings and then fully explain the
> items in the tip instead.

The main reason for tooltips in menus is that menu items are usually
limited in length.  Tooltips can be longer, especially since the font
used for them is (or should be) smaller.

Re: Gtk version getting closer

[Miles Bader]

Karl Eichwalder <keichwa@gmx.net> writes:
> > Where the menu item's text is self-explanatory, there usually is no
> > tooltip that pops up.  In other words, tooltips for menu items
> > should be defined only where they are really needed.
> 
> That's even worth ;)  If you want to sell a product consistency is an
> important issue.  The ideal goal should be: all or nothing.  If
> tooltips appear only now and then, the user might think there is
> something broken.

Tooltips in Gnome (at least on my system!) are often `consistent' to the
point of stupidity:  in many cases a tooltip is popped up with _exactly_
the same text as the menu item or for icons, the same text repeated
_twice_ in the tooltip (presumably one line is the `label' and the other
is the `description')!  This not only seems odd, it seems broken.
Clearly in many cases it's really the fault of the application or the
user that added an icon or whatever without a good description -- but
that's the real world, such things exist.

Perhaps it would be better to could pop up a tooltip that says
`This tooltip intentionally left blank'...

The way I use tooltips is to pause over something and wait to see if
something pops up; if nothing does, I just think `oh there's no tooltip
for that.'  Maybe I'm wierd, but since I gained this habit by using
non-emacs programs (emacs being a relative newcomer to using tooltips), I
think there must be something to it.

[Indeed, it would seem that Gnome's insistence on `consistency' in this
case may actually be damaging, by actually _causing_ people to think that
`everything must have a tooltip']

-Miles
-- 
`...the Soviet Union was sliding in to an economic collapse so comprehensive
 that in the end its factories produced not goods but bads: finished products
 less valuable than the raw materials they were made from.'  [The Economist]

Re: Gtk version getting closer

[Eli Zaretskii]

On 13 Nov 2002, Miles Bader wrote:

> The way I use tooltips is to pause over something and wait to see if
> something pops up; if nothing does, I just think `oh there's no tooltip
> for that.'

Same here.  For me, no tooltip means there's nothing else to be said 
about that particular widget except what its appearance and text already 
say.

Re: Gtk version getting closer

[Jan D.]

> > I do think tips can have a negative effect on menu item strings.  It is
> > too easy to make a menu with cryptic strings and then fully explain the
> > items in the tip instead.
> 
> The main reason for tooltips in menus is that menu items are usually
> limited in length.  Tooltips can be longer, especially since the font
> used for them is (or should be) smaller.

If one sets a default font for everything in .Xdefaults, or use
for example CDE, KDE (and perhaps Gnome) tools for setting style,
the tooltip will pick up that default font.  That usually makes the
tooltip font larger than the menu font.  I see this all the time
with various OS:es and users.  I don't think any assumption about font
should be made at all when writing menu strings or tooltip strings.

There is nothing "wrong" with a long menu string.  After all, it only
pops up when the menu is selected and does not take screen space otherwise.
And when the menu is selected, it is the focus of attention, so it can
take up as much space it needs.  In the Option menu, many menu strings
are longer than their tip.  And in many cases, the tip would have
made a better menu string, IMHO (for example Syntax Highlightning).

The alternative is to have a long tooltip.  Then one has to wait for
the tooltip to appear, shift focus of attention to the tooltip (which
may be on the other side of the screen), and then shift attention back
to the menu.

All this move of attention is what makes an UI seem strange.  True, the same
happens with the toolbar, so ideally, it should have (the option to have)
text under the icons.

	Jan D.

Re: Gtk version getting closer

[Richard Stallman]

    Tooltips are poping up and hiding other info.  As somebody else
    explained, for menu entries tooltips are not that important, because
    menu texts are better to understand than tool bar icons.

Sometimes they are important, for beginners.  Any time a menu item has
tooltip text, it was added explicitly so the menu item would have it.
I can recall a case in the menu bar where the discussion of what menu
item text to use was based on the idea of having a tooltip to go with
it.

I think the right way to address this problem is with an option to
turn off the menu tooltips.  Non-beginners might want to set that
option.

Re: Gtk version getting closer

[Robert J. Chassell]

   On 13 Nov 2002, Miles Bader wrote:

   > The way I use tooltips is to pause over something and wait to see if
   > something pops up; if nothing does, I just think `oh there's no tooltip
   > for that.'

That makes sense.

The problem is not with experts, but with people just learning.  Such
people think that Emacs is broken when they don't see a tooltip.

For example, all the menu items in the `File' and `Edit' menus have
tooltips, but there is no tooltip for the `Expand Aliases' menu item
in the Mail mode menu.  (I myself just discovered this -- I normally
don't look at tooltips.)

The lack of an `Expand Aliases' menu item tool tip will hurt some
people, such as those who don't yet understand address aliases or are
confused by them.

The problem here is that it takes great talent both to be an expert
and to write tips that help a novice.  And to have interest in the
problem.

Perhaps someone from the Emacspeak contingent could and will help?
Emacspeak is intended not only for knowledgeable and determined geeks,
but also for ordinary people who cannot look at a screen.  (Do the
blind use a keyboard-only variation on the menus for sighted people,
such as that provided by `tmm-menubar'?)

Otherwise, I fear that Emacs will remain less well used than it should
be, and continue to possess a false, off-putting reputation.

--
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: Gtk version getting closer

[Jan D.]

> 
> The problem is not with experts, but with people just learning.  Such
> people think that Emacs is broken when they don't see a tooltip.
> 

IMHO, people that are new and use "common" applications will be
surprised by tooltips in menus.  Not a lot of applications
have them.  I've never seen them on any Mac or MS Windows application.

	Jan D.

Re: Gtk version getting closer

[Kim F. Storm]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

>    On 13 Nov 2002, Miles Bader wrote:
> 
>    > The way I use tooltips is to pause over something and wait to see if
>    > something pops up; if nothing does, I just think `oh there's no tooltip
>    > for that.'
> 
> That makes sense.
> 
> The problem is not with experts, but with people just learning.  Such
> people think that Emacs is broken when they don't see a tooltip.
> 
> For example, all the menu items in the `File' and `Edit' menus have

Maybe we could have a "tree-state" customize option here:

- always show tooltips
  (generate a tooltip with the same text as the menu item if
   no explicit tooltip is specified)
- show available tooltips
  (the current functionality - show tooltips is available)
- no tooltips
  (never show tooltips for menu items).


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Gtk version getting closer

[Stefan Monnier]

> IMHO, people that are new and use "common" applications will be
> surprised by tooltips in menus.  Not a lot of applications
> have them.  I've never seen them on any Mac or MS Windows application.

Confusing users is bad.  But surprising them isn't.


	Stefan

Re: Gtk version getting closer

[Francesco Potorti`]

>   > The way I use tooltips is to pause over something and wait to see if
>   > something pops up; if nothing does, I just think `oh there's no tooltip
>   > for that.'

That's how it works on all systems I have ever seen.

>The problem is not with experts, but with people just learning.  Such
>people think that Emacs is broken when they don't see a tooltip.

When there is a row of buttons, one of which has a tooltip, I expect a
tooltip for every other button in the row.  You get the idea.

Re: Gtk version getting closer

[Jason Rumney]

"Jan D." <jan.h.d@swipnet.se> writes:

> For submenus there are no tips.  The PCL-CVS entry could use one,
> since PCL-CVS is kind of cryptic.

Submenus do have tips. PCL-CVS has the tip "Module-level interface to
CVS". But I think it depends on your toolkit as to whether Emacs
can show those tips or not. Xaw3D shows the tips. MS-Windows does
not. Apparently Motif does the same as MS-Windows (fails to notify
Emacs when a submenu is selected).

Re: Gtk version getting closer

[David Masterson]

>>>>> Karl Eichwalder writes:

> Richard Stallman <rms@gnu.org> writes:

>> Could you explain what is disturbing about it?  Then I can think
>> about the issue.

> Tooltips are poping up and hiding other info.  As somebody else
> explained, for menu entries tooltips are not that important, because
> menu texts are better to understand than tool bar icons.

If tooltips are active, they tend to pop up on their own.  This can be
disconcerting for menus, but perhaps that's because I'm slightly more
used to the MS-Windows approach.  In that case, tooltips for menus
only popup if you use the "What's this?" command (Shift-F1).  This
"What's this?" command can be applied to any widget on the screen (but
not every widget answers it).

Perhaps you want to think about this approach for menu tooltips?

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: Gtk version getting closer

[Jan D.]

> 
> > IMHO, people that are new and use "common" applications will be
> > surprised by tooltips in menus.  Not a lot of applications
> > have them.  I've never seen them on any Mac or MS Windows application.
> 
> Confusing users is bad.  But surprising them isn't.
> 

If it is a negative surprise, it is.  I don't know what this would be.
Anybody knows someone who can do a usability test on this? :-)

	Jan D.

Re: Gtk version getting closer

[Robert J. Chassell]

   > The problem is not with experts, but with people just learning.  

   Maybe we could have a "tree-state" customize option here:

   - always show tooltips
     (generate a tooltip with the same text as the menu item if
      no explicit tooltip is specified)
   - show available tooltips
     (the current functionality - show tooltips is available)
   - no tooltips
     (never show tooltips for menu items).

We definately should provide an option to turn tooltips on or off, but
no more.  Otherwise, I fear that no one will fill in the empty
tooltips; and tooltips with the same text as the menu item are
terrible, as Miles also said.

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: Gtk version getting closer

[Stefan Monnier]

>    > The problem is not with experts, but with people just learning.  
> 
>    Maybe we could have a "tree-state" customize option here:
> 
>    - always show tooltips
>      (generate a tooltip with the same text as the menu item if
>       no explicit tooltip is specified)
>    - show available tooltips
>      (the current functionality - show tooltips is available)
>    - no tooltips
>      (never show tooltips for menu items).
> 
> We definately should provide an option to turn tooltips on or off, but
> no more.

Been there: tooltips-mode


	Stefan

Re: Gtk version getting closer

[David Masterson]

>>>>> Robert J Chassell writes:

> Maybe we could have a "tree-state" customize option here:

>    - always show tooltips
>      (generate a tooltip with the same text as the menu item if
>       no explicit tooltip is specified)
>    - show available tooltips
>      (the current functionality - show tooltips is available)
>    - no tooltips
>      (never show tooltips for menu items).

You missed one (the MS-Windows one):

- show a tooltip if requested
  (have a "What's this?" function that will show the tooltip, if any,
   for a selected widget like a menu entry)

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: Gtk version getting closer

[Jan D.]

> > 
> >    Maybe we could have a "tree-state" customize option here:
> > 
> >    - always show tooltips
> >      (generate a tooltip with the same text as the menu item if
> >       no explicit tooltip is specified)
> >    - show available tooltips
> >      (the current functionality - show tooltips is available)
> >    - no tooltips
> >      (never show tooltips for menu items).
> > 
> > We definately should provide an option to turn tooltips on or off, but
> > no more.
> 
> Been there: tooltips-mode

Is it possible to disable tooltips for menus only with that now?  Can't
check out latest CVS, bootstrap failed.

	Jan D.

Re: Gtk version getting closer

[Richard Stallman]

    This isn't always the case.  Maybe the help texts should be
    reviewed and expanded/removed as a result?  For example,
    in Options we have:
      "Save Place in Files between Sessions"

    The tooltip for that is "Save Emacs state for next session".
    I think that the menu entry is much clearer hear, the tip is confusing.

I am surprised you think so.  I think they are both clear
and that they complement each other.

The same for the other items in that menu--they are useful.  This menu
shows why menu item tooltips need to work.

    The tips appear in the wrong places (i.e. under the pointer)
    sometimes.  I don't have a Lucid version available, but in the Motif and
    Gtk version you can click and release on a menubar item to make the menu
    appear.  Then you can navigate the menus with arrow keys.  The
    tip displayed is for the menu item marked with the arrow keys, but
    the tip appears where the pointer is.  The pointer can be on the other side
    of the screen, so this looks funny.

That is indeed a bug; it would be good to fix it.

Re: Gtk version getting closer

[Richard Stallman]

I agree with you on the issue of menu tooltips.

Re: Gtk version getting closer

[Richard Stallman]

    There is nothing "wrong" with a long menu string.

It makes the whole menu wider.  We have already made an effort to
reduce the width of these menus and we would be very reluctant to
install changes that make them even wider.

      And in many cases, the tip would have
    made a better menu string, IMHO (for example Syntax Highlightning).

We can certainly try to improve the text of both the menu items and
the tips.

Re: Gtk version getting closer

[Richard Stallman]

    The problem here is that it takes great talent both to be an expert
    and to write tips that help a novice.  And to have interest in the
    problem.

Would you like to work on improving them?  You have the sort of skills
that it needs.

Re: Gtk version getting closer

[Robert J. Chassell]

       The problem here is that it takes great talent both to be an expert
       and to write tips that help a novice.  And to have interest in the
       problem.

   Would you like to work on improving them?  You have the sort of skills
   that it needs.

I am not a good person for working on menu tips since I hardly ever
use menus.  Only the messages on this mailing list inspired me to look
into the menus in GNU Emacs.  The last time I used a menu system in an
editor application was in 1984, before I discovered Emacs.  I left
those menus behind as soon as I discovered the (undocumented)
keybindings.

The task deserves someone who has more experience with mice and menus
than I, and who is acquainted with contemporary novice users and
understands their mental model of an application.

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: Gtk version getting closer

[Jan D.]

onsdagen den 13 november 2002 kl 17.55 skrev Jason Rumney:

> "Jan D." <jan.h.d@swipnet.se> writes:
>
>> For submenus there are no tips.  The PCL-CVS entry could use one,
>> since PCL-CVS is kind of cryptic.
>
> Submenus do have tips. PCL-CVS has the tip "Module-level interface to
> CVS". But I think it depends on your toolkit as to whether Emacs
> can show those tips or not. Xaw3D shows the tips. MS-Windows does
> not. Apparently Motif does the same as MS-Windows (fails to notify
> Emacs when a submenu is selected).

Okay!  Thanks for the info, I missed that.  I'm sure such tips can
be shown in Gtk, at least it notifies when a submenu is choosen, so
the possibility is there.

	Jan D.

Re: Gtk version getting closer

[Jan D.]

onsdagen den 13 november 2002 kl 18.09 skrev David Masterson:

>>>>>> Karl Eichwalder writes:
>
>> Richard Stallman <rms@gnu.org> writes:
>
>>> Could you explain what is disturbing about it?  Then I can think
>>> about the issue.
>
>> Tooltips are poping up and hiding other info.  As somebody else
>> explained, for menu entries tooltips are not that important, because
>> menu texts are better to understand than tool bar icons.
>
> If tooltips are active, they tend to pop up on their own.  This can be
> disconcerting for menus, but perhaps that's because I'm slightly more
> used to the MS-Windows approach.  In that case, tooltips for menus
> only popup if you use the "What's this?" command (Shift-F1).  This
> "What's this?" command can be applied to any widget on the screen (but
> not every widget answers it).
>
> Perhaps you want to think about this approach for menu tooltips?

This sounds good.  As pointed out, C-h k is (almost) Emacs version
of "What's this?".  Could C-h k be bent to show a tooltip when
invoked on a menu or toolbar item?

How does MS Windows handle the menu when doing this?  Do you first select
"What's this?" and then the menu item?  Or is it the menu item first and
"What's this?" afterwards?  If the first, is the menu still open when
the tooltip is shown?

	Jan D.

Re: Gtk version getting closer

[Jan D.]

>     This isn't always the case.  Maybe the help texts should be
>     reviewed and expanded/removed as a result?  For example,
>     in Options we have:
>       "Save Place in Files between Sessions"
>
>     The tooltip for that is "Save Emacs state for next session".
>     I think that the menu entry is much clearer hear, the tip is confusing.
>
> I am surprised you think so.  I think they are both clear
> and that they complement each other.

Well, this is just an example, but here are my reasoning.

The menu item has "between Sessions", implying this applies
    for all sessions to come.  The tip says "next Session", implying
    it is only for the next session.

The menu item has "Save Place in Files", the tip says "Save Emacs state".
    Neither is 100% correct, there is more that places saved, but
    less than the full Emacs state.  If this is for a beginner, I
    imagine (but could be wrong) that "Save Places" is easier to
    understand than "Save state", as stats can mean many things.

I think I would have written "Reopen files when Emacs is started".

> The same for the other items in that menu--they are useful.  This menu
> shows why menu item tooltips need to work.

I am not against tips, I just don't think showing them as today is
a good idea.  The "What's this?" approach seems workable.  Then we
could have even longer (multiline) tips.

>     The tips appear in the wrong places (i.e. under the pointer)
>     sometimes.  I don't have a Lucid version available, but in the Motif 
> and
>     Gtk version you can click and release on a menubar item to make the 
> menu
>     appear.  Then you can navigate the menus with arrow keys.  The
>     tip displayed is for the menu item marked with the arrow keys, but
>     the tip appears where the pointer is.  The pointer can be on the other 
> side
>     of the screen, so this looks funny.
>
> That is indeed a bug; it would be good to fix it.

It is not that easy to get the information about where the selected
menu item is on the screen, so I think this is hard to do.  I'll keep it
in mind when I start on Gtk menu tips.

	Jan D.

Re: Gtk version getting closer

[Eli Zaretskii]

> From: "Jan D." <jan.h.d@swipnet.se>
> Date: Wed, 13 Nov 2002 11:15:43 +0100 (CET)
> 
> If one sets a default font for everything in .Xdefaults, or use
> for example CDE, KDE (and perhaps Gnome) tools for setting style,
> the tooltip will pick up that default font.

I meant a decent setup, not the default.  I once proposed to make the
default font for the tooltips smaller than the one chosen for the
default face, but was told that there are problems to do that with X,
and I don't know enough about X to suggest a solution.

FWIW, my .emacs selects a much smaller font for tooltips.

> The alternative is to have a long tooltip.  Then one has to wait for
> the tooltip to appear, shift focus of attention to the tooltip (which
> may be on the other side of the screen), and then shift attention back
> to the menu.

That's how tooltips work on all GUI platforms I've seen; Emacs just
tries to be compatible here.  (Of course, you have variables to
customize the time delay for pop-up and pop-down, if the defaults
annoy you.)

Re: Gtk version getting closer

[Eli Zaretskii]

> From: "Jan D." <jan.h.d@swipnet.se>
> Date: Wed, 13 Nov 2002 16:38:11 +0100 (MET)
> 
> I've never seen [tooltips for menus] on any Mac or MS Windows
> application.

Really?  Please click on any menu-bar item in the Internet Explorer,
then move the mouse pointer across the menu that drops down, and watch
the bottom of the IE display, the area we call ``echo area''.

Re: Gtk version getting closer

[Jan D.]

torsdagen den 14 november 2002 kl 19.57 skrev Eli Zaretskii:

>> From: "Jan D." <jan.h.d@swipnet.se>
>> Date: Wed, 13 Nov 2002 16:38:11 +0100 (MET)
>>
>> I've never seen [tooltips for menus] on any Mac or MS Windows
>> application.
>
> Really?  Please click on any menu-bar item in the Internet Explorer,
> then move the mouse pointer across the menu that drops down, and watch
> the bottom of the IE display, the area we call ``echo area''.

I don't think that qualifies as a tooltip.  I suppose you mean what also is
called "status bar" or "status area", I have not run Internet Explorer.
But to be more specific, I mean menus that pop up windows with text
near the pointer when a menu item is selected.

	Jan D.

Re: Gtk version getting closer

[Jan D.]

>> If one sets a default font for everything in .Xdefaults, or use
>> for example CDE, KDE (and perhaps Gnome) tools for setting style,
>> the tooltip will pick up that default font.
>
> I meant a decent setup, not the default.  I once proposed to make the
> default font for the tooltips smaller than the one chosen for the
> default face, but was told that there are problems to do that with X,
> and I don't know enough about X to suggest a solution.
>
> FWIW, my .emacs selects a much smaller font for tooltips.

Yes, but you must be considered a power user.  Most users seem to just
use the tools available in the GUI to select fonts and colours.


>> The alternative is to have a long tooltip.  Then one has to wait for
>> the tooltip to appear, shift focus of attention to the tooltip (which
>> may be on the other side of the screen), and then shift attention back
>> to the menu.
>
> That's how tooltips work on all GUI platforms I've seen; Emacs just
> tries to be compatible here.  (Of course, you have variables to
> customize the time delay for pop-up and pop-down, if the defaults
> annoy you.)

I still believe that this is not how tooltips for menus work on the
majority of GUI platforms.  Most GUI platforms does not have
tooltips for menus at all.  But I think the "What's this?" approach
explained elsewhere is better.

	Jan D.

Re: Gtk version getting closer

[David Masterson]

>>>>> Jan D writes:

> onsdagen den 13 november 2002 kl 18.09 skrev David Masterson:

>>>>>>> Karl Eichwalder writes:

>>> Richard Stallman <rms@gnu.org> writes:

>>>> Could you explain what is disturbing about it?  Then I can think
>>>> about the issue.

>>> Tooltips are popping up and hiding other info.  As somebody else
>>> explained, for menu entries tooltips are not that important,
>>> because menu texts are better to understand than tool bar icons.

>> If tooltips are active, they tend to pop up on their own.  This can
>> be disconcerting for menus, but perhaps that's because I'm slightly
>> more used to the MS-Windows approach.  In that case, tooltips for
>> menus only popup if you use the "What's this?" command (Shift-F1).
>> This "What's this?" command can be applied to any widget on the
>> screen (but not every widget answers it).

>> Perhaps you want to think about this approach for menu tooltips?

> This sounds good.  As pointed out, C-h k is (almost) Emacs version
> of "What's this?".  Could C-h k be bent to show a tooltip when
> invoked on a menu or toolbar item?

> How does MS Windows handle the menu when doing this?  Do you first
> select "What's this?" and then the menu item?  Or is it the menu
> item first and "What's this?" afterwards?  If the first, is the menu
> still open when the tooltip is shown?

You first select "What's this?" if it's available (not always provided
and sometimes it's a simple "?" next to the window's minimize button).
Then you select the "leaf" menu item of interest (ie. menus with
submenus don't trigger the "What's this?").  The menu remains open
during and after the tooltip is shown.

I'm not sure that C-h k should be bent to showing tooltips as C-h k on
a menu item already invokes describe-key and having two different
styles of output for it might be confusing.  In general, you want to
make the tooltip simple to get to, but not constantly popping up in
your way.  My suggestion would be to make the first character of the
menubar (or modeline?) a "?" which would serve as this "What's this?"
button (the equivalent Emacs command can be pretty obscure).  Menus
generally aren't available in non-windows mode (correct?) and you
don't need tooltips in non-windows mode (correct?), so, when the menu
goes away, easy access to tooltips would also go away and this would
be reasonable.

Are tooltips reasonably applied to anything other than (the equivalent
of) an XWindow widget (menu item, button, frame, etc.)?

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: Gtk version getting closer

[Eli Zaretskii]

> Date: Thu, 14 Nov 2002 21:07:56 +0100
> From: "Jan D." <jan.h.d@swipnet.se>
> 
> > Please click on any menu-bar item in the Internet Explorer,
> > then move the mouse pointer across the menu that drops down, and watch
> > the bottom of the IE display, the area we call ``echo area''.
> 
> I don't think that qualifies as a tooltip.

Nevertheless, Emacs behaves just like that when you turn off
tooltip-mode.  It displays the tooltip text in the echo area.

Re: Gtk version getting closer

[Eli Zaretskii]

> From: "Jan D." <jan.h.d@swipnet.se>
> Date: Thu, 14 Nov 2002 18:49:50 +0100
> 
> we could have even longer (multiline) tips.

I don't think there's anything to prevent us from having multiline
tooltips.  Tooltips are just a special kind of frames, so they could
be multiline.

Re: Gtk version getting closer

[David Masterson]

>>>>> Jan D writes:
                                   
> I am not against tips, I just don't think showing them as today is
> a good idea.  The "What's this?" approach seems workable.  Then we
> could have even longer (multiline) tips.

Longer, but not too long.  Otherwise, you're moving into the territory
of describe-* commands.  And, no, the tooltip should not be the same
thing as the output of describe-key as, ultimately, the output of
describe-key could include active areas whereas the tooltip can't, so
the excess would be worthless.  Hmmm, maybe a "?" button to invoke the
tooltip and a "??" button to invoke describe-key...?

Plus, I think it might be reasonable to have tooltips on things like:

* sections of the modeline
* headers in mail messages
* horizontal scrollbar (mentioning truncate-lines)
* the menubar (toggle-menubar?)
* let your imagination flow...

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: Gtk version getting closer

[Jan D.]

torsdagen den 14 november 2002 kl 21.29 skrev Eli Zaretskii:

>> From: "Jan D." <jan.h.d@swipnet.se>
>> Date: Thu, 14 Nov 2002 18:49:50 +0100
>>
>> we could have even longer (multiline) tips.
>
> I don't think there's anything to prevent us from having multiline
> tooltips.  Tooltips are just a special kind of frames, so they could
> be multiline.

I was thinking that tooltips the users ask for generally can be longer
than tooltips that pops up automatically.  The first type you expect, the
second type you don't so one wants to minimize the screen space it
occupies.

	Jan D.

Re: Gtk version getting closer

[Jason Rumney]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

> Really?  Please click on any menu-bar item in the Internet Explorer,
> then move the mouse pointer across the menu that drops down, and watch
> the bottom of the IE display, the area we call ``echo area''.

I have been using Windows for years, and only noticed this
recently. Who looks at the echo/status area when they are selecting
menus at the top of the window? Tooltips are a much better solution.

Re: Gtk version getting closer

[Miles Bader]

"Robert J. Chassell" <bob@rattlesnake.com> writes:
> I am not a good person for working on menu tips since I hardly ever
> use menus.

I rarely use menus in emacs either -- for invoking commands.

I do keep the menu-bar turned on, though, because the menus are great as
_documentation_, especially for modes like Gnus that have 1,000,000
commands that I only occasionally use.  I find it much more convenient
to just browse the menus in such a case than to use the more
conventional emacs help systems (though this obviously only works if
the mode has relatively completely menus; luckily Gnus does...).

-Miles
-- 
Yo mama's so fat when she gets on an elevator it HAS to go down.

Re: Gtk version getting closer

[Richard Stallman]

    If tooltips are active, they tend to pop up on their own.  This can be
    disconcerting for menus, but perhaps that's because I'm slightly more
    used to the MS-Windows approach.  In that case, tooltips for menus
    only popup if you use the "What's this?" command (Shift-F1).

If users are accustomed to this and like it, it would be a good
approach.  But can it be implemented without changing the toolkits?

This might be a useful change to make in GTK.

Re: Gtk version getting closer

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
>     In that case, tooltips for menus only popup if you use the "What's
>     this?" command (Shift-F1).
> 
> If users are accustomed to this and like it, it would be a good
> approach.  But can it be implemented without changing the toolkits?
> 
> This might be a useful change to make in GTK.

Some users may be more used to it (I don't know), but I presume not
Gnome users -- Gnome panel menus act exactly like emacs menus currently
do, they pop up tooltips without any special command.

I like the current method, so I hope any change is completely optional
(and certainly I'd like to use a GTK toolkit version of emacs).

-Miles
-- 
Run away!  Run away!

Re: Gtk version getting closer

[Robert J. Chassell]

Miles Bader <miles@gnu.org> wrote

   I rarely use menus in emacs either -- for invoking commands.

   I do keep the menu-bar turned on, though, because the menus are great as
   _documentation_, especially for modes like Gnus that have 1,000,000
   commands that I only occasionally use.  ....

That is a good reason to use menus.  Whoever write the tool tips
should keep this in mind as one of purposes to which the menu bar
will be put.  The task grows more challenging!

In your same circumstance, I type `C-h m' (describe-mode) which
usually provides me with all the information I need, but not always.

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: Gtk version getting closer

[Eli Zaretskii]

> From: Jason Rumney <jasonr@gnu.org>
> Date: 14 Nov 2002 23:03:05 +0000
> 
> Tooltips are a much better solution.

Obviously, I agree.  My whole point was that displaying information
about menu items is not something Emacs invented, it exists on other
GUI platforms.

Re: Gtk version getting closer

[Eli Zaretskii]

> From: David Masterson <dmaster@synopsys.com>
> Date: 15 Nov 2002 08:36:44 -0800
> 
> if you were going to use the menu, I would think the tooltip popping
> up might get in the way.

Can't you prevent this by customizing tooltip-x-offset and
tooltip-y-offset, or maybe tooltip-delay?

Re: Gtk version getting closer

[David Masterson]

>>>>> Miles Bader writes:

> Richard Stallman <rms@gnu.org> writes:

>>> In that case, tooltips for menus only popup if you use the "What's
>>> this?" command (Shift-F1).

>> If users are accustomed to this and like it, it would be a good
>> approach.  But can it be implemented without changing the toolkits?

>> This might be a useful change to make in GTK.

> Some users may be more used to it (I don't know), but I presume not
> Gnome users -- Gnome panel menus act exactly like emacs menus
> currently do, they pop up tooltips without any special command.

> I like the current method, so I hope any change is completely
> optional (and certainly I'd like to use a GTK toolkit version of
> emacs).

Can you be a little more precise as to why you like the current
method?  From another of your messages, my guess is that you don't use
the menu directly, you just use it as documentation.  If so, then
having the tooltips popup on their own makes sense.  However, if you
were going to use the menu, I would think the tooltip popping up might
get in the way.  Obviously, you could turn off the tooltips all
together, but having a "What's this?" command might be a little more
flexible.

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: Gtk version getting closer

[Miles Bader]

On Fri, Nov 15, 2002 at 08:36:44AM -0800, David Masterson wrote:
> > I like the current method, so I hope any change is completely
> > optional (and certainly I'd like to use a GTK toolkit version of
> > emacs).
> 
> Can you be a little more precise as to why you like the current
> method?

Because (1) I like having the tooltips, and (2) I don't find them annoying,
and (3) I _do_ find having to use an explicit command to get tooltips
annoying.

Note that (2) is something that depends a lot on the particular parameters
(popup delay etc): some programs (the enlightenment window manager is a good
example) have tooltips that drive me bonkers, but emacs seems to have done
things right.

> From another of your messages, my guess is that you don't use
> the menu directly, you just use it as documentation.

I `use them as documentation' in the sense that I use them to help me
remember rarely used commands (or commands with particularly wierd bindings).
Of course I don't look at the menu and then hit the key (that would be a bit
silly) -- I just select the menu entry.

The main difference I think is that I use the menus occasionally, rather
than for every command (which I've seen novice users do, even when I'm pretty
sure they know the key-binding; I guess they're just used to it).

> If so, then having the tooltips popup on their own makes sense.  However,
> if you were going to use the menu, I would think the tooltip popping up
> might get in the way.

It would be nice to have something besides conjecture.

Has anyone heard any complaints about menu tooltips being annoying?

> Obviously, you could turn off the tooltips all together, but having a
> "What's this?" command might be a little more flexible.

They seem orthogonal, actually...

-Miles
-- 
Love is a snowmobile racing across the tundra.  Suddenly it flips over,
pinning you underneath.  At night the ice weasels come.  --Nietzsche

Re: Gtk version getting closer

[Robert J. Chassell]

   .... I would think the tooltip popping up might get in the way.

Try setting the tooltip-x-offset and tooltip-y-offset amounts to
something different than the default.  That keeps the tips from
getting in the way.

I just tried:

    (setq tooltip-x-offset 40)
    (setq tooltip-y-offset -40)

which moves the tips quite a distance.

These variables are in:        emacs/lisp/tooltip.el

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: Gtk version getting closer

[Jason Rumney]

David Masterson <dmaster@synopsys.com> writes:

> However, if you were going to use the menu, I would think the
> tooltip popping up might get in the way.

Maybe more vertical separation between the mouse pointer and tooltip
would help here. Or moving the tooltip to below the mouse pointer
might keep it more out of the way (and would be consistent with Gnome,
Sawfish and MS-Windows).

Re: Gtk version getting closer

[David Masterson]

>>>>> Eli Zaretskii writes:

>> From: David Masterson <dmaster@synopsys.com>
>> Date: 15 Nov 2002 08:36:44 -0800
>> 
>> if you were going to use the menu, I would think the tooltip
>> popping up might get in the way.

> Can't you prevent this by customizing tooltip-x-offset and
> tooltip-y-offset, or maybe tooltip-delay?

I guess it's a preference thing.  Some people are used to tooltips
popping up all the time and, so, it doesn't distract them if they're
not interested in the tooltip.  Others prefer the tooltip to be
available when asked for (as in "What's this?") and would be annoyed
if the tooltip popped up while (say) they were thinking about choosing
between menuA and menuB.  The tooltip-delay might help, but it
requires a fine balance between too fast (annoying you when you're not
interested in the tip) and too slow (annoying you when you are
interested).  The offsets are also problematic because the widgets
that the tooltips are applied to are not uniform size, so sometimes
the offset may be too far and sometimes it may be too close.

Perhaps a tooltip-style variable is needed with these options:

* never - deactivate tooltips
* always - full activation of tooltips
* nomenus - activated except for menus
* whatthis - deactivate tooltips, but "What's this?" will activate
  tooltip of selected widget 

Or, perhaps, the style should only be the first 3 and the last one is
a command (which can be applied to a key) that is always available.

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: Gtk version getting closer

[David Masterson]

>>>>> Miles Bader writes:

> It would be nice to have something besides conjecture.  Has anyone
> heard any complaints about menu tooltips being annoying?

I thought that's what I was doing...

Tooltips popping up sometimes (but not always) can be annoying.  It's
a preference thing based upon the environments you've worked in.  The
MS-Windows users, for instance, might prefer a "What's this?" command
to have the tooltip only popup when requested (I don't think of myself
as an MS-Windows user, but some things have rubbed off ;-).

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: Gtk version getting closer

[Stefan Monnier]

> Of course I don't look at the menu and then hit the key (that would be a bit
> silly) -- I just select the menu entry.

I'm often silly: hitting the key (after reading it in the menu) helps
me remember the binding. ;-)


	Stefan

Re: Gtk version getting closer

[David Masterson]

>>>>> Jason Rumney writes:

> David Masterson <dmaster@synopsys.com> writes:
>> However, if you were going to use the menu, I would think the
>> tooltip popping up might get in the way.

> Maybe more vertical separation between the mouse pointer and tooltip
> would help here. Or moving the tooltip to below the mouse pointer
> might keep it more out of the way (and would be consistent with
> Gnome, Sawfish and MS-Windows).

For some people, this might be enough *most* of the time.  Because the
widgets that might have tooltips are not uniform in size or content,
the visual offsets you mention may sometimes seem too big and
sometimes seem too small (beauty is in the eye of the beholder).

All I'm suggesting is you've got three different types of users:

* Those who don't like tooltips at all (in which case, you provide a
  variable to turn off tooltips).
* Those who find tooltips useful *when* they ask for them (in which
  case, the "What's this?" command makes sense).
* Those who generally find tooltips useful (in which case, the normal
  popups with adjustment variables makes sense).

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: Gtk version getting closer

[Eli Zaretskii]

> From: David Masterson <dmaster@synopsys.com>
> Date: 15 Nov 2002 10:46:43 -0800
> 
> >>>>> Eli Zaretskii writes:
> 
> >> From: David Masterson <dmaster@synopsys.com>
> >> Date: 15 Nov 2002 08:36:44 -0800
> >> 
> >> if you were going to use the menu, I would think the tooltip
> >> popping up might get in the way.
> 
> > Can't you prevent this by customizing tooltip-x-offset and
> > tooltip-y-offset, or maybe tooltip-delay?
> 
> I guess it's a preference thing.  Some people are used to tooltips
> popping up all the time and, so, it doesn't distract them if they're
> not interested in the tooltip.  Others prefer the tooltip to be
> available when asked for (as in "What's this?") and would be annoyed
> if the tooltip popped up while (say) they were thinking about choosing
> between menuA and menuB.

I was asking whether _you_ in _your_ particular environment can
prevent the annoyance using the customizable options.

If the answer is YES, then users at least have a way of getting the
tooltips out of their way when they use menus.

Re: Gtk version getting closer

[David Masterson]

>>>>> Eli Zaretskii writes:

>> From: David Masterson <dmaster@synopsys.com>
>> Date: 15 Nov 2002 10:46:43 -0800
>> 
>> >>>>> Eli Zaretskii writes:
>> 
>> >> From: David Masterson <dmaster@synopsys.com>
>> >> Date: 15 Nov 2002 08:36:44 -0800
>> >> 
>> >> if you were going to use the menu, I would think the tooltip
>> >> popping up might get in the way.
>> 
>> > Can't you prevent this by customizing tooltip-x-offset and
>> > tooltip-y-offset, or maybe tooltip-delay?
>> 
>> I guess it's a preference thing.  Some people are used to tooltips
>> popping up all the time and, so, it doesn't distract them if
>> they're not interested in the tooltip.  Others prefer the tooltip
>> to be available when asked for (as in "What's this?") and would be
>> annoyed if the tooltip popped up while (say) they were thinking
>> about choosing between menuA and menuB.

> I was asking whether _you_ in _your_ particular environment can
> prevent the annoyance using the customizable options.

> If the answer is YES, then users at least have a way of getting the
> tooltips out of their way when they use menus.

Oh.  I haven't tried it yet, but I think I could adapt to things even
without the customizable options (it's just a matter of not letting
the tooltip popup distract you when it's not neede).  However, while I
could adapt to it, it doesn't agree with my current preference which
would tend toward the "What's this?" approach.  As has been true in
the past, though, I'm sure that, if you give me a little time to
adapt, I'll forget all about the old way of doing things.  ;-)

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: Gtk version getting closer

[Jason Rumney]

David Masterson <dmaster@synopsys.com> writes:

> The MS-Windows users, for instance, might prefer a "What's this?"
> command to have the tooltip only popup when requested

This does not seem to be a universal thing on MS-Windows. I had to
look very hard to find a program that had this feature, and that
program did not have a menu bar (just a dialog interface). The "What's
this?" command seems to be in addition to tooltips in that case, and
gives a 5 - 10 line pop-up that looks more like what C-h k would
produce.

Re: Gtk version getting closer

[David Masterson]

>>>>> Jason Rumney writes:

> David Masterson <dmaster@synopsys.com> writes:
>> The MS-Windows users, for instance, might prefer a "What's this?"
>> command to have the tooltip only popup when requested

> This does not seem to be a universal thing on MS-Windows. I had to
> look very hard to find a program that had this feature, and that
> program did not have a menu bar (just a dialog interface). The
> "What's this?" command seems to be in addition to tooltips in that
> case, and gives a 5 - 10 line pop-up that looks more like what C-h k
> would produce.

I agree.  The general idea is good.  The MS implementation is
incomplete and, therefore, not good.

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: Gtk version getting closer

[Richard Stallman]

    The menu item has "between Sessions", implying this applies
	for all sessions to come.  The tip says "next Session", implying
	it is only for the next session.

Both expressions fit what it actually does.

    The menu item has "Save Place in Files", the tip says "Save Emacs state".
	Neither is 100% correct, there is more that places saved, but
	less than the full Emacs state.  If this is for a beginner, I
	imagine (but could be wrong) that "Save Places" is easier to
	understand than "Save state", as stats can mean many things.

I think they are both useful.  If you have specific
suggestions to improve one or the other, please offer them.

    I think I would have written "Reopen files when Emacs is started".

Perhaps "Revisit files of previous session when restarting Emacs."
What do you think?

Re: Gtk version getting closer

[Richard Stallman]

    I am not a good person for working on menu tips since I hardly ever
    use menus.

You can look at the menus for the specific purpose of improving their
tooltips.  It doesn't matter whether you use the menus yourself often;
what matters is that you have the skill to imagine what a newby would
understand, or not understand, when looking at them.

Re: Gtk version getting closer

[Richard Stallman]

    You first select "What's this?" if it's available (not always provided
    and sometimes it's a simple "?" next to the window's minimize button).
    Then you select the "leaf" menu item of interest (ie. menus with
    submenus don't trigger the "What's this?").  The menu remains open
    during and after the tooltip is shown.

This is almost identical to C-h k.  That shows the doc string of the
menu item command.

It is good to make sure each menu item has a function name and a doc
string--to avoid anonymous lambdas there.  I made some changes
of that sort a few months ago, and I think I got rid of them all.

Re: Gtk version getting closer

[Jan D.]

>     The menu item has "between Sessions", implying this applies
> 	for all sessions to come.  The tip says "next Session", implying
> 	it is only for the next session.
>
> Both expressions fit what it actually does.

Yes, they do.  But this is the problem when experts describe things
for beginners, I know, I've been there a lot :-)

For someone used to Emacs, this is totally OK.  But it really doesn't
describe the difference a users sees with and without this option.

>
>     The menu item has "Save Place in Files", the tip says "Save Emacs 
> state".
> 	Neither is 100% correct, there is more that places saved, but
> 	less than the full Emacs state.  If this is for a beginner, I
> 	imagine (but could be wrong) that "Save Places" is easier to
> 	understand than "Save state", as stats can mean many things.
>
> I think they are both useful.  If you have specific
> suggestions to improve one or the other, please offer them.
>
>     I think I would have written "Reopen files when Emacs is started".
>
> Perhaps "Revisit files of previous session when restarting Emacs."
> What do you think?

This is good.  But "previous session" already implies a restart, so
it could be shorter:
  "Visit files of previous session when starting Emacs"

Also, visit is somewhat Emacs specific, most other programs say open.
Emacs menus doesn't have visit in them either.  But if one should
follow other programs convention or use Emacs terms is another
discussion.

I guess this only shows that designing menu texts is hard and also a
matter of taste. :-)

	Jan D.

Re: Gtk version getting closer

[David Masterson]

>>>>> Richard Stallman writes:

>     You first select "What's this?" if it's available (not always provided
>     and sometimes it's a simple "?" next to the window's minimize button).
>     Then you select the "leaf" menu item of interest (ie. menus with
>     submenus don't trigger the "What's this?").  The menu remains open
>     during and after the tooltip is shown.

> This is almost identical to C-h k.  That shows the doc string of the
> menu item command.

Agreed.  

I have found that it's not obvious that "describe-key" can also be
applied to menus and buttons.  Therefore, I would suggest adding a
"What's this?" entry to the standard Help menu that simply does
describe-key.  You can leave the "Describe Key" entry in the Describe
menu of the Help menu.  Because of MS-Windows precedent, this should
make it's use a little more obvious.

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: Gtk version getting closer

[Miles Bader]

BTW, I happened to use a modern MS Windows system today (I'm not sure which
one, but I guess 2K or XP; the menus/title-bars are neon colors, and it was
on a laptop, so probably a `consumer' system), and noticed that the menus had
tooltips popping up without any prompting....  they did a better job of
avoiding the selected menu item that emacs menu tooltips though.

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: Gtk version getting closer

[Richard Stallman]

    I just tried:

	(setq tooltip-x-offset 40)
	(setq tooltip-y-offset -40)

    which moves the tips quite a distance.

Would there be a better default value for these?

Re: Gtk version getting closer

[Jason Rumney]

Richard Stallman <rms@gnu.org> writes:

>     I just tried:
> 
> 	(setq tooltip-x-offset 40)
> 	(setq tooltip-y-offset -40)
> 
>     which moves the tips quite a distance.
> 
> Would there be a better default value for these?

Gnome 1.4 positions its tooltips below the mouse pointer and centered,
everything else I have seen positions them below and to the right (the
start of the text is actually aligned with the LHS of the pointer in
sawfish, I can't check anything else right now). Only Emacs positions
tooltips above the mouse. I think below is less likely to be in the
way, since the pointer usually points upwards. So my suggestion would
be to default to 

(setq tooltip-x-offset 0)
(setq tooltip-y-offset 40)

Re: Bold by moving pixels problem

[Miles Bader]

On Wed, Nov 20, 2002 at 01:09:10PM +0000, Robert J. Chassell wrote:
> Did you install the patch in which bold is created by duplicating a
> glyph, but moving over a pixel?

Yes

> The change does not look too bad with the plain vanilla instance,
> however, there are three problems with the consequences of the change
> for instances of emacs started with my .emacs file:
> 
>   * the new bold creation technique fills in letters such as `m' so
>     that they become unreadable rectangles

Yes, that happens with the font I use too; however, as I said in my original
post, it actually doesn't seem to make much difference to readability.

[I'm not entirely sure _why_ it doesn't make a diffence -- I suppose that the
little blob is close enough to an `m' and there's enough context that my
brain can fill in the details.  It also helps I suppose that boldface
typically only occurs in short stretches of text, not whole buffers.  In any
case, I simply don't notice it at all, unless I explicitly look to see.]

> That is to say, when I reset the value of `mode-line-buffer-identification'
> so its face is :weight normal rather than :weight bold, that change is only
> temporary.
...
>   * I do not know how to set the value that is associated with 
>         (face (:weight bold) ...
>     in my .emacs.

As far as I know, there is no way to universally tweak face attributes.

If the only thing that concerns you is the `synthesized bold,' I suppose a
variable could be added to specifically inhibit this behavior.

However, some `real' bold fonts actually have this same problem --
characters like `m' can be only vague blobs, with the vertical strokes
undifferentiated.  Perhaps in such a case, people would like to disable
even `real' bold-face.

So maybe it would be better to add a more general feature that could also
make such a decision based on the actual font rather than universally.
[Another case might be fonts that don't have italic -- some people
might like to e.g. display an underline instead in this case]

I'm not sure how such feature should look though.

> The `m' in the word `emacs' becomes unreadable.

You might think about just trying it for a while, and seeing if you stop
noticing...

Thanks,

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: Bold by moving pixels problem

[Robert J. Chassell]

   Yes, that happens with the font I use too; however, as I said in my original
   post, it actually doesn't seem to make much difference to readability.

I know what you mean -- on some fonts it does not matter.  But in this
case, it is very obvious and ugly.

   If the only thing that concerns you is the `synthesized bold,' I suppose a
   variable could be added to specifically inhibit this behavior.

Nice, but not enough.

   However, some `real' bold fonts actually have this same problem --
   characters like `m' can be only vague blobs, with the vertical strokes
   undifferentiated.  Perhaps in such a case, people would like to disable
   even `real' bold-face.

Yes -- I would like to disable `real' bold-face.  

I would like everything with bold to be `normal' weight; I then use
color to indicate bold.  With this laptop screen, that works best.  (I
am using "DodgerBlue4" for background and "cyan" for foreground --
suits me well.)

   So maybe it would be better to add a more general feature that could also
   make such a decision based on the actual font rather than universally.

Yes.

   [Another case might be fonts that don't have italic -- some people
   might like to e.g. display an underline instead in this case]

Yes -- again, on this screen, my italic shape looks terrible, so I
use color for this, too.  (I have an underline face, which I could
use for italic, but color works best.)

Do please try to come up with some variable; that way I can use the
shape changers on appropriate screens and what amounts to a fixed
width sans serif font with colors for most of my other faces.

Thanks!

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: Gtk version getting closer

[Robert J. Chassell]

       I just tried:

           (setq tooltip-x-offset 40)
           (setq tooltip-y-offset -40)

       which moves the tips quite a distance.

   Would there be a better default value for these?

I don't know what people would like.  The best value depends both on a
person's screen and on the font they are using.

With my usual "10x20" font,

	(setq tooltip-x-offset 20)
	(setq tooltip-y-offset -20)

looks good, but in a plain vanilla instance of Emacs, started as

    emacs -q --no-site-file --eval '(blink-cursor-mode 0)'


	(setq tooltip-x-offset 15)
	(setq tooltip-y-offset -15)

is better.  But 15 is too small a value for my "10x20" font.

I suspect that many people use a 1024x768 screen with the default
fonts, a white background and all that, but am not sure.  I run the
default fonts in the `plain vanilla' Emacs, but have a higher
resolution screen.

Do others on this list have a sense of what should be a good default?

--
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: Gtk version getting closer

[Robert J. Chassell]

   ... Only Emacs positions
   tooltips above the mouse. I think below is less likely to be in the
   way, since the pointer usually points upwards. So my suggestion would
   be to default to 

   (setq tooltip-x-offset 0)
   (setq tooltip-y-offset 40)

On my usual system, this and variations of it sometimes cover the menu
item and sometimes not.  On the `Tools' menu, for example, these
values lead to a tip that does OK with `Compile' but that covers up
part of `Ediff Miscellanea'.

But on a `plain vanilla' Emacs, started with

    emacs -q --no-site-file --eval '(blink-cursor-mode 0)'

the values lead to tips that never cover up their menu item.

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: Bold by moving pixels problem

[Stefan Monnier]

> I would like everything with bold to be `normal' weight; I then use
> color to indicate bold.  With this laptop screen, that works best.  (I
> am using "DodgerBlue4" for background and "cyan" for foreground --
> suits me well.)
> 
>    So maybe it would be better to add a more general feature that could also
>    make such a decision based on the actual font rather than universally.
> 
> Yes.

How about a face transformer hook called at the end of face-set-spec
as in the patch below ?
We should of course come up with useful functions to put on
that hook.  For example to turn italics into underline or bold
into something else.  Or to enforce a minimum contrast between
foreground and background color, ...


	Stefan


Index: faces.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/faces.el,v
retrieving revision 1.272
diff -u -u -b -r1.272 faces.el
--- faces.el	6 Sep 2002 07:14:29 -0000	1.272
+++ faces.el	21 Nov 2002 01:31:09 -0000
@@ -1377,7 +1379,8 @@
 	       (setq attribute nil))))
 	(when attribute
 	  (set-face-attribute face frame attribute value)))
-      (setq attrs (cdr (cdr attrs))))))
+      (setq attrs (cdr (cdr attrs)))))
+  (run-hook-with-args 'face-transformer-functions face frame))
 
 
 (defun face-attr-match-p (face attrs &optional frame)

Re: Bold by moving pixels problem

[Miles Bader]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
> How about a face transformer hook called at the end of face-set-spec
> as in the patch below ?

The problem is that only works for customized faces, not for those
defined with lower-level functions, or for `merged' faces resulting from
text-properties, etc.  In fact I think one of the complaints Bob had was
about a face property added by the mode-line stuff.

I was envisioning a similar `face-filter,' but run somewhere just before
face-realization or thereabouts.  Of course, this approach requires more
care to avoid bjorking redisplay, or slowing things down too much.

-Miles
-- 
"1971 pickup truck; will trade for guns"

Re: Bold by moving pixels problem

[Eli Zaretskii]

On Thu, 21 Nov 2002, Robert J. Chassell wrote:

> I would like everything with bold to be `normal' weight; I then use
> color to indicate bold.  With this laptop screen, that works best.

The issue of transforming face attributes has come up before.

I think it would be a good feature to be able to tell Emacs that a certain
face attribute should be displayed as some other attribute.  An example of
bold being displayed in some distinct color is a good case in point.

Many telnet clients which run on color displays already do that.  The
MS-DOS port of Emacs before v21.1 actually implemented that by redefining
the bold and italics faces in the DOS-specific startup files. 

Re: Gtk version getting closer

[Kenichi Handa]

In article <m18EfMJ-000IeAC@localhost>, "Robert J. Chassell" <bob@rattlesnake.com> writes:
> I suspect that many people use a 1024x768 screen with the default
> fonts, a white background and all that, but am not sure.  I run the
> default fonts in the `plain vanilla' Emacs, but have a higher
> resolution screen.

> Do others on this list have a sense of what should be a good default?

At the above is first mail I read thoroughly on this topic,
I don't know if this idea has already been discussed or not.

I think the right thing is to decide the tooltip X/Y offset
according to the size and position of the rectangle area
that activates the tooltip, not according to the mouse
position.  Then we can make tooltip never overlap with the
rectangle area, for instance, by aligning the bottom-left
corner of the tooltip with 5/-5 offset from the top-left
corder of the rectangle area will be good.  This is for
people who use the default mouse cursor.  People who use a
mouse cursor of which hot spot is at bottom may want to
allign the top-left corner of the tooltip with the
bottom-left corner of the rectangle area.

Example:
     +------------------------------+
     |        tooltip text          |
     +------------------------------+
   +---------------+
   |  ICON         |
   |     or MENU   |
   +---------------+

---
Ken'ichi HANDA
handa@m17n.org

Re: Gtk version getting closer

[Miles Bader]

On Thu, Nov 21, 2002 at 10:09:29PM +0900, Kenichi Handa wrote:
> I think the right thing is to decide the tooltip X/Y offset according to
> the size and position of the rectangle area that activates the tooltip, not
> according to the mouse position.  Then we can make tooltip never overlap
> with the rectangle

I think that's an excellent idea -- it would yield much more consistent
results than the current method.  One thing I noticed about the windows
tooltips is that they pop up neatly aligned with the edge of the menu entry
or whatever, whereas the emacs ones seem placed sort of randomly (presumably
they're at a constant offset from the mouse pointer's position when the
tooltip popped up, but the offset from the actual menu item is much more
noticable).

Perhaps it would also be good to pass a hint as to the preferred side of
rectangle to put the tooltip on (which I guess would be ignored if there
wasn't enough space).

-Miles

-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: Gtk version getting closer

[Jason Rumney]

Miles Bader <miles@gnu.org> writes:

> One thing I noticed about the windows tooltips is that they pop up
> neatly aligned with the edge of the menu entry or whatever

MS-Windows? All the tooltips I've seen on that platform are placed a
certain offset from the mouse pointer (below and to the right if
there's room, but avoiding the bottom and right edge of the
screen). It is relatively easy to make tooltips obscure the item they
are pointing to if you try, although it doesn't happen accidentally
as often as with the default settings in Emacs, I think due to the
positioning of the tooltip as below the pointer instead of above where
it is near the hotspot. 

Gnome on the other hand seems to position them vertically relative to
the menu entry or whatever (below), and horizontally relative to the
mouse (centered, which I'm not sure I like, but maybe its a case of
getting used to it).

> Perhaps it would also be good to pass a hint as to the preferred side of
> rectangle to put the tooltip on (which I guess would be ignored if there
> wasn't enough space).

They should be consistent. Tooltips popping up in different places
based on the preferences of some elisp package author would not be
good.

Re: Gtk version getting closer

[Richard Stallman]

       way, since the pointer usually points upwards. So my suggestion would
       be to default to 

       (setq tooltip-x-offset 0)
       (setq tooltip-y-offset 40)

Could others please try this and comment?  Would this be an
improvement?  Should we use -40 instead of 40?

Do people want to implement smarter methods of preventing the tooltip
from hiding the menu item?

    I don't know what people would like.  The best value depends both on a
    person's screen and on the font they are using.

Perhaps instead of using fixed values specified by these variables
it could calculate the values based on the size of the menu item.

    I think the right thing is to decide the tooltip X/Y offset
    according to the size and position of the rectangle area
    that activates the tooltip, not according to the mouse
    position.  Then we can make tooltip never overlap with the
    rectangle area, for instance, by aligning the bottom-left
    corner of the tooltip with 5/-5 offset from the top-left
    corder of the rectangle area will be good.

Yes, exactly.  The question is, how hard is that to implement
given the toolkits as they are?

Re: Bold by moving pixels problem

[Miles Bader]

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

I've attached a patch below that's implements the `final face
realization filtering' function that bob wanted.  This is just a
first-cut, so I'd appreciate any comments people have.

The basic interface is a variable, `realize-face-filter':

   realize-face-filter's value is nil

   If non-nil, a function called to perturb faces before final realization.
   It is passed a lisp-vector containing all the attributes of the
   fully-specified face, and can change any that it wishes.

For instance the following will completely turn off bold fonts:

   (defun unboldify-lface (lface)
     (aset lface 4 'normal))
   (setq realize-face-filter 'unboldify-lface)
   (clear-face-cache)

It seems to work fine.

If I instrument the filter function a bit, like:

   (defvar ubf-count 0)
   (defun unboldify-lface (lface)
     (setq ubf-count (1+ ubf-count))
     (aset lface 4 'normal))
   (setq realize-face-filter 'unboldify-lface)
   (clear-face-cache)

`ubf-count' seems to continually incremented (if I keep checking in
*scratch* it goes up 2 or 3 each time, but if I display a complicated
new buffer, it can go up by 100).  It doesn't seem noticably slow to me,
but I have a reasonably fast cpu (1GHz).

I guess I'll need to see exactly what it's getting called on, but this
suggests that maybe more places should be checking the face cache
(or that the face-cache checking should be moved into realize_face).
[Gerd, are you listening...?]

Also, perhaps `realize-face-filter' should be a list of functions
instead, e.g., `realize-face-filter-functions', as there might be
circumstances when two entities want to add a filter -- but maybe this
is something that will only ever be changed by the end-user, who can
make his own filter function do everything he wants.

Any comments?

Thanks,

-Miles

Patch:



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: realize-face-filter-20021217.patch --]
[-- Type: text/x-patch, Size: 2064 bytes --]

Index: src/xfaces.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/xfaces.c,v
retrieving revision 1.266
diff -u -r1.266 xfaces.c
--- src/xfaces.c	17 Nov 2002 23:51:19 -0000	1.266
+++ src/xfaces.c	17 Dec 2002 04:31:36 -0000
@@ -422,6 +422,13 @@
 
 Lisp_Object Vtty_defined_color_alist;
 
+/* If non-nil, a function called to perturb faces before final realization.
+   It is passed a lisp-vector containing all the attributes of the
+   fully-specified face, and can change any that it wishes. */
+
+Lisp_Object Vrealize_face_filter;
+
+
 /* Counter for calls to clear_face_cache.  If this counter reaches
    CLEAR_FONT_TABLE_COUNT, and a frame has more than
    CLEAR_FONT_TABLE_NFONTS load, unused fonts are freed.  */
@@ -6691,6 +6698,21 @@ realize_face (cache, attrs, c, base_face
       free_realized_face (cache->f, former_face);
     }
 
+  if (! NILP (Vrealize_face_filter))
+    {
+      /* Call a user-defined function to perturb the face attributes
+	 before realization.  */
+      Lisp_Object lface = Fmake_vector (make_number (LFACE_VECTOR_SIZE),
+					Qunspecified);
+      bcopy (attrs, XVECTOR (lface)->contents,
+	     LFACE_VECTOR_SIZE * (sizeof *attrs));
+
+      safe_call1 (Vrealize_face_filter, lface);
+
+      bcopy (XVECTOR (lface)->contents, attrs,
+	     LFACE_VECTOR_SIZE * (sizeof *attrs));
+    }      
+
   if (FRAME_WINDOW_P (cache->f))
     face = realize_x_face (cache, attrs, c, base_face);
   else if (FRAME_TERMCAP_P (cache->f) || FRAME_MSDOS_P (cache->f))
@@ -7670,6 +7692,13 @@
 Each element is a regular expression that matches names of fonts to
 ignore.  */);
   Vface_ignored_fonts = Qnil;
+
+  DEFVAR_LISP ("realize-face-filter", &Vrealize_face_filter,
+	       doc: /* If non-nil, a function called to perturb faces before final realization.
+It is passed a lisp-vector containing all the attributes of the
+fully-specified face, and can change any that it wishes. */);
+  Vrealize_face_filter = Qnil;
+
 
 #ifdef HAVE_WINDOW_SYSTEM
   defsubr (&Sbitmap_spec_p);

[-- Attachment #3: Type: text/plain, Size: 192 bytes --]



-- 
[|nurgle|]  ddt- demonic? so quake will have an evil kinda setting? one that 
            will  make every christian in the world foamm at the mouth? 
[iddt]      nurg, that's the goal 

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Bold by moving pixels problem

[Miles Bader]

I wrote:
> `ubf-count' seems to continually incremented (if I keep checking in
> *scratch* it goes up 2 or 3 each time, but if I display a complicated
> new buffer, it can go up by 100).
> 
> I guess I'll need to see exactly what it's getting called on, but this
> suggests that maybe more places should be checking the face cache
> (or that the face-cache checking should be moved into realize_face).

Duh!  I just realized why it's doing this, because with the previous
patch I sent, it _inserts_ into the cache using the post-filter-function
attributes, but _looks up_ in the cache using pre-filter-function
attributes (so cached faces never get properly found later).

I'll fix it...

-Miles
-- 
80% of success is just showing up.  --Woody Allen

Re: Bold by moving pixels problem

[Miles Bader]

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

Ok, this new patch should fix the previously mentioned problem; now the
face-caching seems to be working correctly, and realize-face-filter
doesn't get called too often (in an emacs that I've been using for a
while, it's only been called 78 times).

Thanks,

-Miles


Patch:



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: realize-face-filter-20021217-1.patch --]
[-- Type: text/x-patch, Size: 9170 bytes --]

2002-12-17  Miles Bader  <miles@gnu.org>

	* xfaces.c (Vrealize_face_filter): New variable.
	(realize_face): If Vrealize_face_filter has a non-nil value, use
	it to filter the face attributes before realization.  Use new
	calling conventsions for realize_x_face, realize_tty_face, and
	load_face_font.
	(realize_x_face, realize_tty_face): Add new argument FACE, and
	change return type to void.  Use FACE instead of creating our own.
	(load_face_font): Add a new argument ATTRS, and use it instead of
	FACE->lface.
	(syms_of_xfaces): Initialize Vrealize_face_filter.

Index: src/xfaces.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/xfaces.c,v
retrieving revision 1.266
diff -u -r1.266 xfaces.c
--- src/xfaces.c	17 Nov 2002 23:51:19 -0000	1.266
+++ src/xfaces.c	17 Dec 2002 07:01:09 -0000
@@ -422,6 +422,13 @@
 
 Lisp_Object Vtty_defined_color_alist;
 
+/* If non-nil, a function called to perturb faces before final realization.
+   It is passed a lisp-vector containing all the attributes of the
+   fully-specified face, and can change any that it wishes. */
+
+Lisp_Object Vrealize_face_filter;
+
+
 /* Counter for calls to clear_face_cache.  If this counter reaches
    CLEAR_FONT_TABLE_COUNT, and a frame has more than
    CLEAR_FONT_TABLE_NFONTS load, unused fonts are freed.  */
@@ -481,7 +488,7 @@
 static unsigned char *xstrlwr P_ ((unsigned char *));
 static void signal_error P_ ((char *, Lisp_Object));
 static struct frame *frame_or_selected_frame P_ ((Lisp_Object, int));
-static void load_face_font P_ ((struct frame *, struct face *, int));
+static void load_face_font P_ ((struct frame *, struct face *, Lisp_Object *, int));
 static void load_face_colors P_ ((struct frame *, struct face *, Lisp_Object *));
 static void free_face_colors P_ ((struct frame *, struct face *));
 static int face_color_gray_p P_ ((struct frame *, char *));
@@ -502,10 +509,10 @@
 static int cmp_font_names P_ ((const void *, const void *));
 static struct face *realize_face P_ ((struct face_cache *, Lisp_Object *, int,
 				      struct face *, int));
-static struct face *realize_x_face P_ ((struct face_cache *,
-					Lisp_Object *, int, struct face *));
-static struct face *realize_tty_face P_ ((struct face_cache *,
-					  Lisp_Object *, int));
+static void realize_x_face P_ ((struct face *, struct face_cache *,
+				Lisp_Object *, int, struct face *));
+static void realize_tty_face P_ ((struct face *, struct face_cache *,
+				  Lisp_Object *, int));
 static int realize_basic_faces P_ ((struct frame *));
 static int realize_default_face P_ ((struct frame *));
 static void realize_named_face P_ ((struct frame *, Lisp_Object, int));
@@ -1245,14 +1252,15 @@
 
 #ifdef HAVE_WINDOW_SYSTEM
 
-/* Load font of face FACE which is used on frame F to display
-   character C.  The name of the font to load is determined by lface
-   and fontset of FACE.  */
+/* Load font of face FACE with attributes ATTRS which is used on frame F to
+   display character C.  The name of the font to load is determined by
+   lface and fontset of FACE.  */
 
 static void
-load_face_font (f, face, c)
+load_face_font (f, face, attrs, c)
      struct frame *f;
      struct face *face;
+     Lisp_Object *attrs;
      int c;
 {
   struct font_info *font_info = NULL;
@@ -1262,7 +1270,7 @@
   face->font_info_id = -1;
   face->font = NULL;
 
-  font_name = choose_face_font (f, face->lface, face->fontset, c,
+  font_name = choose_face_font (f, attrs, face->fontset, c,
 				&needs_overstrike);
   if (!font_name)
     return;
@@ -6678,6 +6686,11 @@
      int former_face_id;
 {
   struct face *face;
+  /* The set of attributes this face is know by to the user, as opposed to
+     the set actually used to render the face.  They're usually the same
+     as, but may be different if some attribute is changed by
+     realize-face-filter.  */
+  Lisp_Object *orig_attrs = attrs;
 
   /* LFACE must be fully specified.  */
   xassert (cache != NULL);
@@ -6691,41 +6704,59 @@
       free_realized_face (cache->f, former_face);
     }
 
+  if (! NILP (Vrealize_face_filter))
+    {
+      /* Call a user-defined function to perturb the face attributes
+	 before realization.  */
+      Lisp_Object lface = Fmake_vector (make_number (LFACE_VECTOR_SIZE),
+					Qunspecified);
+      bcopy (attrs, XVECTOR (lface)->contents,
+	     LFACE_VECTOR_SIZE * (sizeof *attrs));
+
+      safe_call1 (Vrealize_face_filter, lface);
+
+      attrs = XVECTOR (lface)->contents;
+    }      
+
+  /* Allocate a new realized face.  */
+  face = make_realized_face (orig_attrs);
+
+  /* Fill it in.  */
   if (FRAME_WINDOW_P (cache->f))
-    face = realize_x_face (cache, attrs, c, base_face);
+    realize_x_face (face, cache, attrs, c, base_face);
   else if (FRAME_TERMCAP_P (cache->f) || FRAME_MSDOS_P (cache->f))
-    face = realize_tty_face (cache, attrs, c);
+    realize_tty_face (face, cache, attrs, c);
   else
     abort ();
 
   /* Insert the new face.  */
-  cache_face (cache, face, lface_hash (attrs));
+  cache_face (cache, face, lface_hash (orig_attrs));
 #ifdef HAVE_WINDOW_SYSTEM
   if (FRAME_WINDOW_P (cache->f) && face->font == NULL)
-    load_face_font (cache->f, face, c);
+    load_face_font (cache->f, face, attrs, c);
 #endif  /* HAVE_WINDOW_SYSTEM */
   return face;
 }
 
 
-/* Realize the fully-specified face with attributes ATTRS in face
-   cache CACHE for character C.  Do it for X frame CACHE->f.  If C is
-   a multibyte character, BASE_FACE is a face that has the same
-   attributes.  Otherwise, BASE_FACE is ignored.  If the new face
-   doesn't share font with the default face, a fontname is allocated
-   from the heap and set in `font_name' of the new face, but it is not
-   yet loaded here.  Value is a pointer to the newly created realized
-   face.  */
+/* Realize into FACE the fully-specified face with attributes ATTRS in face
+   cache CACHE for character C.  Do it for X frame CACHE->f.  If C is a
+   multibyte character, BASE_FACE is a face that has the same attributes.
+   Otherwise, BASE_FACE is ignored.  If the new face doesn't share font
+   with the default face, a fontname is allocated from the heap and set in
+   `font_name' of the new face, but it is not yet loaded here.  Value is a
+   pointer to the newly created realized face.  */
 
-static struct face *
-realize_x_face (cache, attrs, c, base_face)
+static void
+realize_x_face (face, cache, attrs, c, base_face)
+     struct face *face;
      struct face_cache *cache;
      Lisp_Object *attrs;
      int c;
      struct face *base_face;
 {
 #ifdef HAVE_WINDOW_SYSTEM
-  struct face *face, *default_face;
+  struct face *default_face;
   struct frame *f;
   Lisp_Object stipple, overline, strike_through, box;
 
@@ -6733,9 +6764,6 @@
   xassert (SINGLE_BYTE_CHAR_P (c)
 	   || base_face);
 
-  /* Allocate a new realized face.  */
-  face = make_realized_face (attrs);
-
   f = cache->f;
 
   /* If C is a multibyte character, we share all face attirbutes with
@@ -6751,7 +6779,7 @@
 
       /* to force realize_face to load font */
       face->font = NULL;
-      return face;
+      return;
     }
 
   /* Now we are realizing a face for ASCII (and unibyte) characters.  */
@@ -6921,7 +6949,6 @@
     face->stipple = load_pixmap (f, stipple, &face->pixmap_w, &face->pixmap_h);
 
   xassert (FACE_SUITABLE_FOR_CHAR_P (face, c));
-  return face;
 #endif /* HAVE_WINDOW_SYSTEM */
 }
 
@@ -7012,17 +7039,16 @@
 }
 
 
-/* Realize the fully-specified face with attributes ATTRS in face
-   cache CACHE for character C.  Do it for TTY frame CACHE->f.  Value is a
-   pointer to the newly created realized face.  */
+/* Realize into FACE the fully-specified face with attributes ATTRS in face
+   cache CACHE for character C.  Do it for TTY frame CACHE->f.  */
 
-static struct face *
-realize_tty_face (cache, attrs, c)
+static void
+realize_tty_face (face, cache, attrs, c)
+     struct face *face;
      struct face_cache *cache;
      Lisp_Object *attrs;
      int c;
 {
-  struct face *face;
   int weight, slant;
   int face_colors_defaulted = 0;
   struct frame *f = cache->f;
@@ -7030,8 +7056,6 @@
   /* Frame must be a termcap frame.  */
   xassert (FRAME_TERMCAP_P (cache->f) || FRAME_MSDOS_P (cache->f));
 
-  /* Allocate a new realized face.  */
-  face = make_realized_face (attrs);
   face->font_name = FRAME_MSDOS_P (cache->f) ? "ms-dos" : "tty";
 
   /* Map face attributes to TTY appearances.  We map slant to
@@ -7068,8 +7092,6 @@
       && face->background == FACE_TTY_DEFAULT_FG_COLOR
       && face->foreground == FACE_TTY_DEFAULT_BG_COLOR)
     face->tty_bold_p = 0;
-
-  return face;
 }
 
 
@@ -7670,6 +7692,13 @@
 Each element is a regular expression that matches names of fonts to
 ignore.  */);
   Vface_ignored_fonts = Qnil;
+
+  DEFVAR_LISP ("realize-face-filter", &Vrealize_face_filter,
+	       doc: /* If non-nil, a function called to perturb faces before final realization.
+It is passed a lisp-vector containing all the attributes of the
+fully-specified face, and can change any that it wishes. */);
+  Vrealize_face_filter = Qnil;
+
 
 #ifdef HAVE_WINDOW_SYSTEM
   defsubr (&Sbitmap_spec_p);

[-- Attachment #3: Type: text/plain, Size: 49 bytes --]



-- 
Quidquid latine dictum sit, altum viditur.

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Bold by moving pixels problem

[Kim F. Storm]

Miles Bader <miles@lsi.nec.co.jp> writes:

> 
> The basic interface is a variable, `realize-face-filter':

Shouldn't it be called `realize-face-filter-function' ?

> Also, perhaps `realize-face-filter' should be a list of functions
> instead, e.g., `realize-face-filter-functions', as there might be
> circumstances when two entities want to add a filter -- but maybe this
> is something that will only ever be changed by the end-user, who can
> make his own filter function do everything he wants.

You may be right, but once the realize-face-filter-function feature
has been added, some elisp package is bound to emerge which uses it to
solve some unforeseen problem... and want to add its own filter
function.  So I definitely think it should be a list (and as you said
in a subsequent mail, it really doesn't get called very often, so it
shouldn't really matter).

[Sorry, I haven't had time to look at the patch].

Re: Bold by moving pixels problem

[Robert J. Chassell]

Many thanks!

The second version of the patch that implements the `final face
realization filtering' function works fine.  I can finally read the
`m' in my *mail* buffer mode line!

I put the following in my .emacs file

      (defun unboldify-lface (lface)
        (aset lface 4 'normal))

      (setq realize-face-filter 'unboldify-lface)

      (clear-face-cache)

and all is well, as far as I have tested it.

My only issue is semantic:  I continue to have `bold' faces, but I
set `bold' to be a color, not a weight.  What it seems you are doing
is not so much `unboldifying' the face as removing a

    :weight bold

attribute.  Should we not call the defun  `face-normal-weight'?

      (defun face-normal-weight (lface)
        (aset lface 4 'normal))
      (setq realize-face-filter 'face-normal-weight)
      (clear-face-cache)

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: Bold by moving pixels problem

[Miles Bader]

On Tue, Dec 17, 2002 at 04:38:57PM +0000, Robert J. Chassell wrote:
> My only issue is semantic:  I continue to have `bold' faces, but I
> set `bold' to be a color, not a weight.  What it seems you are doing
> is not so much `unboldifying' the face as removing a
> 
>     :weight bold
> 
> attribute.  Should we not call the defun  `face-normal-weight'?

Well, I didn't think very much about the name of that function.  It probably
shouldn't really use the work `face', because it doesn't operate on normal
faces, but rather the low-level internal representation of them (for which
the term `lface' is sometimes used).

You can make it translate bold into a color too, by similarly

  (defun lface-change-bold-to-yellow (lface)
    (if (memq (aref lface 4) '(bold heavy ...)) ; whatever weights you need
        (progn
	  (aset lface 4 'normal)  ; unboldify
	  (aset lface 8 "yellow"))))

WARNING: When I was trying a more complicated function like this yesterday,
my emacs aborted (in UNBLOCK_INPUT), so something funny is going on, I'm not
sure exactly what.  However it might still be too dangerous for casual use
(luckily emacs is great at not losing data, but it's still no fun when it
crashes).

-Miles
-- 
[|nurgle|]  ddt- demonic? so quake will have an evil kinda setting? one that 
            will  make every christian in the world foamm at the mouth? 
[iddt]      nurg, that's the goal 

Re: Bold by moving pixels problem

[Miles Bader]

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

Here's an updated version of my patch, that uses a list of functions:



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: realize-face-filter-20021218-0.patch --]
[-- Type: text/x-patch, Size: 9543 bytes --]

2002-12-17  Miles Bader  <miles@gnu.org>

	* xfaces.c (Vrealize_face_filter_functions): New variable.
	(realize_face): If Vrealize_face_filter_functions has a non-nil
	value, use it to filter the face attributes before realization.
	Use new calling conventions for realize_x_face, realize_tty_face,
	and load_face_font.
	(realize_x_face, realize_tty_face): Add new argument FACE, and
	change return type to void.  Use FACE instead of creating our own.
	(load_face_font): Add a new argument ATTRS, and use it instead of
	FACE->lface.
	(syms_of_xfaces): Initialize Vrealize_face_filter_functions.

Index: src/xfaces.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/xfaces.c,v
retrieving revision 1.266
diff -u -r1.266 xfaces.c
--- src/xfaces.c	17 Nov 2002 23:51:19 -0000	1.266
+++ src/xfaces.c	18 Dec 2002 05:26:34 -0000
@@ -422,6 +422,13 @@
 
 Lisp_Object Vtty_defined_color_alist;
 
+/* A list of functions to perturb faces before final realization.
+   They are passed a lisp-vector containing all the attributes of the
+   fully-specified face, and can change any that they wish. */
+
+Lisp_Object Vrealize_face_filter_functions;
+
+
 /* Counter for calls to clear_face_cache.  If this counter reaches
    CLEAR_FONT_TABLE_COUNT, and a frame has more than
    CLEAR_FONT_TABLE_NFONTS load, unused fonts are freed.  */
@@ -481,7 +488,7 @@
 static unsigned char *xstrlwr P_ ((unsigned char *));
 static void signal_error P_ ((char *, Lisp_Object));
 static struct frame *frame_or_selected_frame P_ ((Lisp_Object, int));
-static void load_face_font P_ ((struct frame *, struct face *, int));
+static void load_face_font P_ ((struct frame *, struct face *, Lisp_Object *, int));
 static void load_face_colors P_ ((struct frame *, struct face *, Lisp_Object *));
 static void free_face_colors P_ ((struct frame *, struct face *));
 static int face_color_gray_p P_ ((struct frame *, char *));
@@ -502,10 +509,10 @@
 static int cmp_font_names P_ ((const void *, const void *));
 static struct face *realize_face P_ ((struct face_cache *, Lisp_Object *, int,
 				      struct face *, int));
-static struct face *realize_x_face P_ ((struct face_cache *,
-					Lisp_Object *, int, struct face *));
-static struct face *realize_tty_face P_ ((struct face_cache *,
-					  Lisp_Object *, int));
+static void realize_x_face P_ ((struct face *, struct face_cache *,
+				Lisp_Object *, int, struct face *));
+static void realize_tty_face P_ ((struct face *, struct face_cache *,
+				  Lisp_Object *, int));
 static int realize_basic_faces P_ ((struct frame *));
 static int realize_default_face P_ ((struct frame *));
 static void realize_named_face P_ ((struct frame *, Lisp_Object, int));
@@ -1245,14 +1252,15 @@
 
 #ifdef HAVE_WINDOW_SYSTEM
 
-/* Load font of face FACE which is used on frame F to display
-   character C.  The name of the font to load is determined by lface
-   and fontset of FACE.  */
+/* Load font of face FACE with attributes ATTRS which is used on frame F to
+   display character C.  The name of the font to load is determined by
+   lface and fontset of FACE.  */
 
 static void
-load_face_font (f, face, c)
+load_face_font (f, face, attrs, c)
      struct frame *f;
      struct face *face;
+     Lisp_Object *attrs;
      int c;
 {
   struct font_info *font_info = NULL;
@@ -1262,7 +1270,7 @@
   face->font_info_id = -1;
   face->font = NULL;
 
-  font_name = choose_face_font (f, face->lface, face->fontset, c,
+  font_name = choose_face_font (f, attrs, face->fontset, c,
 				&needs_overstrike);
   if (!font_name)
     return;
@@ -6678,6 +6686,11 @@
      int former_face_id;
 {
   struct face *face;
+  /* The set of attributes this face is know by to the user, as opposed to
+     the set actually used to render the face.  They're usually the same
+     as, but may be different if some attribute is changed by
+     realize-face-filter.  */
+  Lisp_Object *orig_attrs = attrs;
 
   /* LFACE must be fully specified.  */
   xassert (cache != NULL);
@@ -6691,41 +6704,70 @@
       free_realized_face (cache->f, former_face);
     }
 
+  if (CONSP (Vrealize_face_filter_functions))
+    {
+      /* Call these user-defined functions to perturb the face attributes
+	 before realization.  */
+      Lisp_Object filters, cycle_check;
+      Lisp_Object lface = Fmake_vector (make_number (LFACE_VECTOR_SIZE),
+					Qunspecified);
+
+      bcopy (attrs, XVECTOR (lface)->contents,
+	     LFACE_VECTOR_SIZE * (sizeof *attrs));
+
+      cycle_check = Qnil;
+      for (filters = Vrealize_face_filter_functions;
+	   CONSP (filters);
+	   filters = XCDR (filters))
+	{
+	  safe_call1 (XCAR (filters), lface);
+	  cycle_check = CYCLE_CHECK (cycle_check, filters, 50);
+	  if (NILP (cycle_check))
+	    break;		/* cycle detected */
+	}
+
+      attrs = XVECTOR (lface)->contents;
+    }      
+
+  /* Allocate a new realized face.  */
+  face = make_realized_face (orig_attrs);
+
+  /* Fill it in.  */
   if (FRAME_WINDOW_P (cache->f))
-    face = realize_x_face (cache, attrs, c, base_face);
+    realize_x_face (face, cache, attrs, c, base_face);
   else if (FRAME_TERMCAP_P (cache->f) || FRAME_MSDOS_P (cache->f))
-    face = realize_tty_face (cache, attrs, c);
+    realize_tty_face (face, cache, attrs, c);
   else
     abort ();
 
   /* Insert the new face.  */
-  cache_face (cache, face, lface_hash (attrs));
+  cache_face (cache, face, lface_hash (orig_attrs));
 #ifdef HAVE_WINDOW_SYSTEM
   if (FRAME_WINDOW_P (cache->f) && face->font == NULL)
-    load_face_font (cache->f, face, c);
+    load_face_font (cache->f, face, attrs, c);
 #endif  /* HAVE_WINDOW_SYSTEM */
   return face;
 }
 
 
-/* Realize the fully-specified face with attributes ATTRS in face
-   cache CACHE for character C.  Do it for X frame CACHE->f.  If C is
-   a multibyte character, BASE_FACE is a face that has the same
-   attributes.  Otherwise, BASE_FACE is ignored.  If the new face
-   doesn't share font with the default face, a fontname is allocated
-   from the heap and set in `font_name' of the new face, but it is not
-   yet loaded here.  Value is a pointer to the newly created realized
-   face.  */
+/* Realize into FACE the fully-specified face with attributes ATTRS in face
+   cache CACHE for character C.  Do it for X frame CACHE->f.  If C is a
+   multibyte character, BASE_FACE is a face that has the same attributes.
+   Otherwise, BASE_FACE is ignored.  If the new face doesn't share font
+   with the default face, a fontname is allocated from the heap and set in
+   `font_name' of the new face, but it is not yet loaded here.  Value is a
+   pointer to the newly created realized face.  */
 
-static struct face *
-realize_x_face (cache, attrs, c, base_face)
+static void
+realize_x_face (face, cache, attrs, c, base_face)
+     struct face *face;
      struct face_cache *cache;
      Lisp_Object *attrs;
      int c;
      struct face *base_face;
 {
 #ifdef HAVE_WINDOW_SYSTEM
-  struct face *face, *default_face;
+  struct face *default_face;
   struct frame *f;
   Lisp_Object stipple, overline, strike_through, box;
 
@@ -6733,9 +6775,6 @@
   xassert (SINGLE_BYTE_CHAR_P (c)
 	   || base_face);
 
-  /* Allocate a new realized face.  */
-  face = make_realized_face (attrs);
-
   f = cache->f;
 
   /* If C is a multibyte character, we share all face attirbutes with
@@ -6751,7 +6790,7 @@
 
       /* to force realize_face to load font */
       face->font = NULL;
-      return face;
+      return;
     }
 
   /* Now we are realizing a face for ASCII (and unibyte) characters.  */
@@ -6921,7 +6960,6 @@
     face->stipple = load_pixmap (f, stipple, &face->pixmap_w, &face->pixmap_h);
 
   xassert (FACE_SUITABLE_FOR_CHAR_P (face, c));
-  return face;
 #endif /* HAVE_WINDOW_SYSTEM */
 }
 
@@ -7012,17 +7050,16 @@
 }
 
 
-/* Realize the fully-specified face with attributes ATTRS in face
-   cache CACHE for character C.  Do it for TTY frame CACHE->f.  Value is a
-   pointer to the newly created realized face.  */
+/* Realize into FACE the fully-specified face with attributes ATTRS in face
+   cache CACHE for character C.  Do it for TTY frame CACHE->f.  */
 
-static struct face *
-realize_tty_face (cache, attrs, c)
+static void
+realize_tty_face (face, cache, attrs, c)
+     struct face *face;
      struct face_cache *cache;
      Lisp_Object *attrs;
      int c;
 {
-  struct face *face;
   int weight, slant;
   int face_colors_defaulted = 0;
   struct frame *f = cache->f;
@@ -7030,8 +7067,6 @@
   /* Frame must be a termcap frame.  */
   xassert (FRAME_TERMCAP_P (cache->f) || FRAME_MSDOS_P (cache->f));
 
-  /* Allocate a new realized face.  */
-  face = make_realized_face (attrs);
   face->font_name = FRAME_MSDOS_P (cache->f) ? "ms-dos" : "tty";
 
   /* Map face attributes to TTY appearances.  We map slant to
@@ -7068,8 +7103,6 @@
       && face->background == FACE_TTY_DEFAULT_FG_COLOR
       && face->foreground == FACE_TTY_DEFAULT_BG_COLOR)
     face->tty_bold_p = 0;
-
-  return face;
 }
 
 
@@ -7670,6 +7703,14 @@
 Each element is a regular expression that matches names of fonts to
 ignore.  */);
   Vface_ignored_fonts = Qnil;
+
+  DEFVAR_LISP ("realize-face-filter-functions",
+	       &Vrealize_face_filter_functions,
+	       doc:/* A list of functions to perturb faces before final realization.
+They are passed a lisp-vector containing all the attributes of the
+fully-specified face, and can change any that they wish. */);
+  Vrealize_face_filter_functions = Qnil;
+
 
 #ifdef HAVE_WINDOW_SYSTEM
   defsubr (&Sbitmap_spec_p);

[-- Attachment #3: Type: text/plain, Size: 59 bytes --]



Also, here's a lisp file that implements some filters:



[-- Attachment #4: Some filters for face-realization --]
[-- Type: application/emacs-lisp, Size: 2270 bytes --]

[-- Attachment #5: Type: text/plain, Size: 165 bytes --]



-Miles
-- 
I'm beginning to think that life is just one long Yoko Ono album; no rhyme
or reason, just a lot of incoherent shrieks and then it's over.  --Ian Wolff

[-- Attachment #6: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Bold by moving pixels problem

[Kim F. Storm]

Miles Bader <miles@lsi.nec.co.jp> writes:

> Here's an updated version of my patch, that uses a list of functions:
> 
> 
> 
> 2002-12-17  Miles Bader  <miles@gnu.org>
> 
> 	* xfaces.c (Vrealize_face_filter_functions): New variable.
> 	(realize_face): If Vrealize_face_filter_functions has a non-nil
> 	value, use it to filter the face attributes before realization.
> 	Use new calling conventions for realize_x_face, realize_tty_face,
> 	and load_face_font.


I've looked at your patch, and it seems to be very low-level to give
the filter functions direct access to the actual lface vector elements.

I'd suggest a different approach using the internal-lisp-face attribute
names that are already defined in xfaces.c such as :family, :height, etc.

Instead of the raw lface vector, the filter function should receive
a plist with all of the current lface attributes (:family X :height Y ...),
and it should return a (possibly) modified plist ... which is then
passed on to the next filter function in the list.

When all filter functions have been called, the plist is used to
build the final lface vector.

It might be a little less efficient than using the raw vector, but
this doesn't get called very often anyway (according to your own
statistics).  And not at all if Vrealize_face_filter_functions is nil.

Example:
 
Your code:
> 
> (defun lface-emulate-bold-with-color (lface)
>   (if (memq (aref lface 4)
> 	    '(bold heavy extra-bold semi-bold ultra-bold))
>       (let ((fg-vals (color-values (aref lface 8))))
> 	;; unboldify
> 	(aset lface 4 'normal)
> 	;; Tweak the fg color to indicate bold.
> 	(cond ((equal fg-vals '(65535 65535 65535))
> 	       (aset lface 8 "khaki"))
> 	      ((equal fg-vals '(0 0 0))
> 	       (aset lface 8 "orange4"))
> 	      (t
> 	       ;; intensify the color
> 	       (aset lface 8 (highlight-color (aref lface 8) 2 5000)))))))

becomes something like this: [not tested]

(defun lface-emulate-bold-with-color (lface)
  (let ((weight (plist-get lface :weight))
        (fg (plist-get lface :foreground)))
    (if (memq weight '(bold heavy extra-bold semi-bold ultra-bold))
        (let ((fg-vals (color-values fg)))
	  ;; unboldify
	  (setq lface (plist-put lface :weight 'normal))
	  ;; Tweak the fg color to indicate bold.
	  (cond ((equal fg-vals '(65535 65535 65535))
		 (setq lface (plist-put lface :foreground "khaki")))
		((equal fg-vals '(0 0 0))
		 (setq lface (plist-put lface :foreground "orange4")))
		(t
		 ;; intensify the color
		 (setq lface (plist-put lface :foreground
					(highlight-color fg 2 5000))))))))
  lface)

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Bold by moving pixels problem

[Robert J. Chassell]

On 18 Dec 2002 19:01:01 +0900, Miles Bader <miles@lsi.nec.co.jp> wrote:

   Here's an updated version of my patch, that uses a list of functions:

Success report.

This works so far, using an even more updated
CVS snapshot from today, Wed, 2002 Dec 18  13:25 UTC,
GNU Emacs 21.3.50.31 (i686-pc-linux-gnu, X toolkit)
on a concurrently updated
Debian GNU/Linux, `sarge' (`testing'), kernel 2.4.18 system
under GNOME/sawfish, with my usual .emacs file.

Thanks!

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: Bold by moving pixels problem

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> I've looked at your patch, and it seems to be very low-level to give
> the filter functions direct access to the actual lface vector elements.

Well, it's a low-level thing... :-)

> I'd suggest a different approach using the internal-lisp-face attribute
> names that are already defined in xfaces.c such as :family, :height, etc.

I agree, code filled with `(aref .. 3)' is not good.  Going all the
way to a plist seems a bit gratuitous though.

What about just providing accessor/setter macros for `lface' vectors,
e.g., (lface-weight LFACE) and (set-lface-weight LFACE VAL)?

After all the `lface' representation _is_ exposed to lisp already, so
such macros might help other code as well.

[I'm not sure about the term `lface' though -- it's used fairly
 pervasively in the C code, but of course that's from the perspective of
 the C code...]

-Miles
-- 
The secret to creativity is knowing how to hide your sources.
  --Albert Einstein

signal handling bogosities

[Miles Bader]

I've got another core dump from my face-realization-filter code
(see attached backtrace), and seeing it raises some more fundamental
questions about the redisplay code.

Basically the problem seem to be that it's evaluating lisp code in a
place where it shouldn't, though I'm not sure I understand all the rules
for exactly where is OK and where is not.

The point of failure is this, in `Feval' (eval.c, line 1983):

  if (handling_signal)
    abort ();

it _is_ in a signal handler, specifically:

   #16 0x080dc6f2 in input_available_signal (signo=29)
       at /usr/local/src/emacs/src/keyboard.c:6633

That signal results in `note_mouse_movement', and then
`note_mouse_highlight' being called:

   #11 0x080b2345 in note_mouse_highlight (f=0x850aa18, x=184, y=260)
       at /usr/local/src/emacs/src/xterm.c:7407
   #12 0x080b162e in note_mouse_movement (frame=0x850aa18, event=0xbffd1064)
       at /usr/local/src/emacs/src/xterm.c:6893
   #13 0x080b5f05 in handle_one_xevent (dpyinfo=0x84f5490, eventp=0xbffd13ac, 
       bufp_r=0xbffd1418, numcharsp=0xbffd141c, finish=0xbffd13a8)
       at /usr/local/src/emacs/src/xterm.c:11291

note_mouse_highlight then tries to figure out the proper mouse-face-id,
which calls face realization, and if realize-face-filter-functions has
a non-nil value, calls the lisp interpreter, and thus dies as seen.

Now, I suppose that calling the lisp interpreter inside a signal handler
might be a bad thing, and so perhaps the check in Feval is reasonable
(though the byte-code evaluator _doesn't_ seem to check; perhaps if I
compiled my code, it would work :-).

What concerns me is that even without that, it seems to be doing an
absurd amount of stuff inside the the signal handler, to the extent that
it seems very hard to be sure _what_ code will end being called.  After
it does the face lookup that killed me, it seems to go and actually
display the mouse face, and in other branches of the code the whole
redisplay engine seems to be invoked, for exposure events (I don't know
whether that can result in lisp code being called, but it seems as if it
could -- given the complexity of redisplay, it's kind of hard to tell).

So what do people think?  The whole thing seems really broken to me, but
I don't have a complete grasp of the code.  How hard would be to
restructure things to just queue this stuff for an event-loop outside
the signal handler to handle?

Thanks,

-Miles



Here's the full backtrace:


#0  0x402eac51 in kill () from /lib/libc.so.6
#1  0x080d377a in abort () at /usr/local/src/emacs/src/emacs.c:412
#2  0x0812b44a in Feval (form=1481199500)
    at /usr/local/src/emacs/src/eval.c:1984
#3  0x081292b2 in Fprogn (args=1481198692)
    at /usr/local/src/emacs/src/eval.c:424
#4  0x0812c586 in funcall_lambda (fun=1481198684, nargs=1, 
    arg_vector=0xbffd0b08) at /usr/local/src/emacs/src/eval.c:2921
#5  0x0812c1b1 in Ffuncall (nargs=2, args=0xbffd0b04)
    at /usr/local/src/emacs/src/eval.c:2798
#6  0x0812a880 in internal_condition_case_2 (bfun=0x812bebc <Ffuncall>, 
    nargs=2, args=0xbffd0b04, handlers=405463828, 
    hfun=0x805cd10 <safe_eval_handler>) at /usr/local/src/emacs/src/eval.c:1435
#7  0x0805ce03 in safe_call (nargs=2, args=0xbffd0b04)
    at /usr/local/src/emacs/src/xdisp.c:1400
#8  0x0805ce38 in safe_call1 (fn=408560044, arg=1220621664)
    at /usr/local/src/emacs/src/xdisp.c:1420
#9  0x080a2a9e in realize_face (cache=0x850f090, attrs=0xbffd0c68, c=0, 
    base_face=0x0, former_face_id=-1) at /usr/local/src/emacs/src/xfaces.c:6723
#10 0x080a3b95 in face_at_buffer_position (w=0x8cf3e78, pos=1983, 
    region_beg=0, region_end=0, endptr=0xbffd0d6c, limit=1984, mouse=1)
    at /usr/local/src/emacs/src/xfaces.c:5648
#11 0x080b2345 in note_mouse_highlight (f=0x850aa18, x=184, y=260)
    at /usr/local/src/emacs/src/xterm.c:7407
#12 0x080b162e in note_mouse_movement (frame=0x850aa18, event=0xbffd1064)
    at /usr/local/src/emacs/src/xterm.c:6893
#13 0x080b5f05 in handle_one_xevent (dpyinfo=0x84f5490, eventp=0xbffd13ac, 
    bufp_r=0xbffd1418, numcharsp=0xbffd141c, finish=0xbffd13a8)
    at /usr/local/src/emacs/src/xterm.c:11291
#14 0x080b654d in XTread_socket (sd=0, bufp=0xbffd244c, numchars=4096, 
    expected=1) at /usr/local/src/emacs/src/xterm.c:11719
#15 0x080dc531 in read_avail_input (expected=1)
    at /usr/local/src/emacs/src/keyboard.c:6470
#16 0x080dc6f2 in input_available_signal (signo=29)
    at /usr/local/src/emacs/src/keyboard.c:6633
#17 0x402eabd8 in sigaction () from /lib/libc.so.6
#18 0x08057271 in sit_for (sec=30, usec=0, reading=1, display=1, 
    initial_display=0) at /usr/local/src/emacs/src/dispnew.c:6247
#19 0x080d8305 in read_char (commandflag=1, nmaps=2, maps=0xbfffeb60, 
    prev_event=405463780, used_mouse_menu=0xbfffebac)
    at /usr/local/src/emacs/src/keyboard.c:2635
#20 0x080de7a0 in read_key_sequence (keybuf=0xbfffecb0, bufsize=30, 
    prompt=405463780, dont_downcase_last=0, can_return_switch_frame=1, 
    fix_current_buffer=1) at /usr/local/src/emacs/src/keyboard.c:8398
#21 0x080d63f8 in command_loop_1 () at /usr/local/src/emacs/src/keyboard.c:1478
#22 0x0812a689 in internal_condition_case (bfun=0x80d60f0 <command_loop_1>, 
    handlers=405560436, hfun=0x80d5d04 <cmd_error>)
    at /usr/local/src/emacs/src/eval.c:1352
#23 0x080d5fc8 in command_loop_2 () at /usr/local/src/emacs/src/keyboard.c:1279
#24 0x0812a21d in internal_catch (tag=405521716, 
    func=0x80d5fa4 <command_loop_2>, arg=405463780)
    at /usr/local/src/emacs/src/eval.c:1112
#25 0x080d5f73 in command_loop () at /usr/local/src/emacs/src/keyboard.c:1258
#26 0x080d5ac0 in recursive_edit_1 ()
    at /usr/local/src/emacs/src/keyboard.c:974
#27 0x080d5bf0 in Frecursive_edit ()
    at /usr/local/src/emacs/src/keyboard.c:1030
#28 0x080d4a83 in main (argc=3, argv=0xbffff274)
    at /usr/local/src/emacs/src/emacs.c:1659

-- 
Yo mama's so fat when she gets on an elevator it HAS to go down.

Re: Bold by moving pixels problem

[Miles Bader]

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

BTW, here's a version of the face-filter lisp example code I sent
before, rewritten to use some macros instead; it's quite a bit more
readable!  I used the term `facevec' instead of `lface', since it's a
bit more obvious, but that's just a suggestion...

-Miles



[-- Attachment #2: Example realize-face-filter-functions filters --]
[-- Type: application/emacs-lisp, Size: 3594 bytes --]

[-- Attachment #3: Type: text/plain, Size: 201 bytes --]



-- 
`Cars give people wonderful freedom and increase their opportunities.
 But they also destroy the environment, to an extent so drastic that
 they kill all social life' (from _A Pattern Language_)

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Bold by moving pixels problem

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> > What about just providing accessor/setter macros for `lface' vectors,
> > e.g., (lface-weight LFACE) and (set-lface-weight LFACE VAL)?
> 
> IMO, That's just adding stuff to remedy the wrong approach; the plist
> approach doesn't need adding _any_ new stuff at the lisp level.

But it adds a fair amount of hair at the C level -- and a few lisp
macros is not something to worry about.

> > After all the `lface' representation _is_ exposed to lisp already, so
> > such macros might help other code as well.
> 
> Excuse my ignorance, but where is that exposed already?

See `face-attributes-as-vector'.

> > [I'm not sure about the term `lface' though -- it's used fairly
> >  pervasively in the C code, but of course that's from the perspective of
> >  the C code...]
> 
> It seems to be called (internal-)lisp-face in stuff like
> internal-make-lisp-face (try apropos on "internal lisp face").
> lisp-face-vector may be a good name?

No, that's too long, and really, the term `lisp-' is rather silly in
this context.

-Miles
-- 
Yo mama's so fat when she gets on an elevator it HAS to go down.

Re: Bold by moving pixels problem

[Kim F. Storm]

Miles Bader <miles@lsi.nec.co.jp> writes:

> storm@cua.dk (Kim F. Storm) writes:
> > I've looked at your patch, and it seems to be very low-level to give
> > the filter functions direct access to the actual lface vector elements.
> 
> Well, it's a low-level thing... :-)
> 
> > I'd suggest a different approach using the internal-lisp-face attribute
> > names that are already defined in xfaces.c such as :family, :height, etc.
> 
> I agree, code filled with `(aref .. 3)' is not good.  Going all the
> way to a plist seems a bit gratuitous though.

IMHO, the only argument for the current implementation vs. a plist would be
performance.

> 
> What about just providing accessor/setter macros for `lface' vectors,
> e.g., (lface-weight LFACE) and (set-lface-weight LFACE VAL)?

IMO, That's just adding stuff to remedy the wrong approach; the plist approach
doesn't need adding _any_ new stuff at the lisp level.

> 
> After all the `lface' representation _is_ exposed to lisp already, so
> such macros might help other code as well.

Excuse my ignorance, but where is that exposed already?

> 
> [I'm not sure about the term `lface' though -- it's used fairly
>  pervasively in the C code, but of course that's from the perspective of
>  the C code...]

It seems to be called (internal-)lisp-face in stuff like internal-make-lisp-face
(try apropos on "internal lisp face").  lisp-face-vector may be a good name?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Bold by moving pixels problem

[Miles Bader]

BTW, there's another possibility, which might be better than either the
`macro' or `plist' approaches --

A while back I toyed with the idea of using face-vectors as `anonymous'
faces, since it's often a pain to have to name a face.

On reason I didn't really do anything was that I figured there are
probably places, in the redisplay code especially, which wouldn't work
well without a named face (though at the time I wanted to make
anonymous faces to inherit from, which should work fine).

However, in many places, it's trival -- in particular
`internal-get-lisp-face-attribute' and `internal-set-lisp-face-attribute',
since they use vectors internally and just translate the face-symbol into a
vector at their start (the latter function would require a bit more tweaking,
but as far as I could see, it's still fair to call it `trivial').

Now if those two functions were changed to allow `anonymous' faces (face
vectors), then such functions as `face-attribute', `set-face-attribute',
`make-face-bold', etc., would all start working on face-vectors too!

That way, functions in realize-face-filter-functions could still accept face-
vectors, avoiding the plist translation step, but also use the same familiar
face functions that users already know about; this seems like a huge win to
me... 

[p.s. I'd still like to also allow anonymous faces in more places, but that's
a separate issue]

-Miles
-- 
80% of success is just showing up.  --Woody Allen

Re: Bold by moving pixels problem

[Kim F. Storm]

Miles Bader <miles@gnu.org> writes:

> Now if those two functions were changed to allow `anonymous' faces (face
> vectors), then such functions as `face-attribute', `set-face-attribute',
> `make-face-bold', etc., would all start working on face-vectors too!

Bright idea!

> 
> That way, functions in realize-face-filter-functions could still accept face-
> vectors, avoiding the plist translation step, but also use the same familiar
> face functions that users already know about; this seems like a huge win to
> me... 

I like that!

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: signal handling bogosities

[Gerd Moellmann]

Miles Bader <miles@lsi.nec.co.jp> writes:
> Eli suggested that you might be a good person to ask about the
> following problem (I presume you're not subscribed to emacs-devel).

Hi Miles.  No, I'm not reading emacs-devel.

[...]

> Basically the problem seem to be that it's evaluating lisp code in a
> place where it shouldn't, though I'm not sure I understand all the rules
> for exactly where is OK and where is not.

The rule is pretty simple: one must not modify the state of the Lisp
interpreter while handling a signal because the Lisp interpreter isn't
reentrant.

[...]

> Now, I suppose that calling the lisp interpreter inside a signal handler
> might be a bad thing, and so perhaps the check in Feval is reasonable
> (though the byte-code evaluator _doesn't_ seem to check; perhaps if I
> compiled my code, it would work :-).

I don't think so :).

The Lisp interpreter doesn't protect itself against signals, that is,
the signal might have interrupted the interpreter at an arbitrary
point.  It's very dangerous to change anything from a signal handler
that the Lisp interpreter itself might be working on in the normal
thread of execution.

The fact that handling_signal is only checked in one place is just
because I didn't want to slow down things.  IIRC, there wasn't any
such check before I added one which meant that one could screw up
Emacs without even noticing.

> What concerns me is that even without that, it seems to be doing an
> absurd amount of stuff inside the the signal handler, to the extent that
> it seems very hard to be sure _what_ code will end being called.  

Well said.

> After it does the face lookup that killed me, it seems to go and
> actually display the mouse face, and in other branches of the code
> the whole redisplay engine seems to be invoked, for exposure events
> (I don't know whether that can result in lisp code being called, but
> it seems as if it could -- given the complexity of redisplay, it's
> kind of hard to tell).

The code in xterm.c carefully avoids modifying that state of the Lisp
interpreter asynchronously (or let's say it did when I resigned; I
don't know what it does now), but you're absolutely right that it's
hard to see it does that without studying the code in detail.

> So what do people think?  The whole thing seems really broken to me, but
> I don't have a complete grasp of the code.  How hard would be to
> restructure things to just queue this stuff for an event-loop outside
> the signal handler to handle?

I felt this way of doing X from a signal handler is broken ever since
I started to write the new redisplay and studied that part of the code
in Emacs 19.

And there's not just the problem that Lisp can't be called from the
signal handling code, it also goes the other way 'round.  Normal code
can be interrupted at any time by a signal, so anything used in
xterm.c had better be in a consistent state when the signal is
processed; that's the reason why regions of code in xfaces.c, for
example, protect themselves against signals.

And to add to that, some Xt functionality (specifically timeouts) is
tightly coupled to having an Xt event loop.  That's why widgets using
timeouts, like some scroll bar and menu widgets, don't work well with
Emacs, or don't work without jumping through hoops.

BTW, XEmacs developers told me it is using a normal event loop instead
of the signal abomination.

My feeling is that the cost of restructuring the code to use an event
loop could be pretty high, but I've never investigated this very
deeply because Richard thought the current way of doing things is
good, and an event loop is an abomination :).  There were lots of
other things to do anyway, so I didn't pursue this further.

Specifically for mouse-highlighting there may be a cheaper solution,
though.  IIRC, I once talked with Stefan Monnier about generating
mouse-highlight input events for mouse highlights instead of doing the
display directly when handling the mouse movement event (analogous to
help-echo, for example).

When that is done, normal redisplay could be used to draw the
mouse-highlight, but it would have to be extended to use mouse-face
for part of the text, which it currently doesn't.  Also, the logic
determining which parts of a buffer/window are to be redisplayed would
have to be extended somehow so that the highlighted region is
displayed despite the fact that there have been no buffer changes.

Re: signal handling bogosities

[Miles Bader]

Gerd Moellmann <gerd.moellmann@t-online.de> writes:
> My feeling is that the cost of restructuring the code to use an event
> loop could be pretty high, but I've never investigated this very
> deeply because Richard thought the current way of doing things is
> good, and an event loop is an abomination :).  There were lots of
> other things to do anyway, so I didn't pursue this further.
> 
> Specifically for mouse-highlighting there may be a cheaper solution,
> though.  IIRC, I once talked with Stefan Monnier about generating
> mouse-highlight input events for mouse highlights instead of doing the
> display directly when handling the mouse movement event (analogous to
> help-echo, for example).
> 
> When that is done, normal redisplay could be used to draw the
> mouse-highlight, but it would have to be extended to use mouse-face
> for part of the text, which it currently doesn't.  Also, the logic
> determining which parts of a buffer/window are to be redisplayed would
> have to be extended somehow so that the highlighted region is
> displayed despite the fact that there have been no buffer changes.

Perhaps I'm confused, but why can't the existing code that runs from the
signal handler just be called from the event loop instead, at least as
an easy first-step?

For instance, if the signal handler currently looks like:

   void signal_handler (...)
   {
     if (some_test)
       do_mouse_stuff (mouse_info);
     else if (some_other_test)
       do_exposure_stuff (other info);
   }

change it to be like:

   void signal_handler (...)
   {
     if (some_test)
       queue_mouse_event (mouse_info);
     else if (some_other_test)
       queue_exposure_event (exposure_info);
   }

   void event_loop_function (...)
   {
      while (event in event loop)
        {
          ...
          if (event->type == mouse_event)
            do_mouse_stuff (event->mouse_info)
          else if (event->type == exposure_event)
            do_exposure_stuff (event->exposure_info)
          ...
        }
   }

In other words, re-use as much of the existing code as possible, but
change the place where it's called.

My (vague) reasoning is that if it currently can be called from a
_signal handler_, which is possibly the worst possible case, then the
code must be pretty safe to call from just about anywhere -- so why not
the event loop?

Thanks,

-Miles
-- 
I'm beginning to think that life is just one long Yoko Ono album; no rhyme
or reason, just a lot of incoherent shrieks and then it's over.  --Ian Wolff

Re: signal handling bogosities

[Gerd Moellmann]

Miles Bader <miles@lsi.nec.co.jp> writes:

> Perhaps I'm confused, but why can't the existing code that runs from the
> signal handler just be called from the event loop instead, at least as
> an easy first-step?
> 
> For instance, if the signal handler currently looks like:
> 
>    void signal_handler (...)
>    {
>      if (some_test)
>        do_mouse_stuff (mouse_info);
>      else if (some_other_test)
>        do_exposure_stuff (other info);
>    }
> 
> change it to be like:
> 
>    void signal_handler (...)
>    {
>      if (some_test)
>        queue_mouse_event (mouse_info);
>      else if (some_other_test)
>        queue_exposure_event (exposure_info);
>    }
> 
>    void event_loop_function (...)
>    {
>       while (event in event loop)
>         {
>           ...
>           if (event->type == mouse_event)
>             do_mouse_stuff (event->mouse_info)
>           else if (event->type == exposure_event)
>             do_exposure_stuff (event->exposure_info)
>           ...
>         }
>    }
> 
> In other words, re-use as much of the existing code as possible, but
> change the place where it's called.

What I was thinking about as "event loop" is a toolkit's event loop,
like XtAppMainLoop etc. for Xt, for instance.

I must admit that I never thought about using a home-brewed event
loop, so I can't say much about what that entails, sorry.

Re: signal handling bogosities

[Gerd Moellmann]

storm@cua.dk (Kim F. Storm) writes:

> gerd.moellmann@t-online.de (Gerd Moellmann) writes:
> 
> > 
> > I must admit that I never thought about using a home-brewed event
> > loop, so I can't say much about what that entails, sorry.
> 
> But emacs already has its own home-brewed event loop in
> kbd_buffer_get_event:

Well, I don't understand what the "but" refers to :).

[...]

> Adding DELAYED_MOUSE_EVENT and DELAYED_EXPOSURE_EVENT to
> that list doesn't seem to be too difficult??

If you mean mouse highlighting with DELAYED_MOUSE_EVENT, that's
essentially what I talked about previously.

For handling other events likewise---as I said, I haven't analyzed
that.  For example, seeing exposures mentioned, I don't know if it
would be acceptable to not redraw anything while Emacs is busy.  Maybe
it is, maybe it isn't.

Someone will have to analyze all the consequences of a new
implementation for all kinds of events.

Re: signal handling bogosities

[Kim F. Storm]

gerd.moellmann@t-online.de (Gerd Moellmann) writes:

> 
> I must admit that I never thought about using a home-brewed event
> loop, so I can't say much about what that entails, sorry.

But emacs already has its own home-brewed event loop in
kbd_buffer_get_event:

      if (event->kind == SELECTION_REQUEST_EVENT)
      else if (event->kind == SELECTION_CLEAR_EVENT)
      else if (event->kind == DELETE_WINDOW_EVENT)
      else if (event->kind == ICONIFY_EVENT)
      else if (event->kind == DEICONIFY_EVENT)
      else if (event->kind == BUFFER_SWITCH_EVENT)
      else if (event->kind == MENU_BAR_ACTIVATE_EVENT)
        ...

Adding DELAYED_MOUSE_EVENT and DELAYED_EXPOSURE_EVENT to
that list doesn't seem to be too difficult??


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: signal handling bogosities

[Richard Stallman]

    That signal results in `note_mouse_movement', and then
    `note_mouse_highlight' being called:

       #11 0x080b2345 in note_mouse_highlight (f=0x850aa18, x=184, y=260)
	   at /usr/local/src/emacs/src/xterm.c:7407
       #12 0x080b162e in note_mouse_movement (frame=0x850aa18, event=0xbffd1064)
	   at /usr/local/src/emacs/src/xterm.c:6893
       #13 0x080b5f05 in handle_one_xevent (dpyinfo=0x84f5490, eventp=0xbffd13ac, 
	   bufp_r=0xbffd1418, numcharsp=0xbffd141c, finish=0xbffd13a8)
	   at /usr/local/src/emacs/src/xterm.c:11291

    note_mouse_highlight then tries to figure out the proper mouse-face-id,
    which calls face realization, and if realize-face-filter-functions has
    a non-nil value, calls the lisp interpreter, and thus dies as seen.

I am surprised that the signal handler does face realization.  I would
have expected redisplay ought to do that job.  When the signal handler
runs, it should just look up the data that was computed by redisplay.

In the past, face realization did not evaluate any Lisp code, so
calling it from the signal handler was not a bug.  It may have been
bad design though.

    display the mouse face, and in other branches of the code the whole
    redisplay engine seems to be invoked, for exposure events (I don't know
    whether that can result in lisp code being called, but it seems as if it
    could -- given the complexity of redisplay, it's kind of hard to tell).

That seems bizarre too.  Can you please show me what you have learned
about this?

      How hard would be to
    restructure things to just queue this stuff for an event-loop outside
    the signal handler to handle?

That design has a serious drawback: the screen won't refresh while Emacs
is running.

The design idea used to be that the signal handler would update the
screen in a simple way based on tables that were computed in advance
by redisplay.  This avoided the problem we have now, and would
redisplay immediately even when Emacs is running.  Can we make it work
this way again?

Gerd wrote:

    Specifically for mouse-highlighting there may be a cheaper solution,
    though.  IIRC, I once talked with Stefan Monnier about generating
    mouse-highlight input events for mouse highlights instead of doing the
    display directly when handling the mouse movement event (analogous to
    help-echo, for example).

If we handle mouse highlighting by generating input events to do the
work at main program level, then the highlighting won't change when
you move the mouse while Emacs is running a Lisp program.  Is that
acceptable?

It is not as bad as failing to refresh the screen at all while
a Lisp program is running, but it is still somewhat undesirable.

Re: signal handling bogosities

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Fri, 20 Dec 2002 12:12:24 -0500
> 
> If we handle mouse highlighting by generating input events to do the
> work at main program level, then the highlighting won't change when
> you move the mouse while Emacs is running a Lisp program.  Is that
> acceptable?

I think it might be acceptable if Emacs displays the busy cursor (as
it does by default, IIRC).  The cursor chape tells the user that
Emacs is busy.

Re: signal handling bogosities

[Alex Schroeder]

Richard Stallman <rms@gnu.org> writes:

> If we handle mouse highlighting by generating input events to do the
> work at main program level, then the highlighting won't change when
> you move the mouse while Emacs is running a Lisp program.  Is that
> acceptable?

>From a user perspective, I think that is acceptable.  Sure, currently
most programs use a second thread for their GUI, so eventhough they
are busy, you can open menus -- but when it gets to doing something,
they are just as bound by the event queue as Emacs is -- you can open
the menu, look at it, click on it, but things only happen when the
previous job is done.  Since users cannot do anything anyway when
Emacs is busy, I think it is not a big plus to have highlighting
working.  Loosing that, therefore, is not a problem.

Alex.

Re: signal handling bogosities

[Miles Bader]

On Fri, Dec 20, 2002 at 12:12:24PM -0500, Richard Stallman wrote:
> If we handle mouse highlighting by generating input events to do the
> work at main program level, then the highlighting won't change when
> you move the mouse while Emacs is running a Lisp program.  Is that
> acceptable?

In fact I find it confusing (as a user) that it updates mouse-faces almost
always, but most things only when it's `ready'.  Since you can't actually
_do_ anything until emacs is ready to accept input, it seems much better to
have mouse-faces respond similarly to the way the rest of emacs does.

Anyway, that's my take.

-Miles
-- 
97% of everything is grunge

Re: signal handling bogosities

[Richard Stallman]

    In fact I find it confusing (as a user) that it updates mouse-faces almost
    always, but most things only when it's `ready'.

Emacs won't let you *change* text in the buffer until it is `ready',
and of course they don't update until they change.  By contrast, the
locus of mouse highlighting does change, whenever you move the mouse.

Re: signal handling bogosities

[Alex Schroeder]

Richard Stallman <rms@gnu.org> writes:

>     In fact I find it confusing (as a user) that it updates mouse-faces almost
>     always, but most things only when it's `ready'.
>
> Emacs won't let you *change* text in the buffer until it is `ready',
> and of course they don't update until they change.  By contrast, the
> locus of mouse highlighting does change, whenever you move the mouse.

True, but the question is "What for?"  Here is my interpretation:  The
point of highlighting certain areas when the mouse pointer is over
that particular area is to convey some information.  Usually the
information is "Use the second mouse button to do something".  But in
this case the user cannot click the second mouse button to do
something.  Emacs is already doing something else.  So in this
particular case, the information conveyed is wrong.

I know this just repeats what others have said, but I just wanted to
prevent that Miles' (?) argument is discarded just because he used the
wording "updates mouse-faces".

Alex.

Re: signal handling bogosities

[Miles Bader]

On Sat, Dec 21, 2002 at 03:26:32PM -0500, Richard Stallman wrote:
>     In fact I find it confusing (as a user) that it updates mouse-faces
>     almost always, but most things only when it's `ready'.
> 
> Emacs won't let you *change* text in the buffer until it is `ready',
> and of course they don't update until they change.  By contrast, the
> locus of mouse highlighting does change, whenever you move the mouse.

I'm sure there's a way you can think of it so that it `makes sense'
(and of course I understand technically why it happens the way it does).

None-the-less, I really do find it confusing in practice because seeing the
buffer contents apparently change makes it _feel_ like emacs is ready do so
something (even though it's not), and I'm subsequently surprised when I
try to do something else and can't.

Consider another apparently similar case:  In X (unlike some other window
systems), you can move, resize, and iconify windows even when the underlying
applications aren't ready to respond (and so can't redraw).  In contrast with
emacs mouse-faces, this _feels_ right to me.

I guess the only way I can explain the difference is that in X the window
frame title bar visually appear to be a `wrapper,' and I can easily think of
them as being a completely separate layer and thus follow different rules of
interaction.  In emacs, mouse highlighting is visually part of the buffer
contents, and so it's harder to think it as being somehow separate.
[However, I think it _would_ seem natural if one could move emacs-window
boundaries without being to actually interact with the buffer, because
they're visually distinct layers]

Anyway, those are my thoughts.

-Miles

-- 
`The suburb is an obsolete and contradictory form of human settlement'

Re: signal handling bogosities

[Miles Bader]

On Fri, Dec 20, 2002 at 12:12:24PM -0500, Richard Stallman wrote:
> I am surprised that the signal handler does face realization.  I would
> have expected redisplay ought to do that job.  When the signal handler
> runs, it should just look up the data that was computed by redisplay.

The mouse-face is merged with whatever underlying faces are in the buffer in
the highlighted region, so you can't just have one precomputed mouse-face.

I suppose you could have redisplay notice which regions might be highlighted,
and pre-cache the corresponding mouse-face/buffer-face combination so that it
doesn't happen at highlighting time, but I don't know how easy this would be
(and if the face cache gets flushed at the wrong toime, you have a problem!).

-Miles
-- 
Come now, if we were really planning to harm you, would we be waiting here, 
 beside the path, in the very darkest part of the forest?

Re: signal handling bogosities

[Richard Stallman]

    True, but the question is "What for?"  Here is my interpretation:  The
    point of highlighting certain areas when the mouse pointer is over
    that particular area is to convey some information.  Usually the
    information is "Use the second mouse button to do something".  But in
    this case the user cannot click the second mouse button to do
    something.

You can click the second mouse button then--the request won't
be processed immediately, but it will be processed.

(If your argument is valid, the real conclusion is that Emacs should
turn off the highlighting, not leave the highlighting in the place
where the mouse WAS.)

Re: signal handling bogosities

[Richard Stallman]

    The mouse-face is merged with whatever underlying faces are in the buffer in
    the highlighted region, so you can't just have one precomputed mouse-face.

We could have a precomputed mouse face for each glyph.

Re: signal handling bogosities

[Michael Livshin]

gerd.moellmann@t-online.de (Gerd Moellmann) writes:

> I must admit that I never thought about using a home-brewed event
> loop, so I can't say much about what that entails, sorry.

FWIW, I believe Xemacs uses a home-brewed event loop.  which allows
it to support such things as opening both X and text-terminal frames
in the same Emacs instance, for example.  very nifty.

-- 
I think people have a moral obligation to spell "deontic" correctly.
                                   -- Erik Naggum, in comp.lang.lisp

Re: signal handling bogosities

[Richard Stallman]

    FWIW, I believe Xemacs uses a home-brewed event loop.  which allows
    it to support such things as opening both X and text-terminal frames
    in the same Emacs instance, for example.  very nifty.

The XEmacs developers told me 10 years ago that XEmacs used an
inside-out structure, where Xt implements the event loop and calls
Emacs to handle each events.  That unnatural structure makes it
impossible to write your own loop in Lisp.  I rejected it.

They told me that it was impossible to handle Xt with a natural
structure, where the event loop uses the toolkit as a subroutine, but
we did it.  (Actually I think Paul Reilly did it.)

I will not accept that unnatural structure now, any more than I did 10
years ago.  However, I won't reject all possible changes in the event
loop.  It might be useful to rewrite the event loop in Lisp (keeping
its present natural structure).

Re: signal handling bogosities

[Jan D.]

> 
>     FWIW, I believe Xemacs uses a home-brewed event loop.  which allows
>     it to support such things as opening both X and text-terminal frames
>     in the same Emacs instance, for example.  very nifty.
> 
> The XEmacs developers told me 10 years ago that XEmacs used an
> inside-out structure, where Xt implements the event loop and calls
> Emacs to handle each events.  That unnatural structure makes it
> impossible to write your own loop in Lisp.  I rejected it.

One could argue that for a GUI application the XEmacs approach is the
natural loop :-)

> They told me that it was impossible to handle Xt with a natural
> structure, where the event loop uses the toolkit as a subroutine, but
> we did it.  (Actually I think Paul Reilly did it.)

But not without problems as this discussion shows.  Also, there are some
code just to overcome these problems (timers for example) that feels
like a kludge.  I see that Emacs does some polling when running under
X, there is a timeout for about half a second for each select call.
I don't know why, but I guess it is related.  This makes it hard
to debug events, if nothing else.

I read a paper about event loops on the net some time ago (no URL, sorry),
and it described the problems of integrating several event models.
Say you have some GUI toolkit, perhaps CORBA, some database access
toolkit, and a custom event loop for your application.  Trying to
integrate these into one loop is never easy since all these toolkits usually
assume you run their event loop and nothing else.  Some are more integration-
friendly than others (X/Xt is very friendly, GTK is very unfriendly).
Threads to the rescue, but that is not always that easy either.

> I will not accept that unnatural structure now, any more than I did 10
> years ago.  However, I won't reject all possible changes in the event
> loop.  It might be useful to rewrite the event loop in Lisp (keeping
> its present natural structure).

I haven't looked at this in detail, but it seems to me that a lot could be
gained if Emacs could wait for events in some toolkit specific routine,
like XtAppNextEvent for Xt.  Now it looks to me it does a select for
the X connection file descriptor.  The difference is that if we use
a toolkit routine, timers, signal handlers and idle callbacks and
possible other stuff the toolkit wants to do, gets handled normally.

Has this been considered?  It doesn't solve the redrawing while executing
lisp, but helps a bit.

	Jan D.

Re: signal handling bogosities

[Richard Stallman]

    > The XEmacs developers told me 10 years ago that XEmacs used an
    > inside-out structure, where Xt implements the event loop and calls
    > Emacs to handle each events.  That unnatural structure makes it
    > impossible to write your own loop in Lisp.  I rejected it.

    One could argue that for a GUI application the XEmacs approach is the
    natural loop :-)

It prevents the Lisp code from being natural.  That is more important.
The natural structure for an event loop in Lisp is

  (while ...
    (let ((input (read-events-somehow)))
      (execute input)))

Any change in Emacs that would prevent the Lisp code from looking like
this has a major drawback.

    I haven't looked at this in detail, but it seems to me that a lot could be
    gained if Emacs could wait for events in some toolkit specific routine,
    like XtAppNextEvent for Xt.

Emacs needs to wait for input from various descriptors at the same
time, adn with a timeout.  If it is possible to do that with
XtAppNextEvent, then it is possible to use XtAppNextEvent.

Re: signal handling bogosities

[Jan D.]

> 
>     I haven't looked at this in detail, but it seems to me that a lot could be
>     gained if Emacs could wait for events in some toolkit specific routine,
>     like XtAppNextEvent for Xt.
> 
> Emacs needs to wait for input from various descriptors at the same
> time, adn with a timeout.  If it is possible to do that with
> XtAppNextEvent, then it is possible to use XtAppNextEvent.

Yes it is.  I shall do some experiments.

	Jan D.

Re: Bold by moving pixels problem

[Kim F. Storm]

Miles Bader <miles@gnu.org> writes:

> A while back I toyed with the idea of using face-vectors as `anonymous'
> faces, since it's often a pain to have to name a face.

> However, in many places, it's trival -- in particular
> `internal-get-lisp-face-attribute' and `internal-set-lisp-face-attribute',
> since they use vectors internally and just translate the face-symbol into a
> vector at their start (the latter function would require a bit more tweaking,
> but as far as I could see, it's still fair to call it `trivial').
> 
> Now if those two functions were changed to allow `anonymous' faces (face
> vectors), then such functions as `face-attribute', `set-face-attribute',
> `make-face-bold', etc., would all start working on face-vectors too!
> 
> That way, functions in realize-face-filter-functions could still accept face-
> vectors, avoiding the plist translation step, but also use the same familiar
> face functions that users already know about; this seems like a huge win to
> me... 

Me too.

Did you try to implement this?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Bold by moving pixels problem

[Miles Bader]

On Tue, Jan 07, 2003 at 12:02:19PM +0100, Kim F. Storm wrote:
> > A while back I toyed with the idea of using face-vectors as `anonymous'
> > faces, since it's often a pain to have to name a face.
...
> > That way, functions in realize-face-filter-functions could still accept
> > face- vectors, avoiding the plist translation step, but also use the same
> > familiar face functions that users already know about; this seems like a
> > huge win to me...
> 
> Did you try to implement this?

I actually did so a long time ago but never went further, so maybe I can dig
up the patch I made.

The problem is that the signal/mouse-face problem I ran into make it a bit
dangerous to add the face-filtering feature in general, until that's solved
somehow.

-Miles
-- 
80% of success is just showing up.  --Woody Allen

Re: Bold by moving pixels problem

[Richard Stallman]

It might also make sense to use gensyms or other uninterned symbols as
anonymous faces.  That way, they could have informal names that would
help humans understand what's going on when they're in use.

Re: Bold by moving pixels problem

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> It might also make sense to use gensyms or other uninterned symbols as
> anonymous faces.  That way, they could have informal names that would
> help humans understand what's going on when they're in use.

Doing that would make them a lot more expensive, I think -- right now in
places such as the face-realization-filter code that was being talked
about, you've already got the face in the form of a vector, so all
you've got to do is box it and pass it on.

Requiring them to be named would require you to crank up all the rest of
the face creation machinery; currently it would also prevent the face
from ever being GCed (since emacs keeps a permanent list of all named
faces).

My idea, at least in this case, is something that can be used as a
temporary `in between' face, e.g., to represent the result of face
manipulation in the same way that the C code currently uses face
vectors.  Such faces are almost always going to be very short-lived so
it's arguable whether such anymous names would even be useful in
debugging.

-Miles
-- 
Fast, small, soon; pick any 2.