[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cursor doesn't show through transparent images in emacs 22, unlike e

From: David Kastrup
Subject: Re: cursor doesn't show through transparent images in emacs 22, unlike emacs 21
Date: Sun, 10 Sep 2006 00:55:36 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

Richard Stallman <address@hidden> 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?


> 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,

>       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) 
      "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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]