March 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Mouse-1 actions [was Re: Unable to use File Open Panel] 25 years, 1 month

Oliver Graf

tor(a)spacetec.no (Tor Arntsen) writes: > On Mar 30, 17:49, Oliver Graf wrote: > >I think we having a multiplatform editor. Remember the mail Steven forwarded? > >Perhaps we will soon have a Mac platform to serve. What about One-Button mice? > >I think this is standart for those machines... > > well yes, fine, but if that implies *crippling* the Unix functionality > then we have a problem. > > Make the standard functionality optimal for 3-button mice and find a way > for the others to change the setting. And add a suggestion in the docs > for MS folks to buy a 3-button mouse, they're pretty cheap and that's > something to never regret (my PC always had one, btw). I don't think > that's an option for Mac though. > > But please don't cripple it for Unix just because of the MS port! Yup, as I say (I also love my trackman...). If we make it a theme which is defaulted to the machine the thing is running on (easy to implement via featurep), the users of different platforms will get the most natural feeling on their platform, without crippling unix functionality. And even a Windows user with a 'correct' mouse can switch theme to 'unix' and will also get the unix func. Regards, Oliver.

1 participants
0 comments

Re: Unable to use File Open Panel 25 years, 1 month

Hrvoje Niksic

Jonathan Harris <jhar(a)tardis.ed.ac.uk> writes: > > I don't think that would be a good idea. All over XEmacs, button1 is > > used to position the point, while button2 is used for selecting. > > Making list-mode an exception without changing anything else would > > only add to the confusion. > > That's not quite true; button1 on a glyph widget selects it (eg in > customize buffers). ...which only proves my point that changing these things is a long-term mistake because it confuses the hell out of everyone. It does make sense for button1 to select glyphs (Customize merely copied the way annotations.el has behaved for ages), because positioning the point to a glyph doesn't. > I'd like to see button1 select all "button-like" things. I suggest > that non-glyph widgets are certainly buttons. I also suggest that > filenames in Completion List Mode are more button-like than > text-like, especially when presented in the mouse-read-file frame if > not in general. Do you think that changing button1 to select > filenames in the mouse-read-file frame only and to select non-glyph > widgets would be a good thing or at least harmless? I don't know. In my humble opinion, Emacs users should get used to clicking with button2 everywhere, *or* we should do something about it. Kludging up individual modes in order to support the optional use of button1 for that purpose is clearly not the right thing. My opinions on all that are not very strong. If you really really think it would help people to select files with button1, I won't veto the change.

4 participants
5 comments

Re: Mouse-1 actions [was Re: Unable to use File Open Panel] 25 years, 1 month

Oliver Graf

tor(a)spacetec.no (Tor Arntsen) writes: > On Mar 30, 17:13, Andy Piper wrote: > >Just some more datapoints. 95% of mice on ms-windows systems I have used in > >the last 3-4 years do not have mouse 2. So my overriding concern is that it > >is just too damn inconvenient to hit two mouse buttons simultanously for > >common operations. Consistency does not concern me, I want XEmacs to be > >useable and intuitive, certainly in ms-windows environments that means > >mouse-1 for view type activities. We do it already for glyphs and other > >things. > > If XEmacs is going to get "optimised" for 2-button mice then IMO things are > going way too far. That about kills it for me. I think we having a multiplatform editor. Remember the mail Steven forwarded? Perhaps we will soon have a Mac platform to serve. What about One-Button mice? I think this is standart for those machines... So the whole thing gets better customized/themed (soon as we have this), or we're ending with one button... ;-) Regards, Oliver.

1 participants
0 comments

Re: Mouse-1 actions [was Re: Unable to use File Open Panel] 25 years, 1 month

Oliver Graf

Andy Piper <andy(a)xemacs.org> writes: > Just some more datapoints. 95% of mice on ms-windows systems I have used in > the last 3-4 years do not have mouse 2. So my overriding concern is that it > is just too damn inconvenient to hit two mouse buttons simultanously for > common operations. Consistency does not concern me, I want XEmacs to be > useable and intuitive, certainly in ms-windows environments that means > mouse-1 for view type activities. We do it already for glyphs and other > things. > > I can concede that you might not want to do this under UNIX - but our > delete key discussions have encompassed UNIX as well even though the > presence of delete is more normal under PC systems. [Just dropping into discussion] For me it seems quite intuitive to make the behaviour of button-1 (or should I say click-1) dependend on the position the click took place. XEmacs is not only a editor, it is also (in some modes) only a viewer (and will it ever be a word processor?). You can't edit a info file right away, so making click-1 the selector for hyperlinks is intiutive. In some editing mode, there is nothing (normally) you can select, so setting caret with click-1 is again intiutive. click-2 can keep its behaviour, so 'traditional' users don't get confused. And again everything could be set by some global custom option (and make its way into the 'user' theme -- how do we call the other main theme? 'mainainer' theme or 'developer' theme...), and so the whole discussion becomes sort of a delete/backspace thing. Regards, Oliver.

1 participants
0 comments

