no good way to highlight rectangle while region is highlighted

no good way to highlight rectangle while region is highlighted

[Joe Wells]

Summary of this message: This is a feature request for (1) the
possibility that some overlays can have priority over the use of the
region face, and/or (2) a variant of the “box” face feature where the
vertical lines of the box take no extra space.

It started when I saw the “sense-region” package.  It contains some
code to make Emacs operations that normally operate on the region
switch between operating on the region and the rectangle.  When
operating on the region (in transient mark mode), the region is
highlighted.  When operating on the rectangle, the rectangle is
highlighted.

I didn't really want all of the features of sense-region, but I liked
the rectangle highlighting.  So I thought, wouldn't it be nice to be
able to have _both_ the region and the rectangle highlighted
simultaneously?  I've wanted something like this for a while for
multiple reasons.  One reason is that it makes it easier for me to
explain the rectangle commands to other users.  Another is that
something like this would be a big help with SES (Simple Emacs
Spreadsheet).

So I wrote some code to just use the rectangle highlighting code of
sense-region.el.  I ran into these problems in trying to highlight the
region and rectangle simultaneously:

1. The use of the “region” face for the region takes precedence over
   all overlays and text properties.  So it is not possible to change
   the background color of the rectangle because the region face sets
   the background for the portion of the rectangle inside the region.
   Using slightly different colors for the portion of the rectangle
   within the region and the portion outside the region would have
   been the nicest way of highlighting the rectangle.  However, there
   will be no way of doing this unless some overlays can be given
   priority over the region.

