headers
Luc Teirlinck | 1 Apr 2006 02:52
Picon

Re: emacs-unicode-2: bootstrap failed due to recent mh-e changes

Bill Wohler wrote:

   If an update doesn't resolve the problem, please remove
   lisp/mh-e/*.elc and try again.

All of that is apparently not sufficient to solve the problem.  Still
same error message:

Compiling /home/teirllm/emacscvsdir/emacs/lisp/./mh-e/mh-e.el

In toplevel form: mh-e/mh-e.el:997:1:Error: Symbol's function
definition is void: mh-strip-package-version
make[2]: *** [compile] Error 1
make[2]: Leaving directory `/home/teirllm/emacscvsdir/emacs/lisp'
make[1]: *** [bootstrap-build] Error 2
make[1]: Leaving directory `/home/teirllm/emacscvsdir/emacs'
make: *** [bootstrap] Error 2
Permalink | Reply | 4 comments |
headers
Kevin Rodgers | 1 Apr 2006 02:55
Picon
Favicon

Re: Binding a command to the down-event of a toolbar button

Richard Stallman wrote:
>     I have never seen such a functionality in a *tool-bar*. But buttons
>     like these are common in "media players" of all kinds, where the
>     buttons are often part of some "cool" or "groovy" GUI. I would not
>     expect a tool-bar button to do that, but that's just me.
> 
> When Emacs has a media-player mode, we want it to have such buttons.
> 
> So, is it better for these buttons to appear in the buffer itself,
> or in the tool bar?  Better from a UI standpoint, that is.

If they were in the buffer itself, then they wouldn't depend on which
buffer was selected -- they would always be displayed, so the user could
always click on them, even while working in another buffer.  The tool
bar changes according to which buffer is selected, just like the menu
bar changes, because they are defined as keymaps.

If the buffer happened to display a long playlist, the header line would
be a good place to put the control buttons.

--

-- 
Kevin Rodgers
Permalink | Reply | 7 comments |
headers
Robert J. Chassell | 1 Apr 2006 03:12

Re: Binding a command to the down-event of a toolbar button

    > So, is it better for these buttons to appear in the buffer
    > itself, or in the tool bar?  Better from a UI standpoint, that
    > is.

Some of us do not use or see toolbars.  It is better that buttons
appear in the buffer than not appear at all.

What about consoles -- or people who are situationally or permanently
blind?

--
    Robert J. Chassell
    bob <at> rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc
Permalink | Reply | 0 comments |
headers
Luc Teirlinck | 1 Apr 2006 03:34
Picon

Re: locate-with-filter

Richard Stallman wrote:

   You would have to change the bindings in the button's (text-property)
   keymap if you want different commands to operate on the button.

The user would have to change button-map, but then he would have
changed the bindings for _all_ buttons of _any_ kind, which might not
be what the user wants.  In addition, he would _also_ have to rebind
help-follow.  So this seems hopeless.

   So there are two approaches:

   1. Say that users who want to change the behavior of the buttons should
      change the keymap that they use.

   2. Install your change in help-follow, and then we can get rid of the
      buttons' text property keymap.

The first possibility is very unattractive for the reasons explained above.

Getting rid of the button's keymap means reimplementing help-mode
without using buttons, quite a bit of work for little or no gain.  If
we install my three patches, there is no need to get rid of the
button's RET binding.  Quite to the contrary, it allows to safely hard
code RET in the introductory text, which is what we should be doing
anyway.  The help-echo text hardcodes it too.  So if RET would not
follow buttons any more, the help-echo would be deceiving.

An alternative to my third patch would be to simply delete help-follow
and help-follow-mouse entirely.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Luc Teirlinck | 1 Apr 2006 03:52
Picon

Re: locate-with-filter

Maybe I should clarify that the purpose of my third patch is twofold.
It makes help-follow work as advertised when called from Lisp and it
allows the user to make _additional_ bindings for help-follow and the
button functionality in help-mode, _without_ having to change
button-map, which is a much more far reaching change.

Sincerely,

Luc.
Permalink | Reply | 0 comments |
headers
Bill Wohler | 1 Apr 2006 03:06
Picon
Picon
Gravatar

Re: emacs-unicode-2: bootstrap failed due to recent mh-e changes

Luc Teirlinck <teirllm <at> dms.auburn.edu> wrote:

> Bill Wohler wrote:
> 
>    If an update doesn't resolve the problem, please remove
>    lisp/mh-e/*.elc and try again.
> 
> All of that is apparently not sufficient to solve the problem.  Still
> same error message:
> 
> Compiling /home/teirllm/emacscvsdir/emacs/lisp/./mh-e/mh-e.el
> 
> In toplevel form: mh-e/mh-e.el:997:1:Error: Symbol's function
> definition is void: mh-strip-package-version
> make[2]: *** [compile] Error 1
> make[2]: Leaving directory `/home/teirllm/emacscvsdir/emacs/lisp'
> make[1]: *** [bootstrap-build] Error 2
> make[1]: Leaving directory `/home/teirllm/emacscvsdir/emacs'
> make: *** [bootstrap] Error 2

I do not understand this. If you remove mh-e/*.elc, it compiles. If you
just touch mh-e/mh-e.el and compile it fails.

I found that making mh-strip-package-version a macro fixes the error
(which I just checked in). If someone would like to explain why this is
so, I would listen eagerly. Is this fixing the problem, or merely
masking the symptoms?

Color me baffled by the compiler (again).
(Continue reading)

Permalink | Reply | 2 comments |
headers
Luc Teirlinck | 1 Apr 2006 05:51
Picon

Re: emacs-unicode-2: bootstrap failed due to recent mh-e changes

Bill Wohler wrote:

   I do not understand this. If you remove mh-e/*.elc, it compiles. If you
   just touch mh-e/mh-e.el and compile it fails.

I did `make maintainer-clean' and I even checked that that really
removed all mh-e/*.elc files.  Bootstrapping nevertheless failed
(before your very latest change).

   I found that making mh-strip-package-version a macro fixes the error
   (which I just checked in)

Now bootstrapping indeed works again.

Sincerely,

Luc.
Permalink | Reply | 0 comments |
headers
Stefan Monnier | 1 Apr 2006 05:59
Picon

Re: Binding a command to the down-event of a toolbar button

> If they were in the buffer itself, then they wouldn't depend on which
> buffer was selected -- they would always be displayed, so the user could
> always click on them, even while working in another buffer.  The tool
> bar changes according to which buffer is selected, just like the menu
> bar changes, because they are defined as keymaps.

That's true, but if you check my snapshot (at
http://www.iro.umontreal.ca/~monnier/elisp/mpc.png), you'll see that my
MPC.el uses several buffers in several windows and the toolbar is a very
natural location to put those player buttons.  I could create
yet-another-buffer and recreate a sort of toolbar manually in it (playing
with display, face, mouse-face, and keymap properties).  It would allow me
to solve my problem with the down-event thingy, but it'd be a lot more work,
since I'd have to reinvent the wheel one more time.

> If the buffer happened to display a long playlist, the header line would
> be a good place to put the control buttons.

The header lines are already used for other things,

        Stefan
Permalink | Reply | 4 comments |
headers
M Jared Finder | 1 Apr 2006 05:12

Re: Binding a command to the down-event of a toolbar button

Richard Stallman wrote:
> 	>> Is such behavior normal in tool bars in other user interfaces?
> 	>> If not, I think we should not do it.
> 
>     Why not? It's often good to stick to "normal", "standard", or common UI
>     features so that users know what to expect. But what's the harm in providing
>     functionality where the common UIs have none?
> 
> You're missing the point.  You're proposing we implement the capacity
> to provide a certain kind of GUI feature.  Before we do that, I want
> to know whether users expect or want that kind of feature in GUIs.  If
> they don't, let's save the trouble of writing and maintaining code to
> implement it.

Yes, click and drag and mouse-2, mouse-3 are used in UIs.  Firefox is a 
good example of different things that are done with this:
* mouse-3 brings up a context menu that is used for customization
* mouse-2 opens a page in a new tab
* click and drag is used to move toolbar items around when in "customize 
toolbar" mode.

In short, yes, it would be useful to distinguish between different 
button presses in toolbars (and in the menus as well).

   -- MJF
Permalink | Reply | 11 comments |
headers
Drew Adams | 1 Apr 2006 09:44
Picon
Favicon

RE: Patch to fix frame positioning with negative top/left values onWindows

I've been using a 2005-06-26 CVS snapshot on Windows that had this bug. I
thought that this had been fixed since that snapshot. I just tried a
2006-03-20 snapshot on Windows, however, and the same bug is still there.

Did Fran's patch never get applied, or doesn't it work? His patch dates from
January of 2005 - soon to be a year and a half! The bug symptoms are the
same as before. See thread "Improved patch to fix frame positioning bug on
Windows" from 2005-01-14.

    -----Original Message-----
    From: emacs-devel-bounces+drew.adams=oracle.com <at> gnu.org
    [mailto:emacs-devel-bounces+drew.adams=oracle.com <at> gnu.org]On Behalf Of
    Francis Litterio
    Sent: Thursday, July 07, 2005 9:24 AM
    To: emacs-devel <at> gnu.org
    Cc: help-emacs-windows <at> gnu.org
    Subject: Patch to fix frame positioning with negative top/left values
    onWindows

    Emacs developers,

    This patch to the CVS Emacs sources fixes the way that function
    x_calc_absolute_position() accounts for the Windows-drawn borders around
    a frame when converting a negative 'top or 'left parameter into the
    equivalent positive value.

    I have submitted this patch before, but RMS told me that the FSF needed
    a copyright assignment from me before it could applied.  The FSF now has
    mysigned the copyright assignment, so please let me know if there's any
    problem with this patch.  I've been running Emacs with it for some
(Continue reading)

Permalink | Reply | 3 comments |

Gmane