June 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: bogus binding of button3 in widget keymaps... 26 years, 5 months

SL Baur

Hrvoje Niksic <hniksic(a)srce.hr> writes: > wmperry(a)aventail.com (William M. Perry) writes: ... >> If all else fails, I say we wrestle for it next time you are in the >> states. I might win that, if by no other means than falling on you. >> :) As all the godzilla movie trailers say 'size does matter'. You >> aren't over 6'8" are you? :) > Lemme check: > (+ (* 6 12 2.54) (* 8 2.54)) > => 203.2 > As a matter of fact, I am. *blush* Yowza. I guess that's Mr. Niksic, Sir! Hey Bill, pick on someone your own size ... :-)

1 participants
0 comments

Re: bogus binding of button3 in widget keymaps... 26 years, 5 months

Hrvoje Niksic

wmperry(a)aventail.com (William M. Perry) writes: > I still think we should just change the :button-keymap of the state > buttons. We are currently out of synch with Emacs, and forcing > _every_ other user of the widget library to override this behaviour, > which is really only used in the _custom_ library, seems a violation > of the abstractions. I guess this makes sense. However, I definitely want the default popup menu to remain popups on button3. > > > > Gnus article buffers don't have context-sensitive menus. If > > > > you are over a button/widget, button3 should present you a > > > > widget-specific menu. > > > > > > _mode_ sensitive menus, they do. And the mode you are in, to > > > me, is part of the context. So they are context sensitive. > > > > Bah. That's not "context-sensitive". Call it buffer-local or > > mode-local, but not context-sensitive. > > Then you may as well call the state button widget-local. :) > > If all else fails, I say we wrestle for it next time you are in the > states. I might win that, if by no other means than falling on you. > :) As all the godzilla movie trailers say 'size does matter'. You > aren't over 6'8" are you? :) Lemme check: (+ (* 6 12 2.54) (* 8 2.54)) => 203.2 As a matter of fact, I am. *blush* -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Try to use "ad nauseam" at least once per flame. It doesn't mean anything; but it gives that polished feel to your postings.

1 participants
0 comments

Re: where is sh-mode ? 26 years, 5 months

SL Baur

Didier Verna <verna(a)inf.enst.fr> writes: > I can't find it after the latest package upgrade. It's in the same place it's always been. C-h f sh-mode `sh-mode' is an interactive autoloaded Lisp function -- autoloads from "sh-script" Documentation: Shell Script Mode. M-x locate-library sh-script => Library is file /usr/local/lib/xemacs/xemacs-packages/lisp/sh-script/sh-script.elc

1 participants
0 comments

Re: bogus binding of button3 in widget keymaps... 26 years, 5 months

William M. Perry