Re: Comparison between integer and character is constant nil (?2 and 0) 25 years, 1 month

Didier Verna

Stephen J Turnbull writes: Stephen> A better alternative yet would be to see if we can figure out what Stephen> "spurious" Ebola warnings look like and trap them. There's one case of bogus warnings happening all the time in parse-time.el. There's an array (parse-time-syntax) containing both chars and integers. parse-time-string ends up comparing a char to each element of this array, leading to ebola warnings. Although I find this code rather ugly, the warnings are clearly bogus, and not the code. However, it seems to me that making Ebola clever enough to trap those cases wouldn't be trivial at all, and I'm not even sure it's worth the effort. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / E.N.S.T. INF C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 73 46 75634 Paris cedex 13 Fax. (33) 01 45 81 31 19

1 participants
0 comments

Re: Comparison between integer and character is constant nil (?2 and 0) 25 years, 1 month

Karl Kleinpaste

Hrvoje Niksic <hniksic(a)srce.hr> writes: > Can't we just /debug/ those cases when they show up rather than > flashing the warnings in my face I disable the warning by adding "#if 0" to data.c every time I pick up a fresh XEmacs beta, because every single article I display with Gnus induces the warnings, apparently as a consequence of customizing gnus-treat-date-lapsed to 'head. And yes, it's *really* annoying to get that mini backtrace on a tty, which I use a lot.

1 participants
0 comments

Re: Comparison between integer and character is constant nil (?2 and 0) 25 years, 1 month

Hrvoje Niksic

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > Although most ports of FSF packages are well-done in this respect > these days, I think we are likely to see occasional Ebola from that > source for the forseeable future. Can't we just /debug/ those cases when they show up rather than flashing the warnings in my face (which is especially annoying on TTY's)? I know they're on by default only in debugging builds, but it doesn't justify them if they're only there to catch an occasional bug.

2 participants
1 comments

Mail loop 25 years, 1 month

Tor Arntsen

(Sent to sperber(a)informatik.uni-tuebingen.de already, I made a stupid typo for the xemacs address.. arrgh.) I get the same XEmacs-beta mails over and over again, Uni-Tuebingen.de seems to be bouncing mails back to gwyn.tux.org. Mail headers follow: - Tor #From owner-xemacs-beta(a)xemacs.org Tue Mar 30 15:18:46 1999 #Return-Path: <owner-xemacs-beta(a)xemacs.org> #Received: from gwyn.tux.org (gwyn.tux.org [207.96.122.8]) # by spacetec.no (8.9.1a/8.9.1) with ESMTP id PAA22947 # for <tor(a)spacetec.no>; Tue, 30 Mar 1999 15:18:45 +0200 #Received: (from majordom＠localhost) # by gwyn.tux.org (8.9.1/8.9.1) id HAA15697 # for xemacs-beta-out; Tue, 30 Mar 1999 07:08:39 -0500 #Received: from ra-afs.Informatik.Uni-Tuebingen.De (ra-afs.informatik.uni-tuebing$ # by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id HAA15694 # for <xemacs-beta(a)xemacs.org>; Tue, 30 Mar 1999 07:08:37 -0500 #Received: (from root＠localhost) # by ra-afs.Informatik.Uni-Tuebingen.De (8.9.1/8.9.1) id OAA34800; # Tue, 30 Mar 1999 14:08:36 +0200 #Received: from gwyn.tux.org (gwyn.tux.org [207.96.122.8]) # by ra-afs.Informatik.Uni-Tuebingen.De (8.9.1/8.9.1) with ESMTP id FAA222$ # Mon, 29 Mar 1999 05:05:09 +0200 #Received: (from majordom＠localhost) # by gwyn.tux.org (8.9.1/8.9.1) id WAA25823 # for xemacs-beta-out; Sun, 28 Mar 1999 22:01:53 -0500 #Received: from localhost (tanko.sk.tsukuba.ac.jp [130.158.99.155]) # by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id WAA25820 # for <xemacs-beta(a)xemacs.org>; Sun, 28 Mar 1999 22:01:51 -0500 #Received: by localhost # id m10RSJB-00014GC # (Debian Smail-3.2.0.102 1998-Aug-2 #2); Mon, 29 Mar 1999 12:01:49 +0900 $

1 participants
0 comments

the list is in a loop [ra-afs.Informatik.Uni-Tuebingen.De] 25 years, 1 month

Giacomo Boffi

looking at the headers, it seems that ra-afs.Informatik.Uni-Tuebingen.De mails back to the list whatever it receives from the list

1 participants
0 comments

Re: pop3.el - treating "From " at the beginning of lines 25 years, 1 month

Tor Arntsen

On Mar 30, 9:21, SL Baur wrote: >>> > "Convert MS-DOG style line endings to normal line endings. I humbly suggest somebody change it to 'Convert CRLF line endings to LF line endings.' Before you know it nobody remembers what 'normal' or '<whatever>' style line endings were meant to be. Besides, there are more than just MS systems using CRLF line endings. I worked for years on a minicomputer system with CRLF and never felt sorry for it :-) - Tor

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 March 1999