From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: cursor doesn't show through transparent images in emacs 22, unlike emacs 21 Date: Sun, 10 Sep 2006 00:55:36 +0200 Message-ID: <85lkosd507.fsf@lola.goethe.zz> References: <851wqpgxtp.fsf@lola.goethe.zz> <85ejuojey3.fsf@lola.goethe.zz> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1157842635 31924 80.91.229.2 (9 Sep 2006 22:57:15 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 9 Sep 2006 22:57:15 +0000 (UTC) Cc: juri@jurta.org, ken.manheimer@gmail.com, emacs-devel@gnu.org, storm@cua.dk Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 10 00:57:14 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GMBlA-0003Ei-0p for ged-emacs-devel@m.gmane.org; Sun, 10 Sep 2006 00:57:12 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GMBl9-0000BB-LU for ged-emacs-devel@m.gmane.org; Sat, 09 Sep 2006 18:57:11 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GMBki-0008WB-HY for emacs-devel@gnu.org; Sat, 09 Sep 2006 18:56:44 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GMBkh-0008Vm-Pe for emacs-devel@gnu.org; Sat, 09 Sep 2006 18:56:44 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GMBkh-0008Vf-Ln for emacs-devel@gnu.org; Sat, 09 Sep 2006 18:56:43 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GMBlc-0006KD-AO for emacs-devel@gnu.org; Sat, 09 Sep 2006 18:57:40 -0400 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1GMBkZ-0007oP-Cg; Sat, 09 Sep 2006 18:56:35 -0400 Original-Received: by lola.goethe.zz (Postfix, from userid 1002) id 5F5851C40B5C; Sun, 10 Sep 2006 00:55:37 +0200 (CEST) Original-To: rms@gnu.org In-Reply-To: (Richard Stallman's message of "Sat\, 09 Sep 2006 16\:45\:38 -0400") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.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: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:59607 Archived-At: Richard Stallman writes: > The present setting results in almost all cases in a recognizable > cursor position (images with border 0 are possible only come Emacs > 22.1). > > Are you saying that the problem of failing to show the cursor > only applies when the border is 0, and that that is a new feature? Yes. > In that case, let's limit my recommendations to the case when the > border is 0. We can give :mask a different default, or make the > lack of :mask an error, only when border is 0. It is my opinion that we should not meddle with the defaults of mask, since mask may serve independent purposes: it is well possible that the _image_ has a transparency layer and specifies a mask. And when this mask just happens to be opaque (not an uncommon occurence), we are back to square one: masks can perfectly well be all opaque. The proper solution would be to draw in the image itself. If we instead use a temporary fix instead, it should not be interlocked with :mask since the final, proper solution should be independent of mask, too. > I have experienced that: trust me, this default _is_ worse, > much much worse than the existing one. > > That makes no sense at all. The current default (in the case with > border 0) is not to show the cursor at all. (If I'm mistaken, > please explain.) If we change it to heuristic-mask, then usually it > would show the cursor. That is better than not showing the cursor. We had cases in the combined Emacs/preview-latex history where the cursor was not displayed (we have not used :border yet). The user will usually remember how he arrived at the character and not lose track of the cursor. If he gets away from the screen, a quick cursor movement forth and back will reestablish the position. The alternative is that the graphic on which the cursor is positioned will be flashing (since the graphics tend to be characters on background, this means the lion share of the graphics). Now we have put the customization option for a flashing cursor into the top of the options menu because people get close to epileptic reactions by a 10x20 square (at most) flashing at them. If a graphic taking half the screen or more is flashing (easily an area larger by a factor of 1000), even the most insensitive person will get close to getting a heart attack. It is _very_ _very_ disconcerting, much more so than the cursor just disappearing. The cursor disappearing feels like a quirk: you can play around it, make do by moving the cursor back and forth to figure out where you are. The whole screen flashing at you feels like an attack on your sanity. It is impossible to concentrate or do anything sensible except move the cursor elsewhere. > If you want me to believe this is worse, you'll have to demonstrate > it with clear explanation, not emotional upset. > > preview-latex had to go to quite disadvantageous techniques to avoid > large-scale flashing in Emacs 21. You'd reintroduce it. > > Would you please show the justification for that claim? In preview-latex under Emacs 21, we generate images with a colored border and let just this border become transparent. This means that the images are useless for anything else. There is a mode to cut and paste a text passage into mail messages, and those color-border images under Emacs-21 need to be regenerated without a border then. The cursor display in Emacs 22 (a box around the cursor) was decent enough to just use that: no artificial play with transparent borders was needed. The corresponding definition looks like the following: ;;; Note that the following default introduces a border only when ;;; Emacs blinks politely when point is on an image (the tested ;;; unrelated function was introduced at about the time image blinking ;;; became tolerable). (defcustom preview-transparent-border (unless (fboundp 'posn-object-x-y) 1.5) "Width of transparent border for previews in pt. Setting this to a numeric value will add a border of `preview-transparent-color' around images, and will turn the heuristic-mask setting of images to default to 't since then the borders are correctly detected even in case of palette operations. If the transparent color is something not present otherwise in the image, the cursor display will affect just this border. A width of 0 is interpreted by PostScript as meaning a single pixel, other widths are interpreted as PostScript points (1/72 of 1in)" :group 'preview-appearance :type '(choice (const :value nil :tag "No border") (number :value 1.5 :tag "Border width in pt"))) > I think it would be a mistake to abuse :mask just in order to get the > cursor to display in a useful way. > > There is no "abuse" in changing the default. But :mask, :border and :cursor are unrelated things. Making their defaults depend on one another does not see like a good idea. > In particular since it would mean > that customizing the cursor type would have no effect on images, > > Why do you think it would mean that? There are cursor types of block and bar. How would you display block and bar cursors by fiddling with the default of :mask? > > 3. If #2 is too complex to do now, maybe we should make it an > > error to fail to specify :mask on an image on a character in > > the buffer. That is simple. > > It will also break wagonloads of existing code. > > I doubt it. You've said border 0 is a new feature, so there can't > be so much existing code that uses it. Admitted. I just don't think that making this an error is the right migration path: ultimately, the cursor should just be drawn in the image area. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum