From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: finger-pointer curser as default for mouse-face text Date: Wed, 27 Oct 2004 14:52:15 +0200 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: References: <200410270215.i9R2FAi07526@raven.dms.auburn.edu> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1098881665 24495 80.91.229.6 (27 Oct 2004 12:54:25 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 27 Oct 2004 12:54:25 +0000 (UTC) Cc: drew.adams@oracle.com, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 27 14:54:14 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CMnJe-00017q-00 for ; Wed, 27 Oct 2004 14:54:14 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CMnRO-0003LX-Pc for ged-emacs-devel@m.gmane.org; Wed, 27 Oct 2004 09:02:14 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CMnPX-00038O-PS for emacs-devel@gnu.org; Wed, 27 Oct 2004 09:00:19 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CMnPU-00037q-VU for emacs-devel@gnu.org; Wed, 27 Oct 2004 09:00:17 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CMnPU-00037b-Da for emacs-devel@gnu.org; Wed, 27 Oct 2004 09:00:16 -0400 Original-Received: from [212.88.64.25] (helo=mail-relay.sonofon.dk) by monty-python.gnu.org with smtp (Exim 4.34) id 1CMnHe-0007Rv-B3 for emacs-devel@gnu.org; Wed, 27 Oct 2004 08:52:10 -0400 Original-Received: (qmail 39615 invoked from network); 27 Oct 2004 12:52:09 -0000 Original-Received: from unknown (HELO kfs-l.imdomain.dk.cua.dk) (213.83.150.2) by 0 with SMTP; 27 Oct 2004 12:52:09 -0000 Original-To: Luc Teirlinck In-Reply-To: <200410270215.i9R2FAi07526@raven.dms.auburn.edu> (Luc Teirlinck's message of "Tue, 26 Oct 2004 21:15:10 -0500 (CDT)") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (gnu/linux) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:29049 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:29049 Luc Teirlinck writes: > Kim Storm wrote: > > But CVS emacs is still far from being released, > > If we keep going on like this, there _never_ will be another release. I agree, but I think this is an important issue. > > and I guess that if we make a clean interface how to inhibit the > mapping for specific links, the package authors will have plenty > of time to adapt their code for CVS emacs. > > It is also a matter of not only documenting the new behavior, but also > changing references to the old behavior everywhere in all manuals, > which may be spread all over the place. This is a general - but user customizable - change in behaviour. As such, we should need to document the current "standard" behaviour, and then add a section at an appropriate place which says something like (need to be elaborated on a little bit): Whenever you can click with mouse-2 to follow a link, you may also be able to follow the link by a double click or a short click with mouse-1. The actual mouse-1 action that you need to follow a link is controlled by the user option mouse-1-click-follows-link. One problem is the tooltips which say "click mouse-2 to ...". To fix that requires that we change all places where the tooltips are created (unless there is some place we can put in a clever rewrite of the message). > Realistically speaking, > implementing the new behavior will introduce bugs that will need to be > fixed. Everything combined, plenty of resources will be diverted from > working on the release, assuming we still want to have one. I don't think there will be many bugs related to this -- some but not many. > I have not been following this discussion, as I have had no time to do > so. I thought the purpose of a feature freeze was exactly that people > would not have to divert time away from working on the release by > worrying about substantive new features and their possible negative effects. That's a problem of a feature freeze that's in place for more than 1 year. If you look at the change logs, new features still creap in over time. Global warming may also be a problem :-) -- Kim F. Storm http://www.cua.dk