Hrvoje Niksic <hniksic(a)srce.hr> writes: > wmperry(a)aventail.com (William M. Perry) writes: > > > Hrvoje Niksic <hniksic(a)srce.hr> writes: > > > > > wmperry(a)aventail.com (William M. Perry) writes: > > > > > > > Why not make button1 do what you want there? > > > > > > Context-sensitive menus have always been activated by button3, not > > > button1 or button2. Widgets like `State' look like a context-sensitive > > > menu to me. > > > > This isn't really context-sensitive though. That is _all_ the state > > button is meant to do. > > Yes, but when you click on a particular State button, you get the menu > pertaining to that button, not to all buttons. It's context-sensitive. No - it is a separate widget and has separate functions. I don't think it qualifies as context-sensitive. But that may well be a religious issue. :) I still think we should just change the :button-keymap of the state buttons. We are currently out of synch with Emacs, and forcing _every_ other user of the widget library to override this behaviour, which is really only used in the _custom_ library, seems a violation of the abstractions. > > The context-sensitive menus should be offering _additional_ > > functionality than the widget's main purpose. > > I agree. But then again, I've always thought that the State widget's > main purpose was very ugly in the UI sense. I haven't seen anything > else in Emacs pop up a menu when button2 is pressed on it. > > > > > You wouldn't be able to get the standard context sensitive menus > > > > in a GNUS article buffer if you just happened to have a > > > > buttonized/widgetized chunk of text under your mouse. > > > > > > Gnus article buffers don't have context-sensitive menus. If you > > > are over a button/widget, button3 should present you a > > > widget-specific menu. > > > > _mode_ sensitive menus, they do. And the mode you are in, to me, is > > part of the context. So they are context sensitive. > > Bah. That's not "context-sensitive". Call it buffer-local or > mode-local, but not context-sensitive. Then you may as well call the state button widget-local. :) If all else fails, I say we wrestle for it next time you are in the states. I might win that, if by no other means than falling on you. :) As all the godzilla movie trailers say 'size does matter'. You aren't over 6'8" are you? :) Or we could have a contest with our sons - whoever wears theirs out soonest and gets them put to bed wins. -Bill P.

1 participants
0 comments

XEmacs + Qt 26 years, 5 months

Martin Buchholz

>From an RMS interview: http://some.net/transcripts/rms-19980613-gnu.log <lilo> there's been a lot of recent discussion about the whole business with Qt and KDE....I had wanted to ask you, if you could, to talk about that whole business <rms> just because it encouraged someone to use GNU/Linux. <rms> Qt is a library which appears to be technically useful, but is not free software. <rms> Like all the other non-free programs out there, it's outside <rms> of the free software community. <rms> KDE is a free program which was developed so that it needs Qt in <rms> order to run. <rms> This has a paradoxical result: although KDE is free software, <rms> it is useless as an addition to a free operating system, <rms> because there is no way to run it on a free operating system. <rms> In order to run KDE, you need to add Qt, which means that the operating system is no longer entirely free. <rms> The KDE developers thought that they would "get the job done faster" <rms> if they used Qt--but the real result is that the wrong job got done. <rms> It's like saying, "we can build this segment of track faster if we don't <lilo> okay, for some of our participants who are maybe not clear on the problem with the Qt license....I don't want to take a lot of questions on this, but could you tell us what, in your opinion, "breaks" the Qt license as free software? <rms> make it connect with the other segment". Maybe so, but if it doesn't connect, <rms> you don't have a railroad that works. <rms> I would have to look at the Qt license again; it has been several months <rms> since I looked, and I don't remember.<lilo> okay, let's see.... <rms> I think it was either that it is limited to noncommercial distrbution only <rms> or that distribution of modified versions is not allowed, or both. * lilo nods <rms> Either kind of restriction makes a program non-free; I just don't remember for certain which of these restrictions Qt has. <rms> By the way, the Qt license says it gives permission to link Qt <rms> with GPL-covered programs; however, if you actually do that, you would <rms> violate the GPL. <rms> If the authors of a GPL-covered program want to give permission for linking it <rms> with Qt, they can do so. <lilo> so regardless of the flaws you see in it, it just simply doesn't work connecting it to the GPL<rms> It's clear that the authors of KDE mean to permit this, for example, <rms> so it is permitted *for KDE*. But if you wanted to link Emacs with Qt <rms> you would have to ask permission from the FSF, and I can tell you <rms> that the answer would be no. The purpose of releasing Emacs under the GPL <rms> is so that it can't be mixed with non-free software. Extended versions <rms> of Emacs must be free software.

1 participants
0 comments

Re: Release schedule for 21.0 26 years, 5 months

SL Baur

Ben Wing <ben(a)666.com> writes: > MULE-izing the MS Windows code in a weekish. Approved if you can keep it to that time frame.

1 participants
0 comments

Re: bogus binding of button3 in widget keymaps... 26 years, 5 months

Hrvoje Niksic

wmperry(a)aventail.com (William M. Perry) writes: > Hrvoje Niksic <hniksic(a)srce.hr> writes: > > > wmperry(a)aventail.com (William M. Perry) writes: > > > > > Why not make button1 do what you want there? > > > > Context-sensitive menus have always been activated by button3, not > > button1 or button2. Widgets like `State' look like a context-sensitive > > menu to me. > > This isn't really context-sensitive though. That is _all_ the state > button is meant to do. Yes, but when you click on a particular State button, you get the menu pertaining to that button, not to all buttons. It's context-sensitive. > The context-sensitive menus should be offering _additional_ > functionality than the widget's main purpose. I agree. But then again, I've always thought that the State widget's main purpose was very ugly in the UI sense. I haven't seen anything else in Emacs pop up a menu when button2 is pressed on it. > > > You wouldn't be able to get the standard context sensitive menus > > > in a GNUS article buffer if you just happened to have a > > > buttonized/widgetized chunk of text under your mouse. > > > > Gnus article buffers don't have context-sensitive menus. If you > > are over a button/widget, button3 should present you a > > widget-specific menu. > > _mode_ sensitive menus, they do. And the mode you are in, to me, is > part of the context. So they are context sensitive. Bah. That's not "context-sensitive". Call it buffer-local or mode-local, but not context-sensitive. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- "A Real Programmer's code can awe with its fiendish brilliance, even as its crockishness appalls."

1 participants
0 comments

Re: bogus binding of button3 in widget keymaps... 26 years, 5 months

William M. Perry

Hrvoje Niksic <hniksic(a)srce.hr> writes: > wmperry(a)aventail.com (William M. Perry) writes: > > > Why not make button1 do what you want there? > > Context-sensitive menus have always been activated by button3, not > button1 or button2. Widgets like `State' look like a context-sensitive > menu to me. This isn't really context-sensitive though. That is _all_ the state button is meant to do. The context-sensitive menus should be offering _additional_ functionality than the widget's main purpose. To me, if I right-clicked on a standard widget, I would expect to see a menu with ways to take actions like widget-browse-at, 'activate' widget, etc. Or if it was in a 'repeat' widget, the add/insert/delete stuff would be a good candidate to be on a menu like this. > > You wouldn't be able to get the standard context sensitive menus in > > a GNUS article buffer if you just happened to have a > > buttonized/widgetized chunk of text under your mouse. > > Gnus article buffers don't have context-sensitive menus. If you are over > a button/widget, button3 should present you a widget-specific menu. _mode_ sensitive menus, they do. And the mode you are in, to me, is part of the context. So they are context sensitive. :) Otherwise we'd allways just see the standard undo/cut/copy/paste/clear/select/split/unsplit popup menu on button3. -Bill P.

1 participants
0 comments

Re: Toolbar and XEmacs 21.0-b43 26 years, 5 months

SL Baur

Oliver Graf <ograf(a)fga.de> writes: > Hi there! > My toolbar looks different after installing b43. My frame-background-mode > is 'dark. Has it something to do with this? Possibly. Do you have xpm in your binary[1]? Another reason for those kinds of colors is using the xbm version of the toolbar. Footnotes: [1] Check Installation, or M-x describe-installation.

1 participants
0 comments

Re: Ebola in vector key syntax 26 years, 5 months

Hrvoje Niksic

SL Baur <steve(a)vmailer.xemacs.org> writes: > I think it's wrong in this context that single digit numerics in > vectors get treated as control characters. A character is a > character is a character and not an integer. Yes, but we have to pay some attention to backward compatibility. Also, it's not real Ebola, because Ebola is a bug, and this is well-documented -- see docs of `define-key'. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Old numerical analysts never die, they just get disarrayed.

1 participants
0 comments

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta June 1998