2. Using the “box” face feature (i.e., (set-face-attribute FACE nil
   :box '(:line-width -1 :color COLOR))) for the rectangle is
   problematic because there is no way to make the vertical lines not
   take space.  Using a negative dimension makes the horizontal lines
   (on top and bottom) not take space, but the vertical lines (on the
   left and right) do take space.  So every time the rectangle changes
   lots of text on the screen gets shifted around.  It would be nice
   if there was a way to make the vertical lines appear _within_ the
   space allocated for the text with the face.

3. Changing the foreground color of the rectangle just is not visually
   satisfactory, and overrides any colors provided by font-lock.

4. Using inverse video (i.e., (set-face-inverse-video-p FACE t)) for
   the rectangle is not visually satisfactory, and is anyway confusing
   at the boundaries of the rectangle due to the blinking box cursor
   which looks just like inverse video when it is on.

The most satisfactory alternative I have found is to use the stipple
feature.  I'm currently using this code:

  (set-face-stipple FACE '(12 12 "\000\010\000\004\000\002\000\001\200\000\100\000\040\000\020\000\010\000\004\000\002\000\001\000"))

This draws diagonal lines in the foreground color over the rectangle
from upper right to lower left that are 1 pixel wide and separated by
12 pixels.

But even using stipple is not really satisfactory as it is visually
difficult to locate the exact boundaries of the rectangle.

Any suggestions?  I'd like to use either background colors, or the box
face feature, but either of these would require changes to Emacs to
work acceptably.

By the way, *all* of the methods I have tried can't show a rectangle
of width 0.  But rectangles of width 0 are extremely useful with some
rectangle commands, and it would help to be able to show such
rectangles.

-- 
Joe

======================================================================

P.S.  Here is the code I am using with version 1.8 of sense-region.el,
so you can see how highlighting the rectangle works for yourself with
“M-x sense-region-on RET”:

;; I'm building on sense-region.el version 1.8 of 2002-05-23, because
;; I don't understand what version 1.9 is doing and all the
;; documentation is in Japanese and Google's translation doesn't make
;; much sense.  You can get version 1.8 in the recent Ubuntu versions
;; of the “sense-region” package:
;;
;;   http://archive.ubuntu.com/ubuntu/pool/universe/s/sense-region/sense-region_0.0.20020523.orig.tar.gz
;;
;; The file sense-region_2002-05-23.el on the author's web site is
;; actually a significantly later version from 2002-08-25, so don't get
;; that file.

(defun require-sense-region-if-found ()
  (or (require 'sense-region nil t)
      (require 'sense-region
               "/mnt/gentoo-portage/jbw/sense-region-0.0.20020523/sense-region.el"
               t)))

(require-sense-region-if-found)

(progn
  (make-face 'sense-region-face t)
  ;;(set-face-attribute 'sense-region-face nil :box '(:line-width -1 :color "red"))
  (set-face-attribute 'sense-region-face nil :box nil)
  ;;;; XOXOXOXO
  ;;;; OXOXOXOX
  ;;;; #o125 == #x55, #o252 == #xAA
  ;;(set-face-stipple 'sense-region-face '(8 2 "\125\252"))
  ;;;; XXO == 1 + 2 == 3
  ;;;; XOX == 1 + 4 == 5
  ;;;; OXX == 2 + 4 == 6
  ;;(set-face-stipple 'sense-region-face '(3 3 "\003\005\006"))
  ;;;; XOO == 1
  ;;;; OOX == 4
  ;;;; OXO == 2
  ;;(set-face-stipple 'sense-region-face '(3 3 "\001\004\002"))
  ;;;; XOOO == 1
  ;;;; OOOX == 8
  ;;;; OOXO == 4
  ;;;; OXOO == 2
  ;;(set-face-stipple 'sense-region-face '(4 4 "\001\010\004\002"))
  ;;;; XOOOO ==  1 == 001
  ;;;; OOOOX == 16 == 020
  ;;;; OOOXO ==  8 == 010
  ;;;; OOXOO ==  4 == 004
  ;;;; OXOOO ==  2 == 002
  ;;(set-face-stipple 'sense-region-face '(5 5 "\001\020\010\004\002"))
  ;;(set-face-stipple 'sense-region-face '(7 7 "\100\040\020\010\004\002\001"))
  (set-face-stipple 'sense-region-face '(8 8 "\200\100\040\020\010\004\002\001"))
  (set-face-stipple 'sense-region-face '(9 9 "\000\001\200\000\100\000\040\000\020\000\010\000\004\000\002\000\001\000"))
  (set-face-stipple 'sense-region-face '(11 11 "\000\004\000\002\000\001\200\000\100\000\040\000\020\000\010\000\004\000\002\000\001\000"))
  (set-face-stipple 'sense-region-face '(12 12 "\000\010\000\004\000\002\000\001\200\000\100\000\040\000\020\000\010\000\004\000\002\000\001\000"))
  ;;(set-face-stipple 'sense-region-face '(14 14 "\000\040\000\020\000\010\000\004\000\002\000\001\200\000\100\000\040\000\020\000\010\000\004\000\002\000\001\000"))
  (set-face-inverse-video-p 'sense-region-face nil)
  ;;(set-face-foreground 'sense-region-face "red")
  (set-face-background 'sense-region-face nil)
  (set-face-foreground 'sense-region-face nil)
  (setq sense-region-status 'rectangle))

(defadvice sense-region-on (around jbw-override-completely activate)
  (interactive)
  (if (featurep 'sense-region)
      (add-hook 'post-command-hook 'sense-region-redisplay)))

(defadvice sense-region-off (around jbw-override-completely activate)
  (interactive)
  (if (featurep 'sense-region)
      (sense-region-to-region))
  (remove-hook 'post-command-hook 'sense-region-redisplay))

(defadvice sense-region-to-region (around jbw-override-completely activate)
  (interactive)
  (mell-sign-rectangle-highlight-off sense-region-overlay-list)
  (setq sense-region-overlay-list nil))

======================================================================

P.P.S.  My Emacs version information:

In GNU Emacs 22.1.1 (i686-pc-linux-gnu, GTK+ Version 2.8.20)
 of 2007-06-27 on artemis
Windowing system distributor `The X.Org Foundation', version 11.0.70000000
configured using `configure  '--prefix=/home/jbw/local2' '--enable-debug' '--disable-nls' '--with-x-toolkit=gtk' 'CFLAGS=-O0 -g3 -ggdb''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: en_US.UTF-8
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: jbw
  value of $LANG: nil
  locale-coding-system: utf-8
  default-enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  shell-dirtrack-mode: t
  outline-minor-mode: t
  desktop-save-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  temp-buffer-resize-mode: t
  size-indication-mode: t
  line-number-mode: t
  transient-mark-mode: t

Re: no good way to highlight rectangle while region is highlighted

[Richard Stallman]

    Summary of this message: This is a feature request for (1) the
    possibility that some overlays can have priority over the use of the
    region face, and/or (2) a variant of the ?box? face feature where the
    vertical lines of the box take no extra space.

(2) sounds terribly low-level.  (1) is cleaner.

I think (1) could be implemented with a change in face_at_buffer_position.
For instance, we could define a certain priority for the region,
so that overlays whose priority exceeds that cover the region.
It doesn't look terribly hard, but you need to think carefully
to prove that you store the value into *ENDPTR in all cases.

      It contains some
    code to make Emacs operations that normally operate on the region
    switch between operating on the region and the rectangle.  When
    operating on the region (in transient mark mode), the region is
    highlighted.  When operating on the rectangle, the rectangle is
    highlighted.

If you only want to show the region OR a rectangle,
why do you need any new display features?  You'd need a new
feature only to show both at once.

      I ran into these problems in trying to highlight the
    region and rectangle simultaneously:

Why do you want to highlight them both simultaneously?

Re: no good way to highlight rectangle while region is highlighted

[Joe Wells]

Richard Stallman <rms@gnu.org> writes:

>     Summary of this message: This is a feature request for (1) the
>     possibility that some overlays can have priority over the use of the
>     region face, and/or (2) a variant of the ?box? face feature where the
>     vertical lines of the box take no extra space.
>
> (2) sounds terribly low-level.  (1) is cleaner.

I agree with you that it is low level.  At the same time, I think it
would make a far better user interface for highlighting the rectangle
I think the ease of the user seeing the rectangle would be much
better.  This is especially important if the rectangle is to be
highlighted at the same time as the region (see below for why this is
desirable).

I think it is worth pointing out (again) that the “box” feature of
faces _already_ supports having the _horizontal_ lines take no extra
space.  It is a bit strange that it supports this but does not support
having the _vertical_ lines take no extra space.

> I think (1) could be implemented with a change in face_at_buffer_position.
> For instance, we could define a certain priority for the region,
> so that overlays whose priority exceeds that cover the region.
> It doesn't look terribly hard, but you need to think carefully
> to prove that you store the value into *ENDPTR in all cases.

It would be lovely to be able to do (1), because that would allow
using background color to distinguish the rectangle while the region
is being shown.  (Note that parts of the rectangle can be outside the
region, so showing it with colors at the same time as the region is a
bit complicated.)

>     It contains some
>     code to make Emacs operations that normally operate on the region
>     switch between operating on the region and the rectangle.  When
>     operating on the region (in transient mark mode), the region is
>     highlighted.  When operating on the rectangle, the rectangle is
>     highlighted.
>
> If you only want to show the region OR a rectangle,
> why do you need any new display features?  You'd need a new
> feature only to show both at once.

You are correct.  I am not using sense-region.el as designed (see
below for why).  I am only using the code from sense-region that
highlights the rectangle.  Using some of the code in sense-region.el,
I am now showing both the region and rectangle at once.  But I am
currently using the stipple feature of faces for the rectangle, and as
a user interface it is visually not so good.

>     I ran into these problems in trying to highlight the
>     region and rectangle simultaneously:
>
> Why do you want to highlight them both simultaneously?

I think it is useful (and is the way Emacs has worked already for
decades) to have both rectangle and region commands available at all
times.  In this case, because Emacs doesn't know whether you are going
to use a region or rectangle command next, it is helpful to be able to
show them both.

I hope these comments are helpful.

-- 
Joe

Re: no good way to highlight rectangle while region is highlighted

[Johan Bockgård]

Joe Wells <jbw@macs.hw.ac.uk> writes:

>   ;;;; XOXOXOXO
>   ;;;; OXOXOXOX
>   ;;;; #o125 == #x55, #o252 == #xAA
>   ;;(set-face-stipple 'sense-region-face '(8 2 "\125\252"))

A more convenient way to specify the bitmap is

(string #b01010101
        #b10101010)

etc.

-- 
Johan Bockgård

Re: no good way to highlight rectangle while region is highlighted

[Richard Stallman]

    I agree with you that it is low level.  At the same time, I think it
    would make a far better user interface for highlighting the rectangle
    I think the ease of the user seeing the rectangle would be much
    better.

I do not see why.  Could you explain?

    I think it is worth pointing out (again) that the ?box? feature of
    faces _already_ supports having the _horizontal_ lines take no extra
    space.  It is a bit strange that it supports this but does not support
    having the _vertical_ lines take no extra space.

It does sound like a natural extension, but it might be hard to
implement since it involves changing the display code.  (Do you want
to implement this and debug it?)  And I still don't see how it relates.

    Using some of the code in sense-region.el,
    I am now showing both the region and rectangle at once.

Why do you want to?

    I think it is useful (and is the way Emacs has worked already for
    decades) to have both rectangle and region commands available at all
    times.  In this case, because Emacs doesn't know whether you are going
    to use a region or rectangle command next, it is helpful to be able to
    show them both.

I would not want that as a normal feature.
I think it would look confusing.  I would rather have a command
to switch between region and rectangle.

Re: no good way to highlight rectangle while region is highlighted

[Joe Wells]

Richard Stallman <rms@gnu.org> writes:

>     I agree with you that it is low level.  At the same time, I think it
>     would make a far better user interface for highlighting the rectangle
>     I think the ease of the user seeing the rectangle would be much
>     better.
>
> I do not see why.  Could you explain?

I am assuming the goal of showing _both_ the rectangle and region
simultaneously.  (If you just want to show one of them at a time, then
background colors are more than enough.)

I think highlighting both the rectangle and the region will be easiest
by drawing colored lines around the rectangle and keeping the current
way of highlighting the region.  I have already tried this (using the
“box” feature with colored lines), and I find it the easiest to
visually understand of the ways that I have gotten to work.  I'm not
using it now because every time the rectangle changes, areas of text
get shifted on the screen right or left by 1 pixel and this is
visually jarring.  (This is using the “box” face feature with a
dimension of -1, which makes a line 1 pixel wide.  The text shifts
because the line takes up horizontal space (although no vertical space
is taken).)

In contrast, I think showing both region and rectangle with colors in
a way that is easy for the user to see will be more difficult.  Part
of the difficulty is due to the fact that part of the rectangle can be
outside of the region and part can be within.

(By the way, I would also like to see a solution that shows the
rectangle when it is of zero width.  That would be quite useful for
some rectangle commands.  None of the methods I have tried so far can
work for this case.)

>     I think it is worth pointing out (again) that the ?box? feature of
>     faces _already_ supports having the _horizontal_ lines take no extra
>     space.  It is a bit strange that it supports this but does not support
>     having the _vertical_ lines take no extra space.
>
> It does sound like a natural extension, but it might be hard to
> implement since it involves changing the display code.  (Do you want
> to implement this and debug it?)  And I still don't see how it relates.

It relates because it would solve the only problem I have encountered
with using the “box” feature of faces to highlight the rectangle.
That problem is that chunks of text get shifted left or right by a
pixel every time the rectangle changes.  Other than this problem,
using the “box” feature to highlight the rectangle works great and is
easy to understand.

(No, I'm not volunteering.  Sorry, maybe a year from now, not now.)

>     Using some of the code in sense-region.el,
>     I am now showing both the region and rectangle at once.
>
> Why do you want to?

Because in Emacs there are many commands that affect the region, and
there are also many commands that effect the rectangle, and at any
given moment I might want to use any of them (either region or
rectangle), so it would be useful to have visual indicators of what
portions of the text both kinds of commands would affect.

>     I think it is useful (and is the way Emacs has worked already for
>     decades) to have both rectangle and region commands available at all
>     times.  In this case, because Emacs doesn't know whether you are going
>     to use a region or rectangle command next, it is helpful to be able to
>     show them both.
>
> I would not want that as a normal feature.

As I explained above, it would be helpful, at least to me (and I
think to others as well).

> I think it would look confusing.

That depends on how smoothly it is implemented.  I think using the
“box” face feature for the rectangle and colors for the region would
make it easy for people to see which was which.

> I would rather have a command to switch between region and rectangle.

That could also be useful.

I hope these comments are helpful.

-- 
Joe

Re: no good way to highlight rectangle while region is highlighted

[Ehud Karni]

On Sat, 21 Jul 2007 22:59:30, Joe Wells wrote:
>
> Summary of this message: This is a feature request for (1) the
> possibility that some overlays can have priority over the use of the
> region face, and/or (2) a variant of the -box- face feature where the
> vertical lines of the box take no extra space.
       [snip]
> Any suggestions?  I'd like to use either background colors, or the box
> face feature, but either of these would require changes to Emacs to
> work acceptably.


Below is my code to mark rectangles (blocks):

> Any suggestions?  I'd like to use either background colors, or the box
> face feature, but either of these would require changes to Emacs to
> work acceptably.

I think a strong background color (I use red) is much better because
it can not be missed. A frame only (box) can be overlooked, especially
when the rectangle is greater than the screen size.

Ehud.


 -------------------------- mark block code --------------------------

(defvar mark-1st nil "1st mark (ek) position,
a cons cell: (marker column-number) for all marks,
nil if not set")

(defvar mark-2nd nil "2nd mark (ek) position,
a cons cell: (marker column-number) for all marks,
nil if not set")

(defvar mark-overlay-list nil "list of mark overlays (unmark deletes them).")

(defvar mark-block-max-lines 500 "Maximum lines in block mark to face (color).
If the number of lines in the block mark is greater than this value don't make it visible.")

(defun visible-unmark () "Make marked area normal"
       (mapc 'delete-overlay mark-overlay-list)
       (setq mark-overlay-list nil))

(defun mark-set-face (FACE) "Set face of marked area to FACE (to mark only)"
       (visible-unmark)                    ;; clear overlay if exist
       (mark-block-check-swap)             ;; ensure upper-left, bottom-right
       (let* ((buf (set-buffer (marker-buffer (car mark-1st))))
                   (pos (point-marker))         ;; current position in buf
                   (m1 (marker-position (car mark-1st)))
                   (m2 (marker-position (car mark-2nd)))
             )
           (if (> (count-lines m1 m2) mark-block-max-lines)
                   (message "Block mark to large - not shown")
               (let ((c1 (cdr mark-1st))
                     (c2 (1+ (cdr mark-2nd))))
                   (goto-char m1)
                   (setq m2 (min m2 (1- (point-max))))
                   (while (not (< m2 (point)))
                   (setq m1 (+ (point) c1))
                   (end-of-line)
                   (setq m1 (min m1 (point)))
                   (goto-col c2 t)
                   (mark-set-face-overlay m1 (point) buf FACE)
                   (forward-line)))))
       (goto-char pos))                ;; restore position

(defun mark-set-face-overlay (BEG END BUF FACE)
  "make-overlay BEG END in BUF, set its `face' to FACE and its priority to 99.
really FACE is always `MARK'. Add to mark-overlay-list (for unmarking)."
       (let ((ov (make-overlay BEG END BUF nil t)))
           (overlay-put ov 'face FACE)
           (overlay-put ov 'priority 99)
           (setq mark-overlay-list (append (list ov) mark-overlay-list))))

(defun mark-block-check-swap ()
  "Block mark check (& swap) so mark-1st is set to upper left corner,
        mark-2nd to right bottom corner."
       (let ((tmp 0)
             (p1 (car mark-1st))
             (p2 (car mark-2nd))
             (c1 (cdr mark-1st))
             (c2 (cdr mark-2nd)))
           (if (> (marker-position p1) (marker-position p2))
               (progn
                   (setq tmp p1)
                   (setq p1 p2)
                   (setq p2 tmp)))
           (if (> c1 c2)
               (progn
                   (setq tmp c1)
                   (setq c1 c2)
                   (setq c2 tmp)))
           (setq mark-1st (cons p1 c1))
           (setq mark-2nd (cons p2 c2))))

(defun goto-col (arg &optional nospc)
  "goto ARG (column number) on current line, add spaces if needed
optional NOSPC means don't add spaces at end of line"
  (interactive "NGoto Column: ")
       (end-of-line)
       (let ((col-goto (- arg (column-no))))
           (if nospc ()
               (while (> col-goto 0)
                   (insert-char ?\040 1)
                   (setq col-goto (- col-goto 1))))
           (if (< col-goto 0)
               (goto-char (+ (point) col-goto)))))

(defun column-no (&optional arg)
 "returns column number of point or arg (char number if given)"
 (interactive "p")
       (save-excursion
           (if arg
               (goto-char arg))
           (let ((inhibit-field-text-motion))
               (1+  (- (point) (line-beginning-position))))))


--
 Ehud Karni           Tel: +972-3-7966-561  /"\
 Mivtach - Simon      Fax: +972-3-7966-667  \ /  ASCII Ribbon Campaign
 Insurance agencies   (USA) voice mail and   X   Against   HTML   Mail
 http://www.mvs.co.il  FAX:  1-815-5509341  / \
 GnuPG: 98EA398D <http://www.keyserver.net/>    Better Safe Than Sorry

Re: no good way to highlight rectangle while region is highlighted

[Joe Wells]

"Ehud Karni" <ehud@unix.mvs.co.il> writes:

> On Sat, 21 Jul 2007 22:59:30, Joe Wells wrote:
>>
>> Summary of this message: This is a feature request for (1) the
>> possibility that some overlays can have priority over the use of the
>> region face, and/or (2) a variant of the -box- face feature where the
>> vertical lines of the box take no extra space.
>        [snip]
>> Any suggestions?  I'd like to use either background colors, or the box
>> face feature, but either of these would require changes to Emacs to
>> work acceptably.
>
> Below is my code to mark rectangles (blocks):

Hi, Ehud,

Thanks for your comments.

How does your code work in combination with the Emacs C code that
highlights the region using the “region” face?  I think your code will
have the same problems that I have already described.

I notice that your code modifies the buffer.  This is very undesirable
for the purpose I have in mind (which is constantly showing the
current rectangle).

>> Any suggestions?  I'd like to use either background colors, or the box
>> face feature, but either of these would require changes to Emacs to
>> work acceptably.
>
> I think a strong background color (I use red) is much better because
> it can not be missed. A frame only (box) can be overlooked, especially
> when the rectangle is greater than the screen size.

A frame (“box”) can be seen fairly easily if its borders are in a
strong color.  And I think a frame around the current rectangle is
easier to use in combination with a background color to simultaneously
show the current region.  (My goal is to have a good way to highlight
simultaneously _both_ the current region and current rectangle.)

-- 
Joe

Re: no good way to highlight rectangle while region is highlighted

[Ehud Karni]

On Fri, 27 Jul 2007 08:52:16, Joe Wells wrote:
>
> "Ehud Karni" <ehud@unix.mvs.co.il> writes:
>
> How does your code work in combination with the Emacs C code that
> highlights the region using the "region" face?  I think your code will
> have the same problems that I have already described.

The overlay is set to priority 99 and I sure see it OVER the region.

> I notice that your code modifies the buffer.  This is very undesirable
> for the purpose I have in mind (which is constantly showing the
> current rectangle).

The code does NOT modify the buffer (you can check it on read only
buffer), please try it before you state such observation.

> > I think a strong background color (I use red) is much better because
> > it can not be missed. A frame only (box) can be overlooked, especially
> > when the rectangle is greater than the screen size.
>
> A frame ("box") can be seen fairly easily if its borders are in a
> strong color.

Not if the area border is not on the screen (which can happen when the
rectangle is greater than a screen, e.g. 150 lines by 120 chars).

Ehud.


--
 Ehud Karni           Tel: +972-3-7966-561  /"\
 Mivtach - Simon      Fax: +972-3-7966-667  \ /  ASCII Ribbon Campaign
 Insurance agencies   (USA) voice mail and   X   Against   HTML   Mail
 http://www.mvs.co.il  FAX:  1-815-5509341  / \
 GnuPG: 98EA398D <http://www.keyserver.net/>    Better Safe Than Sorry

Re: no good way to highlight rectangle while region is highlighted

[Joe Wells]

"Ehud Karni" <ehud@unix.mvs.co.il> writes:

> On Fri, 27 Jul 2007 08:52:16, Joe Wells wrote:
>>
>> "Ehud Karni" <ehud@unix.mvs.co.il> writes:
>>
>> How does your code work in combination with the Emacs C code that
>> highlights the region using the "region" face?  I think your code will
>> have the same problems that I have already described.
>
> The overlay is set to priority 99 and I sure see it OVER the region.

Hi, Ehud,

How is this possible?  From (info "(elisp)Displaying Faces"):

     “If these various sources together specify more than one face for a
  particular character, Emacs merges the attributes of the various faces
  specified.  For each attribute, Emacs tries first the face of any
  special glyph; then the face for region highlighting, if appropriate;
  then the faces specified by overlays, followed by those specified by
  text properties, then the `mode-line' or `mode-line-inactive' or
  `header-line' face (if in a mode line or a header line), and last the
  `default' face.”

So the only faces which can override the “region” face are the faces
for glyphs set with display tables.  Overlays can't do that.  Because
the default “region” face sets a background color, there is no way an
overlay can override the background color of the region.

>> I notice that your code modifies the buffer.  This is very undesirable
>> for the purpose I have in mind (which is constantly showing the
>> current rectangle).
>
> The code does NOT modify the buffer (you can check it on read only
> buffer), please try it before you state such observation.

Your goto-col function contains code to modify the buffer.  I assumed
that this code was used (because otherwise why would it be there?).
(By the way (just curious), but why aren't you using Emacs's standard
move-to-column function instead?)

Anyway, I couldn't try your code because it is incomplete.  As far as
I can tell, the entry point in what you supplied is mark-set-face and
this merely raises an error because there is no code to assign values
to the variables mark-1st and mark-2nd that it depends on.

>> > I think a strong background color (I use red) is much better because
>> > it can not be missed. A frame only (box) can be overlooked, especially
>> > when the rectangle is greater than the screen size.
>>
>> A frame ("box") can be seen fairly easily if its borders are in a
>> strong color.
>
> Not if the area border is not on the screen (which can happen when the
> rectangle is greater than a screen, e.g. 150 lines by 120 chars).

When one uses the “box” face feature, every _individual_ line shows a
top and bottom border.  So there is no possibility of not seeing the
frame.

-- 
Joe

Re: no good way to highlight rectangle while region is highlighted

[Dan Nicolaescu]

"Ehud Karni" <ehud@unix.mvs.co.il> writes:

  > On Sat, 21 Jul 2007 22:59:30, Joe Wells wrote:
  > >
  > > Summary of this message: This is a feature request for (1) the
  > > possibility that some overlays can have priority over the use of the
  > > region face, and/or (2) a variant of the -box- face feature where the
  > > vertical lines of the box take no extra space.
  >        [snip]
  > > Any suggestions?  I'd like to use either background colors, or the box
  > > face feature, but either of these would require changes to Emacs to
  > > work acceptably.
  > 
  > 
  > Below is my code to mark rectangles (blocks):
  > 
  > > Any suggestions?  I'd like to use either background colors, or the box
  > > face feature, but either of these would require changes to Emacs to
  > > work acceptably.
  > 
  > I think a strong background color (I use red) is much better because
  > it can not be missed. A frame only (box) can be overlooked, especially
  > when the rectangle is greater than the screen size.

BTW, cua-selection-mode has a way of marking rectangles, turn on
cua-selection-mode and the do C-RET and use the arrow keys to extend
the rectangle...

Re: no good way to highlight rectangle while region is highlighted

[Ehud Karni]

On Fri, 27 Jul 2007 14:27:49, Joe Wells wrote:
>
> "Ehud Karni" <ehud@unix.mvs.co.il> writes:
>
> > The overlay is set to priority 99 and I sure see it OVER the region.
>
> How is this possible?  From (info "(elisp)Displaying Faces"):
>
>      "If these various sources together specify more than one face for a
>   particular character, Emacs merges the attributes of the various faces
                                ^^^^^^
>   specified.  For each attribute, Emacs tries first the face of any
>   special glyph; then the face for region highlighting, if appropriate;
>   then the faces specified by overlays, followed by those specified by
>   text properties, then the `mode-line' or `mode-line-inactive' or
>   `header-line' face (if in a mode line or a header line), and last the
>   `default' face."
>
> So the only faces which can override the "region" face are the faces
> for glyphs set with display tables.  Overlays can't do that.  Because
> the default "region" face sets a background color, there is no way an
> overlay can override the background color of the region.

I think the keyword is "merges" that you somehow ignored.

> >> I notice that your code modifies the buffer.  This is very undesirable
> >> for the purpose I have in mind (which is constantly showing the
> >> current rectangle).
> >
> > The code does NOT modify the buffer (you can check it on read only
> > buffer), please try it before you state such observation.
>
> Your goto-col function contains code to modify the buffer.  I assumed
> that this code was used (because otherwise why would it be there?).
> (By the way (just curious), but why aren't you using Emacs's standard
> move-to-column function instead?)

My `goto-col' is used for other purposes too. Here it is used ONLY with
the NOSPC arg set to t.

> Anyway, I couldn't try your code because it is incomplete.  As far as
> I can tell, the entry point in what you supplied is mark-set-face and
> this merely raises an error because there is no code to assign values
> to the variables mark-1st and mark-2nd that it depends on.

The code is a small part of a much larger (1320 lines) package.

Here is sample code to set mark-1st to current cursor position.
(setq mark-1st (cons
                   (save-excursion (beginning-of-line) (point-marker))
                   (col (1- (column-no)))))

Ehud.


--
 Ehud Karni           Tel: +972-3-7966-561  /"\
 Mivtach - Simon      Fax: +972-3-7966-667  \ /  ASCII Ribbon Campaign
 Insurance agencies   (USA) voice mail and   X   Against   HTML   Mail
 http://www.mvs.co.il  FAX:  1-815-5509341  / \
 GnuPG: 98EA398D <http://www.keyserver.net/>    Better Safe Than Sorry

Re: no good way to highlight rectangle while region is highlighted

[Joe Wells]

"Ehud Karni" <ehud@unix.mvs.co.il> writes:

> On Fri, 27 Jul 2007 14:27:49, Joe Wells wrote:
>>
>> "Ehud Karni" <ehud@unix.mvs.co.il> writes:
>>
>> > The overlay is set to priority 99 and I sure see it OVER the region.
>>
>> How is this possible?  From (info "(elisp)Displaying Faces"):
>>
>>      "If these various sources together specify more than one face for a
>>   particular character, Emacs merges the attributes of the various faces
>                                ^^^^^^
>>   specified.  For each attribute, Emacs tries first the face of any
>>   special glyph; then the face for region highlighting, if appropriate;
>>   then the faces specified by overlays, followed by those specified by
>>   text properties, then the `mode-line' or `mode-line-inactive' or
>>   `header-line' face (if in a mode line or a header line), and last the
>>   `default' face."
>>
>> So the only faces which can override the "region" face are the faces
>> for glyphs set with display tables.  Overlays can't do that.  Because
>> the default "region" face sets a background color, there is no way an
>> overlay can override the background color of the region.
>
> I think the keyword is "merges" that you somehow ignored.

Hi, Ehud,

My reading of the documentation (supplemented by my perusal of the
Emacs C source code) for “merging” of face F1 and face F2 is that it
is not a symmetric operation and one of the faces takes priority.  In
the case of distinct face attributes, both are used; this means if
face F1 has value V1 for attribute A1 and face F2 has value V2 for
attribute A2, then you get a new face with V1 for A1 and V2 for A2.
In the case of assignments for the same face attribute, only one is
used; assuming face F1 has priority, if face F1 has value V1 for
attribute A0 and face F2 has value V2 for the same attribute A0, then
value V1 is used.

Note that there is no notion of merging of colors.  One of the two
colors is always used, unchanged.

My reading of the above-quoted documentation is that the “region” face
always takes priority over all overlays (regardless of the overlay's
“priority” property), text properties, and the default face.  Given
that the default value of the “region” face sets the :background
attribute, this means that any :background attribute set by any
overlay or text property or the default face is ignored in the area
covered by the region when it is being highlighted.

I have done testing that agrees with this.  Although I had no reason
to believe they would make any difference, I just now tried overlay
priorities anyway and verified that overlay priorities make no
difference whatsoever in this matter.  No matter how high the overlay
priority, the background color of the overlay's face can not override
the background color of the “region” face (and no attempt at color
combination occurs).  I even tried most-positive-fixnum as the overlay
priority (and you can't get any higher than that).

So basically, unless you are working with some Emacs C code which
differs from Emacs 22.1 in how this is handled, what you are saying
about overlay faces overriding the region face is simply not true.

My latest testing code is appended below, so you can check for
yourself.

>> Anyway, I couldn't try your code because it is incomplete.  As far as
>> I can tell, the entry point in what you supplied is mark-set-face and
>> this merely raises an error because there is no code to assign values
>> to the variables mark-1st and mark-2nd that it depends on.
>
> The code is a small part of a much larger (1320 lines) package.
>
> Here is sample code to set mark-1st to current cursor position.
> (setq mark-1st (cons
>                    (save-excursion (beginning-of-line) (point-marker))
>                    (col (1- (column-no)))))

I am only interested in seeing how it might be able to highlight the
current rectangle (simultaneously with the current region being
highlighted by Emacs's built in mechanism).  Do you have code to
illustrate that?  Right now, you are supplying less than what I
already have.

-- 
Joe

P.S.  Here is my testing code (which now tries to set a background
color for the overlay faces and sets the priority of these overlays as
high as possible):

;; I'm building on sense-region.el version 1.8 of 2002-05-23, because
;; I don't understand what version 1.9 is doing and all the
;; documentation is in Japanese and Google's translation doesn't make
;; much sense.  You can get version 1.8 in the recent Ubuntu versions
;; of the “sense-region” package (it is the only file in this .tar.gz
;; file):
;;
;;   http://archive.ubuntu.com/ubuntu/pool/universe/s/sense-region/sense-region_0.0.20020523.orig.tar.gz
;;
;; The file sense-region_2002-05-23.el on the author's web site is
;; actually a significantly later version from 2002-08-25, so don't get
;; that file.

;; *** TODO: Switch this to using the rectangle highlighting code from
;; cua-rect.el which now comes in Emacs (since 22.1).

(defun require-sense-region-if-found ()
  (or (require 'sense-region nil t)
      (require 'sense-region
               "/mnt/gentoo-portage/jbw/sense-region-0.0.20020523/sense-region.el"
               t)))

(require-sense-region-if-found)

(progn
  (make-face 'sense-region-face t)
  ;;(set-face-attribute 'sense-region-face nil :box '(:line-width -1 :color "red"))
  (set-face-attribute 'sense-region-face nil :box nil)
  ;;;; XOXOXOXO
  ;;;; OXOXOXOX
  ;;;; #o125 == #x55, #o252 == #xAA
  ;;(set-face-stipple 'sense-region-face '(8 2 "\125\252"))
  ;;;; XXO == 1 + 2 == 3
  ;;;; XOX == 1 + 4 == 5
  ;;;; OXX == 2 + 4 == 6
  ;;(set-face-stipple 'sense-region-face '(3 3 "\003\005\006"))
  ;;;; XOO == 1
  ;;;; OOX == 4
  ;;;; OXO == 2
  ;;(set-face-stipple 'sense-region-face '(3 3 "\001\004\002"))
  ;;;; XOOO == 1
  ;;;; OOOX == 8
  ;;;; OOXO == 4
  ;;;; OXOO == 2
  ;;(set-face-stipple 'sense-region-face '(4 4 "\001\010\004\002"))
  ;;;; XOOOO ==  1 == 001
  ;;;; OOOOX == 16 == 020
  ;;;; OOOXO ==  8 == 010
  ;;;; OOXOO ==  4 == 004
  ;;;; OXOOO ==  2 == 002
  ;;(set-face-stipple 'sense-region-face '(5 5 "\001\020\010\004\002"))
  ;;(set-face-stipple 'sense-region-face '(7 7 "\100\040\020\010\004\002\001"))
  (set-face-stipple 'sense-region-face '(8 8 "\200\100\040\020\010\004\002\001"))
  (set-face-stipple 'sense-region-face '(9 9 "\000\001\200\000\100\000\040\000\020\000\010\000\004\000\002\000\001\000"))
  (set-face-stipple 'sense-region-face '(11 11 "\000\004\000\002\000\001\200\000\100\000\040\000\020\000\010\000\004\000\002\000\001\000"))
  (set-face-stipple 'sense-region-face '(12 12 "\000\010\000\004\000\002\000\001\200\000\100\000\040\000\020\000\010\000\004\000\002\000\001\000"))
  ;;(set-face-stipple 'sense-region-face '(14 14 "\000\040\000\020\000\010\000\004\000\002\000\001\200\000\100\000\040\000\020\000\010\000\004\000\002\000\001\000"))
  ;;(set-face-inverse-video-p 'sense-region-face t)
  (set-face-inverse-video-p 'sense-region-face nil)
  ;;(set-face-foreground 'sense-region-face "red")
  (set-face-background 'sense-region-face nil)
  (set-face-background 'sense-region-face "red")
  (set-face-foreground 'sense-region-face nil)
  (setq sense-region-status 'rectangle))

(defadvice sense-region-on (around jbw-override-completely activate)
  (interactive)
  (if (featurep 'sense-region)
      (add-hook 'post-command-hook 'sense-region-redisplay)))

(defadvice sense-region-off (around jbw-override-completely activate)
  (interactive)
  (if (featurep 'sense-region)
      (sense-region-to-region))
  (remove-hook 'post-command-hook 'sense-region-redisplay))

(defadvice sense-region-to-region (around jbw-override-completely activate)
  (interactive)
  (mell-sign-rectangle-highlight-off sense-region-overlay-list)
  (setq sense-region-overlay-list nil))

(defadvice mell-transient-region-active-p (around jbw-handle-delayed-mark-deactivation activate)
  "Need to make sure (eq deactivate-mark t) taken as a sign the
region is not active (this is a bug in sense-region.el)."
  (if deactivate-mark
      nil
    ad-do-it))

;; This function is copied from version 1.8 of sense-region.el and
;; modified by inserting the commented sexp.
(defun mell-sign-rectangle-highlight (start end &optional buffer face)
  (save-excursion
    (or buffer (setq buffer (current-buffer)))
    (mapcar
     '(lambda (region)
	(prog1
	    (setq overlay
		  (make-overlay (car region) (cdr region) buffer nil t))
          ;; jbw: inserted next sexp (only difference from version 1.8)
          (overlay-put overlay 'priority most-positive-fixnum)
	  (overlay-put overlay 'face (or face 'highlight))
	  (overlay-put overlay 'evaporate t)
	  ))
     (mell-region-get-visible-rectangle-list start end))
;     (mell-region-get-rectangle-list start end))
    ))

Re: no good way to highlight rectangle while region is highlighted

[Ehud Karni]

On Sat, 28 Jul 2007 01:10:26, Joe Wells wrote:
>
> "Ehud Karni" <ehud@unix.mvs.co.il> writes:
>
> My reading of the documentation (supplemented by my perusal of the
> Emacs C source code) for "merging" of face F1 and face F2 is that it
> is not a symmetric operation and one of the faces takes priority.  In
> the case of distinct face attributes, both are used; this means if
> face F1 has value V1 for attribute A1 and face F2 has value V2 for
> attribute A2, then you get a new face with V1 for A1 and V2 for A2.
                               ======================================
> In the case of assignments for the same face attribute, only one is
> used; assuming face F1 has priority, if face F1 has value V1 for
> attribute A0 and face F2 has value V2 for the same attribute A0, then
> value V1 is used.
>
> Note that there is no notion of merging of colors.  One of the two
> colors is always used, unchanged.

I checked it and this is true. Your only hope is to use merging of
attributes not used in "region" face.

> I have done testing that agrees with this.  Although I had no reason
> to believe they would make any difference, I just now tried overlay
> priorities anyway and verified that overlay priorities make no
> difference whatsoever in this matter.  No matter how high the overlay
> priority, the background color of the overlay's face can not override
> the background color of the "region" face (and no attempt at color
> combination occurs).  I even tried most-positive-fixnum as the overlay
> priority (and you can't get any higher than that).

I also rechecked the overlay priority issue and found it is not needed.
I think I added it a long time ago when font-lock used overlays.

I checked both X and tty and found the following:
1. When `transient-mark-mode' is enabled the "region" face attributes
overrides any other, but when it is disabled and you use the mouse
to mark a region (the `mouse-drag-region' function) it uses an overlay
and so the overlay priority may have an influence.

2. All the X only face attributes (like box, width, strike-through)
should not be used because they does not work on tty (and some of them
like box and overline also change the display by adding 1 extra pixel
between text lines).

3. If you use attributes not set by the "region" face, most notably
the inverse-video attribute, you can see it through the rest of the
region.

Ehud.


--
 Ehud Karni           Tel: +972-3-7966-561  /"\
 Mivtach - Simon      Fax: +972-3-7966-667  \ /  ASCII Ribbon Campaign
 Insurance agencies   (USA) voice mail and   X   Against   HTML   Mail
 http://www.mvs.co.il  FAX:  1-815-5509341  / \
 GnuPG: 98EA398D <http://www.keyserver.net/>    Better Safe Than Sorry

Re: no good way to highlight rectangle while region is highlighted

[Richard Stallman]

    I think highlighting both the rectangle and the region will be easiest
    by drawing colored lines around the rectangle and keeping the current
    way of highlighting the region.  I have already tried this (using the
    ?box? feature with colored lines), and I find it the easiest to
    visually understand of the ways that I have gotten to work.  I'm not
    using it now because every time the rectangle changes, areas of text
    get shifted on the screen right or left by 1 pixel and this is
    visually jarring.

Are you saying that, with the new face feature you asked for,
the rectangle outline would work perfectly?

If someone wants to implement it, I have nothing against it.

Re: no good way to highlight rectangle while region is highlighted

[Joe Wells]

Richard Stallman <rms@gnu.org> writes:

>     I think highlighting both the rectangle and the region will be easiest
>     by drawing colored lines around the rectangle and keeping the current
>     way of highlighting the region.  I have already tried this (using the
>     ?box? feature with colored lines), and I find it the easiest to
>     visually understand of the ways that I have gotten to work.  I'm not
>     using it now because every time the rectangle changes, areas of text
>     get shifted on the screen right or left by 1 pixel and this is
>     visually jarring.
>
> Are you saying that, with the new face feature you asked for,
> the rectangle outline would work perfectly?

As I mentioned, I have tried the simultaneous highlighting of the
region and the rectangle, using background color for the region (the
default behavior), and the “box” face feature for the rectangle.  The
only problem with this (as far as I can tell from my experience) is
that the “box” face feature uses horizontal space (and so the text
gets shifted back and forth as the rectangle changes).  If this
shifting of the text didn't happen, I think this method of
highlighting the rectangle would be quite nice.

I can't claim it would be perfect.  If the vertical lines don't take
extra horizontal space, then obviously for some text the lines will
overlap a bit with the glyphs being displayed.  (This problem can
already happen for overlap with the horizontal lines, but that is less
of an issue because in the most commonly used fonts very few glyphs
use pixels in the top and bottom lines of the space they are
allocated.)

> If someone wants to implement it, I have nothing against it.

Always the main issue.

-- 
Joe

overlays with higher priority than region [was: no good way to highlight rectangle while region is highlighted]

[Drew Adams]

>     Summary of this message: This is a feature request for (1) the
>     possibility that some overlays can have priority over the use of the
>     region face, and/or (2) a variant of the ?box? face feature where the
>     vertical lines of the box take no extra space.
>
RMS> (2) sounds terribly low-level.  (1) is cleaner.

RMS> I think (1) could be implemented with a change in
RMS> face_at_buffer_position. For instance, we could define a
RMS> certain priority for the region, so that overlays whose
RMS> priority exceeds that cover the region.
RMS> It doesn't look terribly hard, but you need to think carefully
RMS> to prove that you store the value into *ENDPTR in all cases.

Did this get dropped? I too would like to see the possibility of having an
overlay that has higher priority than the region. One use case is
highlighting a line within the region.

[Please don't suggest other ways to draw attention to the line, here (e.g.
display-table, fringe). That is just an example. I would like to be able to
have an overlay with a higher priority than the region - I'm not interested
in this example per se.]