Display question

Display question

[Michael Welsh Duggan]

[-- Attachment #1: Type: text/plain, Size: 657 bytes --]

Try evaluating the following elisp in a graphical session:

(defface special-char
  '((t :box t))
  "Face for special chars")

(defconst RLO #("\u200bRLO\u200b" 1 4 (face special-char)))

(defun set-disp-entry (table idx str)
  (let* ((len (length str))
         (result (make-vector len nil)))
    (dotimes (c len)
      (let ((face (get-text-property c 'face str))
            (char (aref str c)))
        (aset result c (make-glyph-code char face))))
    (set-char-table-range table idx result)))

(set-disp-entry standard-display-table #x202e RLO)

(ucs-insert #x202e)

Afterward, I get a character that looks like a double-boxed RLO.  Image
included:


[-- Attachment #2: boxed.png --]
[-- Type: image/png, Size: 36577 bytes --]

[-- Attachment #3: Type: text/plain, Size: 232 bytes --]


Is this expected?  If I just do (insert RLO RLO RLO) a few times in a
non-font-locked buffer, I get a box around RLO, with a tiny space
between the boxes, and not the double box seen here.

-- 
Michael Welsh Duggan
(md5i@md5i.com)

Re: Display question

[Eli Zaretskii]

> From: Michael Welsh Duggan <md5i@md5i.com>
> Date: Wed, 08 Jun 2011 01:55:54 -0400
> 
> Afterward, I get a character that looks like a double-boxed RLO.  Image
> included:
> 
> Is this expected?  If I just do (insert RLO RLO RLO) a few times in a
> non-font-locked buffer, I get a box around RLO, with a tiny space
> between the boxes, and not the double box seen here.

The difference between these two use cases is that characters
delivered from display tables are not subject to the treatment we give
to "glyphless characters", which is what u+200b ZERO WIDTH SPACE is.
You expect this character to be displayed as a thin space (probably to
get the boxed "RLO" look prettier), but this thin space will only show
when u+200b is treated as a glyphless character, which can happen when
it comes from the buffer, but not from a display table.

The problem here is that display tables and glyphless character
display are 2 similar, but different features, and we didn't yet
figure out how to mix them, or whether to fuse them into a single
feature.  So now they "fight" each other, and the display table wins
in this case.

We could perhaps find some ad-hoc solution for this particular case,
but I really think we should solve the general issue -- how to combine
display tables and glyphless character display together -- before we
discuss the solutions.

Btw, you cannot expect that u+200b is displayed as a thin space,
because the user could change that via glyphless-char-display-control,
which see.  So this particular use of u+200b is questionable to begin
with, IMO.

Re: Display question

[Michael Welsh Duggan]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Michael Welsh Duggan <md5i@md5i.com>
>> Date: Wed, 08 Jun 2011 01:55:54 -0400
>> 
>> Afterward, I get a character that looks like a double-boxed RLO.  Image
>> included:
>> 
>> Is this expected?  If I just do (insert RLO RLO RLO) a few times in a
>> non-font-locked buffer, I get a box around RLO, with a tiny space
>> between the boxes, and not the double box seen here.
>
> The difference between these two use cases is that characters
> delivered from display tables are not subject to the treatment we give
> to "glyphless characters", which is what u+200b ZERO WIDTH SPACE is.
> You expect this character to be displayed as a thin space (probably to
> get the boxed "RLO" look prettier), but this thin space will only show
> when u+200b is treated as a glyphless character, which can happen when
> it comes from the buffer, but not from a display table.

[...]

> Btw, you cannot expect that u+200b is displayed as a thin space,
> because the user could change that via glyphless-char-display-control,
> which see.  So this particular use of u+200b is questionable to begin
> with, IMO.

I wasn't actually thinking it would appear as a space when I initially
tried it.  I was using it to separate two runs of character properties
so the boxes wouldn't join if they were next to each other.  (This does
and does not work if I set u+200b to zero-width.  I think this confuses
the display mechanism a little.)  I did not know about
glyphless-char-display, which seems to have the feature I was trying to
implement built in.  Thanks for the help.

(I was playing around with ideas on how to display and undisplay bidi control
characters, as you might have guessed.)

-- 
Michael Welsh Duggan
(md5i@md5i.com)

Re: Display question

[Eli Zaretskii]

> From: Michael Welsh Duggan <md5i@md5i.com>
> Date: Wed, 08 Jun 2011 09:13:20 -0400
> Cc: emacs-devel@gnu.org
> 
> (I was playing around with ideas on how to display and undisplay bidi control
> characters, as you might have guessed.)

It might be a good idea to have a minor mode that would show the
directional formatting codes in such a human-readable form.  Please
consider contributing such a mode.  TIA.

Re: Display question

[Michael Welsh Duggan]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Michael Welsh Duggan <md5i@md5i.com>
>> Date: Wed, 08 Jun 2011 09:13:20 -0400
>> Cc: emacs-devel@gnu.org
>> 
>> (I was playing around with ideas on how to display and undisplay bidi control
>> characters, as you might have guessed.)
>
> It might be a good idea to have a minor mode that would show the
> directional formatting codes in such a human-readable form.  Please
> consider contributing such a mode.  TIA.

So, for the most part it looks like 

(update-glyphless-char-display 
 'glyphless-char-display-control 
 '((format-control . acronym) (no-font . hex-code)))

does what I want.  But the nature of glyphless-char-display is that of a
global variable, as opposed to a buffer-local variable, and making this
variable buffer local and doing a vector-based copy-tree of the original
doesn't cause a buffer-local effect.  I don't know necessarily think
that declaring glyphless-char-display with DEFVAR_PER_BUFFER is
necessarily the right solution.  Presumably it->object would be the
buffer in question in lookup_glyphless_char_display, so getting the
buffer local value would be possible, but honestly if we were to want to
used the buffer local value, it should be cached at the beginning of the
display of the buffer.

Thoughts?

-- 
Michael Welsh Duggan
(md5i@md5i.com)