bug of display-table & make-glyph-code

bug of display-table & make-glyph-code

[levin]

To reinvent this bug, please follow:

1. Please save the text below as glyph.org, visit it, and `M-x org-mode' to 
turn on org mode. 

2. Keep the first headline collapsed by pressing TAB (if neccessary) on it.

3. you can expand the second/third headline by press TAB on it.

4. eval the lisp code in the second headline, this CANNOT change "..." 
display.

5. eval the lisp code in the third headline, this CAN change "..." display.

I find out that if make-glyph-code returns a negative int, then the 
display table does not take effect on "..." display.

--------8<-------------8<--------
* Please keep me collapsed by pressing TAB (if neccessary)
some info to hide

* please eval me, this CANNOT change "..." display
(describe-face 'org-warning)

(face-id 'org-warning)  # mine is 77 here

(unless buffer-display-table
  (setq buffer-display-table (make-display-table)))

(set-display-table-slot buffer-display-table 'selective-display
			(vconcat (mapcar
				  (lambda (c)
				    (make-glyph-code c 'org-warning))
				  "...")))

* please eval me, this can change ellipse display 
(describe-face 'tooltip)

(face-id 'tooltip)   # mine is 54 here

(unless buffer-display-table
  (setq buffer-display-table (make-display-table)))

(set-display-table-slot buffer-display-table 'selective-display
			(vconcat (mapcar
				  (lambda (c)
				    (make-glyph-code c 'tooltip))
				  "...")))
--------8<-------------8<--------

My environment:
In GNU Emacs 23.0.0.2 (i686-pc-linux-gnu)
 of 2007-08-27 on MagicLinux
configured using `configure  '--with-x-toolkit=no''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: zh_CN.GB18030
  value of $XMODIFIERS: nil
  locale-coding-system: chinese-gb18030-unix
  default-enable-multibyte-characters: t

Major mode: Org

Minor modes in effect:
  encoded-kbd-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-compression-mode: t
  line-number-mode: t

--
Levin

Re: bug of display-table & make-glyph-code

[Richard Stallman]

[I sent this message a week ago but did not get a response.]

Would someone please DTRT and ack?

From: levin <zslevin@gmail.com>
To: emacs-devel@gnu.org
Date: Mon, 27 Aug 2007 17:32:22 +0800
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain;
  charset="gb18030"
Subject: bug of display-table & make-glyph-code

To reinvent this bug, please follow:

1. Please save the text below as glyph.org, visit it, and `M-x org-mode' to 
turn on org mode. 

2. Keep the first headline collapsed by pressing TAB (if neccessary) on it.

3. you can expand the second/third headline by press TAB on it.

4. eval the lisp code in the second headline, this CANNOT change "..." 
display.

5. eval the lisp code in the third headline, this CAN change "..." display.

I find out that if make-glyph-code returns a negative int, then the 
display table does not take effect on "..." display.

--------8<-------------8<--------
* Please keep me collapsed by pressing TAB (if neccessary)
some info to hide

* please eval me, this CANNOT change "..." display
(describe-face 'org-warning)

(face-id 'org-warning)  # mine is 77 here

(unless buffer-display-table
  (setq buffer-display-table (make-display-table)))

(set-display-table-slot buffer-display-table 'selective-display
			(vconcat (mapcar
				  (lambda (c)
				    (make-glyph-code c 'org-warning))
				  "...")))

* please eval me, this can change ellipse display 
(describe-face 'tooltip)

(face-id 'tooltip)   # mine is 54 here

(unless buffer-display-table
  (setq buffer-display-table (make-display-table)))

(set-display-table-slot buffer-display-table 'selective-display
			(vconcat (mapcar
				  (lambda (c)
				    (make-glyph-code c 'tooltip))
				  "...")))
--------8<-------------8<--------

My environment:
In GNU Emacs 23.0.0.2 (i686-pc-linux-gnu)
 of 2007-08-27 on MagicLinux
configured using `configure  '--with-x-toolkit=no''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: zh_CN.GB18030
  value of $XMODIFIERS: nil
  locale-coding-system: chinese-gb18030-unix
  default-enable-multibyte-characters: t

Major mode: Org

Minor modes in effect:
  encoded-kbd-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-compression-mode: t
  line-number-mode: t

--
Levin


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: bug of display-table & make-glyph-code

[martin rudalics]

 > To reinvent this bug, please follow:

[...]

 > 4. eval the lisp code in the second headline, this CANNOT change "..."
 > display.

Here it displays them with org-warning face as expected.

[...]

 > (face-id 'org-warning)  # mine is 77 here

Evaluates to 142 here.

[...]

 > My environment:

 > In GNU Emacs 23.0.0.2 (i686-pc-linux-gnu)
 >  of 2007-08-27 on MagicLinux
 > configured using `configure  '--with-x-toolkit=no''

Can someone reproduce the OP's behavior with Emacs 22 ?

Re: bug of display-table & make-glyph-code

[Glenn Morris]

martin rudalics wrote:

> Can someone reproduce the OP's behavior with Emacs 22 ?

Neither with Emacs 22 nor the current CVS trunk.

Re: bug of display-table & make-glyph-code

[levin]

Glenn Morris wrote:
> martin rudalics wrote:
> > Can someone reproduce the OP's behavior with Emacs 22 ?
>
> Neither with Emacs 22 nor the current CVS trunk.

I use GNU Emacs 23 CVS.

Re: bug of display-table & make-glyph-code

[Glenn Morris]

levin wrote:

> I use GNU Emacs 23 CVS.

That does not mean very much I'm afraid. The relevant information is:
which branch of CVS, and when did you update.

Re: bug of display-table & make-glyph-code

[Du Jingwu]

Glenn Morris:
> levin wrote:
> > I use GNU Emacs 23 CVS.
>
> That does not mean very much I'm afraid. The relevant information is:
> which branch of CVS, and when did you update.

I did a cvs update of emacs-unicode-2 branch just now, bootstrapped it, and 
the bug still appeared.

--
Levin

Re: bug of display-table & make-glyph-code

[Richard Stallman]

    I use GNU Emacs 23 CVS.

"Emacs 23" is not well-defined now.
Do you use the CVS trunk, or the unicode-2 branch?

Re: bug of display-table & make-glyph-code

[Richard Stallman]

    > Can someone reproduce the OP's behavior with Emacs 22 ?

    Neither with Emacs 22 nor the current CVS trunk.

If we cannot make it fail, we can cross it off the list.
Would you please?

Re: bug of display-table & make-glyph-code

[Glenn Morris]

Richard Stallman wrote:

> If we cannot make it fail, we can cross it off the list.
> Would you please?

It's not on any list. The only extant Emacs 22 bugs seem to be:

eshell external commands
KDE maximization
getopts_long and etags?
static locals and HPUX?

Re: bug of display-table & make-glyph-code

[martin rudalics]

 >>If we cannot make it fail, we can cross it off the list.
 >>Would you please?
 >
 >
 > It's not on any list.

I didn't put it there because I couldn't reproduce it on Emacs 22.

 > The only extant Emacs 22 bugs seem to be:
 >
 > eshell external commands
 > KDE maximization

To me this seems a consequence of the known restriction that Emacs
frames can't have arbitrary pixel size.  Apparently the OP is the
only Emacs user on KDE.

 > getopts_long and etags?
 > static locals and HPUX?


I think the following two issues should be resolved too:

"22.1.1; Frame title no more updated after calling `set-frame-configuration'"

first raised 2007-08-30 on emacs-devel, and

"dired-warning face not colored on 8-color ttys"

first raised 2007-08-30 on bug-gnu-emacs.  Please have a look.


Finally, the problem reported by davidk

"Re: display-buffer change"

as from 2007-08-27 on bug-gnu-emacs hasn't been resolved satisfactorily
either.

Re: bug of display-table & make-glyph-code

[Glenn Morris]

martin rudalics wrote:

> "dired-warning face not colored on 8-color ttys"
>
> first raised 2007-08-30 on bug-gnu-emacs.

Thought your font-lock-warning-face solution was good.

Re: bug of display-table & make-glyph-code

[martin rudalics]

>>"dired-warning face not colored on 8-color ttys"
>>
>>first raised 2007-08-30 on bug-gnu-emacs.
> 
> 
> Thought your font-lock-warning-face solution was good.
> 

The first feedback I got on this ;-)

BTW, the OP suggested to change this for other faces inheriting from
font-lock-comment-face as well.  Does anyone know a face where this
would be useful?

Re: bug of display-table & make-glyph-code

[Glenn Morris]

martin rudalics wrote:

> BTW, the OP suggested to change this for other faces inheriting from
> font-lock-comment-face as well.  Does anyone know a face where this
> would be useful?

find . -name '*.el' | xargs grep 'inherit.*font-lock-comment-face'

change-log-acknowledgement, dired-warning, iswitchb-single-match,
outline-5

Haven't looked if it's appropriate to change all of them.

Re: bug of display-table & make-glyph-code

[martin rudalics]

 >>BTW, the OP suggested to change this for other faces inheriting from
 >>font-lock-comment-face as well.  Does anyone know a face where this
 >>would be useful?
 >
 >
 > find . -name '*.el' | xargs grep 'inherit.*font-lock-comment-face'
 >
 > change-log-acknowledgement, dired-warning, iswitchb-single-match,
 > outline-5
 >
 > Haven't looked if it's appropriate to change all of them.

I think `change-log-acknowledgement' should be left alone.  Changing
`outline-5' doesn't make much sense since `outline-1' and `outline-4'
can't be distinguished any more.  A similar argument holds for
`iswitchb-single-match' where `iswitchb-current-match' and
`iswitchb-virtual-matches' are already indistinguishable.

Re: bug of display-table & make-glyph-code

[Glenn Morris]

martin rudalics wrote:

> I think `change-log-acknowledgement' should be left alone.  Changing
> `outline-5' doesn't make much sense since `outline-1' and `outline-4'
> can't be distinguished any more.  A similar argument holds for
> `iswitchb-single-match' where `iswitchb-current-match' and
> `iswitchb-virtual-matches' are already indistinguishable.

Well, that's easy. :)  I say; install your dired-warning fix, and cross
this off the list.

Re: bug of display-table & make-glyph-code

[martin rudalics]

 > Well, that's easy. :)  I say; install your dired-warning fix, and cross
 > this off the list.

Mapping dired-warning to font-lock-warning-face was a bad idea: The
latter is already used for marking and flagging.  It seems better to use
`font-lock-comment-delimiter-face' just for the min-colors 8 case as in
the patch below.

*** dired.el.~1.359.2.6.~	Tue Aug  7 16:01:52 2007
--- dired.el	Thu Sep  6 10:34:06 2007
***************
*** 335,341 ****
     "Face name used for flagged files.")

   (defface dired-warning
!   '((t (:inherit font-lock-comment-face)))
     "Face used to highlight a part of a buffer that needs user attention."
     :group 'dired-faces
     :version "22.1")
--- 335,343 ----
     "Face name used for flagged files.")

   (defface dired-warning
!   '((((class color) (min-colors 16)) (:inherit font-lock-comment-face))
!     (((class color) (min-colors 8)) (:inherit font-lock-comment-delimiter-face))
!     (t (:inherit font-lock-comment-face)))
     "Face used to highlight a part of a buffer that needs user attention."
     :group 'dired-faces
     :version "22.1")

Re: bug of display-table & make-glyph-code

[Glenn Morris]

martin rudalics wrote:

> Mapping dired-warning to font-lock-warning-face was a bad idea: The
> latter is already used for marking and flagging.

Does that matter? The marking and flagging faces seem to be applied to
the file name. The warning face seems only to be applied to the
permissions. So it's not like they overlap or anything. And I think a
warning should be displayed in, umm, a warning face (so it has
emphasis), rather than a comment face (so it is subdued).

Re: bug of display-table & make-glyph-code

[martin rudalics]

 >>Mapping dired-warning to font-lock-warning-face was a bad idea: The
 >>latter is already used for marking and flagging.
 >
 >
 > Does that matter? The marking and flagging faces seem to be applied to
 > the file name. The warning face seems only to be applied to the
 > permissions. So it's not like they overlap or anything.

Good.

 > And I think a
 > warning should be displayed in, umm, a warning face (so it has
 > emphasis), rather than a comment face (so it is subdued).

That's what I thought in the first place.  Using
`font-lock-warning-face' is an "incompatible" change though, hence I
would have to document it in NEWS?

Re: bug of display-table & make-glyph-code

[Glenn Morris]

martin rudalics wrote:

> That's what I thought in the first place. Using
> `font-lock-warning-face' is an "incompatible" change though, hence I
> would have to document it in NEWS?

Well, an incompatible change only in a default, and a change for the
better, IMO. Though changing faces does seem to be a minefield. :(
If you wanted to be ultra-cautious, just fix the bug in 22, and change
to warning in the trunk?

Re: bug of display-table & make-glyph-code

[martin rudalics]

 > Well, an incompatible change only in a default, and a change for the
 > better, IMO. Though changing faces does seem to be a minefield. :(

Some of the mines are due to changing the `font-lock-comment-face'
default for Emacs 22.

 > If you wanted to be ultra-cautious, just fix the bug in 22, and change
 > to warning in the trunk?

There's no obvious fix.  Using `font-lock-comment-delimiter-face' would
have to be documented as well and I would have to cross two minefields
then ...

Re: bug of display-table & make-glyph-code

[Richard Stallman]

    That's what I thought in the first place.  Using
    `font-lock-warning-face' is an "incompatible" change though, hence I
    would have to document it in NEWS?

Maybe, but I am not sure it actually rises to the threshold where
a NEWS entry is needed.

Re: bug of display-table & make-glyph-code

[Glenn Morris]

Richard Stallman wrote:

>     Using `font-lock-warning-face' is an "incompatible" change
>     though, hence I would have to document it in NEWS?
>
> Maybe, but I am not sure it actually rises to the threshold where
> a NEWS entry is needed.

I really would just make this change and consider this issue dealt with.

Re: bug of display-table & make-glyph-code

[martin rudalics]

>>    Using `font-lock-warning-face' is an "incompatible" change
>>    though, hence I would have to document it in NEWS?
>>
>>Maybe, but I am not sure it actually rises to the threshold where
>>a NEWS entry is needed.
> 
> 
> I really would just make this change and consider this issue dealt with.

Done.

dired-warning (was: bug of display-table & make-glyph-code)

[Juri Linkov]

> Mapping dired-warning to font-lock-warning-face was a bad idea: The
> latter is already used for marking and flagging.  It seems better to use
> `font-lock-comment-delimiter-face' just for the min-colors 8 case as in
> the patch below.

Since this change was synced to the trunk and I see it in action now,
I agree it was a bad idea.

The primary intention of introducing the dired-warning face was to
warn users about possible security holes.  But red is too strong color.
There are many files and directories where permission to write is correct
(especially for groups), but displaying their permissions in red in dired
is distracting.  This color usually requires an immediate action to fix
the problem, but in most cases there are no problems.

An analogy for this situation are warnings and errors issued by the compiler:
when there is an error, it needs to be fixed, but most warnings are useless.
compile.el uses two separate faces for errors and warnings:
compilation-error and compilation-warning.  compilation-error inherits
from font-lock-warning-face, and compilation-warning has its own definition.

I propose to add a new face font-lock-error-face, to copy its definition
from font-lock-warning-face, and to copy the definition of compilation-warning
to font-lock-warning-face.  So dired-warning inheriting now from
font-lock-warning-face will use the new definition.

Making this distinction between two faces font-lock-error-face and
font-lock-warning-face will be useful for other packages where
error text should be displayed in the strong color, and warnings in
more subdued color.

PS: This proposal is for the trunk.  For Emacs-22 I think we should
restore the old color by copying definitions of font-lock-comment-face
and font-lock-comment-delimiter-face to dired-warning like:

(defface dired-warning
  '((((class color) (min-colors 88) (background light))
     (:foreground "Firebrick"))
    (((class color) (min-colors 88) (background dark))
     (:foreground "chocolate1"))
    (((class color) (min-colors 8) (background light))
     :foreground "red")
    (((class color) (min-colors 8) (background dark))
     :foreground "red1"))
  "Face used to highlight a part of a buffer that needs user attention."
  :group 'dired-faces
  :version "22.1")

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: dired-warning

[martin rudalics]

 > Since this change was synced to the trunk and I see it in action now,
 > I agree it was a bad idea.

The problem provoking that change was that with eight colors
`font-lock-comment-delimiter-face' usurpated `font-lock-comment-face'
leaving the latter without foreground.

 > I propose to add a new face font-lock-error-face, to copy its definition
 > from font-lock-warning-face, and to copy the definition of compilation-warning
 > to font-lock-warning-face.  So dired-warning inheriting now from
 > font-lock-warning-face will use the new definition.
 >
 > Making this distinction between two faces font-lock-error-face and
 > font-lock-warning-face will be useful for other packages where
 > error text should be displayed in the strong color, and warnings in
 > more subdued color.

Would this fit into an eight colors scheme?

 > PS: This proposal is for the trunk.  For Emacs-22 I think we should
 > restore the old color by copying definitions of font-lock-comment-face
 > and font-lock-comment-delimiter-face to dired-warning like:
 >
 > (defface dired-warning
 >   '((((class color) (min-colors 88) (background light))
 >      (:foreground "Firebrick"))
 >     (((class color) (min-colors 88) (background dark))
 >      (:foreground "chocolate1"))
 >     (((class color) (min-colors 8) (background light))
 >      :foreground "red")
 >     (((class color) (min-colors 8) (background dark))
 >      :foreground "red1"))
 >   "Face used to highlight a part of a buffer that needs user attention."
 >   :group 'dired-faces
 >   :version "22.1")

dired.el face specs are based on inheriting, hence this might break some
people's customizations.

Re: dired-warning

[Juri Linkov]

>> Making this distinction between two faces font-lock-error-face and
>> font-lock-warning-face will be useful for other packages where
>> error text should be displayed in the strong color, and warnings in
>> more subdued color.
>
> Would this fit into an eight colors scheme?

We could add appropriate conditions for an eight colors scheme.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: bug of display-table & make-glyph-code

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Wed, 05 Sep 2007 12:44:29 -0400
> Cc: rms@gnu.org, emacs-devel@gnu.org
> 
> find . -name '*.el' | xargs grep 'inherit.*font-lock-comment-face'

AKA "grep -R 'inherit.*font-lock-comment-face' --include='*.el'"
(assuming you are on GNU/Linux, or otherwise have GNU Grep installed).

I know: old habits die hard...

Re: bug of display-table & make-glyph-code

[levin]

martin rudalics wrote:
>  > KDE maximization
>
> To me this seems a consequence of the known restriction that Emacs
> frames can't have arbitrary pixel size.  Apparently the OP is the
> only Emacs user on KDE.

hmm, me too, the Emacs user on KDE, experiencing the same maximization 
problem.

--
Levin

Re: bug of display-table & make-glyph-code

[Richard Stallman]

    >  > KDE maximization
    >
    > To me this seems a consequence of the known restriction that Emacs
    > frames can't have arbitrary pixel size.  Apparently the OP is the
    > only Emacs user on KDE.

    hmm, me too, the Emacs user on KDE, experiencing the same maximization 
    problem.

If we are sure that this is due to that basic limitation,
we can delete it from the pending bug list.  Are we sure?

frame resizing under KDE (was Re: bug of display-table & make-glyph-code)

[Stephen Berman]

On Wed, 05 Sep 2007 10:08:14 +0200 martin rudalics <rudalics@gmx.at> wrote:

>> KDE maximization
>
> To me this seems a consequence of the known restriction that Emacs
> frames can't have arbitrary pixel size.  Apparently the OP is the
> only Emacs user on KDE.

I think I'm the original OP of this bug back in 2005, though not the
OP of the recent thread; and someone else admitted to seeing it in KDE
too; so there are at least three of us :-).  Anyway, I don't think the
bug is solely due to the frame size restriction, because it only
happens under the GTK+ build.

Steve Berman

Re: frame resizing under KDE (was Re: bug of display-table & make-glyph-code)

[martin rudalics]

 >>>KDE maximization
 >>
 >>To me this seems a consequence of the known restriction that Emacs
 >>frames can't have arbitrary pixel size.  Apparently the OP is the
 >>only Emacs user on KDE.
 >
 >
 > I think I'm the original OP of this bug back in 2005, though not the
 > OP of the recent thread; and someone else admitted to seeing it in KDE
 > too; so there are at least three of us :-).  Anyway, I don't think the
 > bug is solely due to the frame size restriction, because it only
 > happens under the GTK+ build.

Could you list here which of your build/manager combinations handle
maximization correctly and which don't?  Is it possible that some of
them incidentally DTRT because the usable screen area is a multiple of
the character height?

Re: frame resizing under KDE (was Re: bug of display-table & make-glyph-code )

[Levin]

martin rudalics wrote:
>  >>>KDE maximization
>  >>
>  >>To me this seems a consequence of the known restriction that Emacs
>  >>frames can't have arbitrary pixel size.  Apparently the OP is the
>  >>only Emacs user on KDE.
>  >
>  > I think I'm the original OP of this bug back in 2005, though not the
>  > OP of the recent thread; and someone else admitted to seeing it in KDE
>  > too; so there are at least three of us :-).  Anyway, I don't think the
>  > bug is solely due to the frame size restriction, because it only
>  > happens under the GTK+ build.
>
> Could you list here which of your build/manager combinations handle
> maximization correctly and which don't?  Is it possible that some of
> them incidentally DTRT because the usable screen area is a multiple of
> the character height?
>

Strange. If I click the maximum button of emacs in KDE repeatedly and fastly,
sometimes I can get emacs maximized.

Is there any hook or code that will restore the maximized window back to 
normal one?
--
Levin

Re: frame resizing under KDE

[Stephen Berman]

On Wed, 05 Sep 2007 19:42:23 +0200 martin rudalics <rudalics@gmx.at> wrote:

> Could you list here which of your build/manager combinations handle
> maximization correctly and which don't?  Is it possible that some of
> them incidentally DTRT because the usable screen area is a multiple of
> the character height?

I currently have a Lucid build of Emacs 22.0.90 and GTK+ builds of
22.0.50, 22.0.90, 22.0.91, 22.0.92, 22.0.93, 22.0.96, 22.0.97,
22.0.98, as well as the released 22.1 and CVS trunk (pre-multi-tty)
22.1.50.  Under Gnome all of these maximize correctly.

Under KDE, with the non-GTK+ build (GNU Emacs 22.0.90.1
(i686-pc-linux-gnu, X toolkit) of 2006-11-07), frame resizing works as
expected (as with all other applications under KDE):

1. Clicking the maximize icon in the title bar with mouse-1 toggles
   maximization both vertically and horizontally.

2. Clicking with mouse-2 toggles maximization vertically.

3. Clicking with mouse-3 toggles maximization horizontally.  

In each case the maximization covers the entire screen area in the
specified dimensions.


With my GTK+ builds of 22.0.50, 22.0.90 and 22.0.91, frame resizing
under KDE works as follows:

1. Clicking the maximize icon with mouse-1 resizes the frame
vertically and horizontally but not quite maximally, in both
dimensions there is space between the frame and the screen edges.
Also, the maximize icon is unchanged and its tooltip still says
"Maximize" (it should have changed to a double window icon and the
tooltip should say "Restore", as it does in the non-GTK+ build).
Subsequently clicking mouse-1 makes the frame momentarily expand to
cover the entire screen, but it immediately returns to the previous,
not quite maximal size.  It is not possible to restore the original
size by clicking the maximization icon.

2. Clicking the maximize icon with mouse-2 resizes the frame
vertically but not quite maximally, and the maximize icon is unchanged
and its tooltip still says "Maximize".  Clicking again with mouse-2
expands the frame to cover the entire vertical space; this makes the
echo area appear to grow, but the scroll bar there does not grow
correspondingly.  Subseqently clicking the maximize icon with mouse-2
toggles between the not quite and the completely vertically maximized
sizes and the icon remains unchanged.

3. Clicking the maximize icon with mouse-3 yields behavior in the
horizontal dimension corresponding to that in the vertical dimension
with mouse-2.


Both the non-GTK+ build of 22.0.90 and the GTK+ builds of 22.0.50,
22.0.90 and 22.0.91 have as default font
-Adobe-Courier-Medium-R-Normal--12-120-75-75-M-70-ISO8859-1.  (This is
what x-fixed-font-alist says.)

Starting with Emacs 22.0.92 the default font changed to
-*-fixed-medium-r-*--16-*-*-*-*-*-fontset-16.  My GTK+ build of this
version, and all subsequent builds up to GNU Emacs 22.1.50.11
(i686-pc-linux-gnu, GTK+ Version 2.10.6) of 2007-08-24 (my latest),
differ from the above as follows:

3. Clicking the maximize icon with mouse-3 works almost as expected:
it toggles between horizontally maximized and the original horizontal
size.  However, when maximized, the icon still shows a single rather
than a double window, and the tooltip still says "Maximize".

2. Clicking the maximize icon with mouse-2 yields the same behavior as
in the GTK+ build of 22.0.90.

1. Clicking the maximize icon with mouse-1 yields the same behavior as
in the GTK+ build of 22.0.90 except that the horizontal dimension is
fully maximized.

With all of these builds, changing the font can make the horizontal
resizing (mouse-3) behave as in pre-22.0.92 builds.  This is the case
e.g. with the following fonts from the Font Menu: "7x13", "9x15",
"10x20".  With the fonts "6x10", "6x12", "6x13", "8x13", "12x24"
horizontal resizing works correctly.

Steve Berman

Re: bug of display-table & make-glyph-code

[Chong Yidong]

martin rudalics <rudalics@gmx.at> writes:

> Finally, the problem reported by davidk
>
> "Re: display-buffer change"
>
> as from 2007-08-27 on bug-gnu-emacs hasn't been resolved satisfactorily
> either.

Actually, Stefan has pointed out that the current behavior was
implemented to fix a bug, and it matches the documentation.  So I
don't think there's a problem here.

Re: bug of display-table & make-glyph-code

[martin rudalics]

> Actually, Stefan has pointed out that the current behavior was
> implemented to fix a bug, and it matches the documentation.  So I
> don't think there's a problem here.

We both agreed on that before.  However the bug led the OP to believe
that this is Emacs' standard behavior and he wanted to have it back.

I suggested to have `display-buffer' not split dedicated windows
(unless there's just one) which should fix his problem.  If we don't,
could someone please tell the OP that we are not going to change this.

Re: bug of display-table & make-glyph-code

[Stefan Monnier]

>> Actually, Stefan has pointed out that the current behavior was
>> implemented to fix a bug, and it matches the documentation.  So I
>> don't think there's a problem here.

> We both agreed on that before.  However the bug led the OP to believe
> that this is Emacs' standard behavior and he wanted to have it back.

> I suggested to have `display-buffer' not split dedicated windows
> (unless there's just one) which should fix his problem.

The case that the OP mentioned seemed like a case where both the old and the
new behaviors are acceptable, with no clear favorite.  So I think we may as
well leave the code alone.
Unless I misunderstood or overlooked a detail, of course.

> If we don't, could someone please tell the OP that we are not going to
> change this.

I'm experimenting with a feature that marks some frames as "balanced" such
that any window-creation/deletion or frame resizing causes the windows to be
rebalanced with balance-windows or balance-windows-area.  In such
a situation, whether "| a | b |" is split as "|a|c| b |" or as "| a |c|b|"
doesn't matter that much, since that'll be rebalanced to something visually
identical anyway.


        Stefan

Re: bug of display-table & make-glyph-code

[martin rudalics]

 >>I suggested to have `display-buffer' not split dedicated windows
 >>(unless there's just one) which should fix his problem.
 >
 >
 > The case that the OP mentioned seemed like a case where both the old and the
 > new behaviors are acceptable, with no clear favorite.  So I think we may as
 > well leave the code alone.
 > Unless I misunderstood or overlooked a detail, of course.

Aren't all your windows dedicated, thus it wouldn't make any difference
for you?  For other users, a dedicated window might express some kind of
desire to not have Emacs touch that window if possible.  Personally, I
have no preferences here.  I'd just wanted to propose the OP a way to
get his old behavior back.

 >>If we don't, could someone please tell the OP that we are not going to
 >>change this.
 >
 >
 > I'm experimenting with a feature that marks some frames as "balanced" such
 > that any window-creation/deletion or frame resizing causes the windows to be
 > rebalanced with balance-windows or balance-windows-area.  In such
 > a situation, whether "| a | b |" is split as "|a|c| b |" or as "| a |c|b|"
 > doesn't matter that much, since that'll be rebalanced to something visually
 > identical anyway.

Would this clash with `temp-buffer-resize-mode'?

Re: bug of display-table & make-glyph-code

[Stefan Monnier]

> Aren't all your windows dedicated, thus it wouldn't make any difference
> for you?

I wasn't talking about my own case.

> For other users, a dedicated window might express some kind of desire to
> not have Emacs touch that window if possible.  Personally, I have no
> preferences here.  I'd just wanted to propose the OP a way to get his old
> behavior back.

I understand.  But I'd just want a clearer explanation about why that would
be a better choice in general (or even in his particular case).

>> I'm experimenting with a feature that marks some frames as "balanced" such
>> that any window-creation/deletion or frame resizing causes the windows to be
>> rebalanced with balance-windows or balance-windows-area.  In such
>> a situation, whether "| a | b |" is split as "|a|c| b |" or as "| a |c|b|"
>> doesn't matter that much, since that'll be rebalanced to something visually
>> identical anyway.

> Would this clash with `temp-buffer-resize-mode'?

I don't think it's incompatible.  It may require extra code to handle it
well, of course.


        Stefan

Re: bug of display-table & make-glyph-code

[martin rudalics]

 > I understand.  But I'd just want a clearer explanation about why that would
 > be a better choice in general (or even in his particular case).

He wants a window of the same size display the same buffer in the same
area of the same frame, whatever he's doing.

Re: bug of display-table & make-glyph-code

[Stefan Monnier]

>> I understand.  But I'd just want a clearer explanation about why that would
>> be a better choice in general (or even in his particular case).

> He wants a window of the same size display the same buffer in the same
> area of the same frame, whatever he's doing.

I must have lost too much context: I do not understand the
above description.  Can someone spell it out in baby-steps for my poor
excuse for a brain?


        Stefan

Re: bug of display-table & make-glyph-code

[martin rudalics]

> I must have lost too much context: I do not understand the
> above description.  Can someone spell it out in baby-steps for my poor
> excuse for a brain?

The OP explained it as follows:

 > Split an emacs frame in two windows showing buffers A and B:
 >
 >    +-------------+
 >    |             |
 >    |      A      |
 >    |             |
 >    +-------------+
 >    |             |
 >    |      B      |
 >    |             |
 >    +-------------+
 >
 > While in the lower window, run
 >
 >     (set-window-dedicated-p (selected-window) t)
 >
 > Now, in the upper window, run
 >
 >     (display-buffer "C")
 >
 > In Emacs 21, this will be the result:
 >
 >    +-------------+
 >    |      A      |
 >    +-------------+
 >    |      C      |
 >    +-------------+
 >    |             |
 >    |      B      |
 >    |             |
 >    +-------------+
 >
 > In Emacs 22, this will be the result:
 >
 >    +-------------+
 >    |             |
 >    |      C      |
 >    |             |
 >    +-------------+
 >    |             |
 >    |      B      |
 >    |             |
 >    +-------------+
 >
 > In Emacs 22 with split-heigh-threshold=10, this will be the result:
 >
 >    +-------------+
 >    |             |
 >    |      A      |
 >    |             |
 >    +-------------+
 >    |      B      |
 >    +-------------+
 >    |      C      |
 >    +-------------+
 >

What he apparently wants is window B always display the same buffer, stay
below all other windows, and not change its size.

Re: bug of display-table & make-glyph-code

[Stefan Monnier]

>> I must have lost too much context: I do not understand the
>> above description.  Can someone spell it out in baby-steps for my poor
>> excuse for a brain?

> The OP explained it as follows:

>> Split an emacs frame in two windows showing buffers A and B:
>> 
>> +-------------+
>> |             |
>> |      A      |
>> |             |
>> +-------------+
>> |             |
>> |      B      |
>> |             |
>> +-------------+
>> 
>> While in the lower window, run
>> 
>> (set-window-dedicated-p (selected-window) t)
>> 
>> Now, in the upper window, run
>> 
>> (display-buffer "C")
>> 
>> In Emacs 21, this will be the result:
>> 
>> +-------------+
>> |      A      |
>> +-------------+
>> |      C      |
>> +-------------+
>> |             |
>> |      B      |
>> |             |
>> +-------------+
>> 
>> In Emacs 22, this will be the result:
>> 
>> +-------------+
>> |             |
>> |      C      |
>> |             |
>> +-------------+
>> |             |
>> |      B      |
>> |             |
>> +-------------+
>> 
>> In Emacs 22 with split-heigh-threshold=10, this will be the result:
>> 
>> +-------------+
>> |             |
>> |      A      |
>> |             |
>> +-------------+
>> |      B      |
>> +-------------+
>> |      C      |
>> +-------------+
>> 

> What he apparently wants is window B always display the same buffer, stay
> below all other windows, and not change its size.

I guess I see the following problems:
0 - it's not clear to me why Emacs chooses to split B rather than A.
    It seems unrelated to the split-height-threshold fix, so we need to look
    into this before being able to determine how best to fix it.
1 - since we're in buffer/window A, it would probably be preferable to place
    buffer C closer rather than further, so in this case after splitting B
    display-buffer should prefer using the top window for C and the bottom
    one for B.
2 - "dedicated" is mostly meant to cause deletion of the buffer to also
    cause deletion of the window.  It says nothing about the window having
    a fixed size or being non-splittable.
3 - we have window-size-fixed for that.
4 - we don't have window-(un)splittable for that (there's a frame parameter
    to prevent splitting windows in that frame, tho).


-- Stefan

Re: display-buffer-change (was Re: bug of display-table & make-glyph-code)

[martin rudalics]

Stefan Monnier schrieb:
 >>>I must have lost too much context: I do not understand the
 >>>above description.  Can someone spell it out in baby-steps for my poor
 >>>excuse for a brain?
 >
 >
 >>The OP explained it as follows:
 >
 >
 >>>Split an emacs frame in two windows showing buffers A and B:
 >>>
 >>>+-------------+
 >>>|             |
 >>>|      A      |
 >>>|             |
 >>>+-------------+
 >>>|             |
 >>>|      B      |
 >>>|             |
 >>>+-------------+
 >>>
 >>>While in the lower window, run
 >>>
 >>>(set-window-dedicated-p (selected-window) t)
 >>>
 >>>Now, in the upper window, run
 >>>
 >>>(display-buffer "C")
 >>>
 >>>In Emacs 21, this will be the result:
 >>>
 >>>+-------------+
 >>>|      A      |
 >>>+-------------+
 >>>|      C      |
 >>>+-------------+
 >>>|             |
 >>>|      B      |
 >>>|             |
 >>>+-------------+
 >>>
 >>>In Emacs 22, this will be the result:
 >>>
 >>>+-------------+
 >>>|             |
 >>>|      C      |
 >>>|             |
 >>>+-------------+
 >>>|             |
 >>>|      B      |
 >>>|             |
 >>>+-------------+
 >>>
 >>>In Emacs 22 with split-heigh-threshold=10, this will be the result:
 >>>
 >>>+-------------+
 >>>|             |
 >>>|      A      |
 >>>|             |
 >>>+-------------+
 >>>|      B      |
 >>>+-------------+
 >>>|      C      |
 >>>+-------------+
 >>>
 >
 >
 >>What he apparently wants is window B always display the same buffer, stay
 >>below all other windows, and not change its size.
 >
 >
 > I guess I see the following problems:
 > 0 - it's not clear to me why Emacs chooses to split B rather than A.
 >     It seems unrelated to the split-height-threshold fix, so we need to look
 >     into this before being able to determine how best to fix it.

Fget_largest_window returns the largest window and B could be that
window.

 > 1 - since we're in buffer/window A, it would probably be preferable to place
 >     buffer C closer rather than further, so in this case after splitting B
 >     display-buffer should prefer using the top window for C and the bottom
 >     one for B.

With `split-window' the new window is the lower one, we would lose all
associations for B if we did that.


 > 2 - "dedicated" is mostly meant to cause deletion of the buffer to also
 >     cause deletion of the window.  It says nothing about the window having
 >     a fixed size or being non-splittable.

Agreed.

 > 3 - we have window-size-fixed for that.

David: Could you set that for the buffer of your window B and look
whether it gives good results.

 > 4 - we don't have window-(un)splittable for that (there's a frame parameter
 >     to prevent splitting windows in that frame, tho).

Earlier I thought about splitting obey a buffer-local value for
`split-height-threshold'.

Re: display-buffer-change

[Stefan Monnier]

>> I guess I see the following problems:
>> 0 - it's not clear to me why Emacs chooses to split B rather than A.
>> It seems unrelated to the split-height-threshold fix, so we need to look
>> into this before being able to determine how best to fix it.

> Fget_largest_window returns the largest window and B could be that
> window.

So it's not always going to behave this way, it depends on details of the
current layout.  A shift by 1 line can change the result?

>> 1 - since we're in buffer/window A, it would probably be preferable to place
>> buffer C closer rather than further, so in this case after splitting B
>> display-buffer should prefer using the top window for C and the bottom
>> one for B.

> With `split-window' the new window is the lower one, we would lose all
> associations for B if we did that.

I know.  It'a problem.  Independent from the current one.

>> 2 - "dedicated" is mostly meant to cause deletion of the buffer to also
>> cause deletion of the window.  It says nothing about the window having
>> a fixed size or being non-splittable.

> Agreed.

>> 3 - we have window-size-fixed for that.

> David: Could you set that for the buffer of your window B and look
> whether it gives good results.

I don't think that's going to help.  This variable is almost never
used/obeyed :-(

And I don't think it'd help the OP anyway because he doesn't want to go
a configure such things.  And the window shouldn't be fixed-size anyway
(you should still be able to resize it with balance-window, for example).

>> 4 - we don't have window-(un)splittable for that (there's a frame parameter
>> to prevent splitting windows in that frame, tho).

> Earlier I thought about splitting obey a buffer-local value for
> `split-height-threshold'.

That would make a lot of sense.  But I don't think it'd help the OP either
because it's too detailed a configuration.

To get back to the OP's example scenario, starting from 

>>>+-------------+
>>>|             |
>>>|      A      |
>>>|             |
>>>+-------------+
>>>|             |
>>>|      B      |
>>>|             |
>>>+-------------+

Why would

>>>+-------------+
>>>|      A      |
>>>+-------------+
>>>|      C      |
>>>+-------------+
>>>|             |
>>>|      B      |
>>>|             |
>>>+-------------+

be better than

>>>+-------------+
>>>|             |
>>>|      A      |
>>>|             |
>>>+-------------+
>>>|      B      |
>>>+-------------+
>>>|      C      |
>>>+-------------+

and why should it depend on B being dedicated?


        Stefan

Re: display-buffer-change

[martin rudalics]

 >>>0 - it's not clear to me why Emacs chooses to split B rather than A.
 >>>It seems unrelated to the split-height-threshold fix, so we need to look
 >>>into this before being able to determine how best to fix it.
 >
 >
 >>Fget_largest_window returns the largest window and B could be that
 >>window.
 >
 >
 > So it's not always going to behave this way, it depends on details of the
 > current layout.  A shift by 1 line can change the result?

If Fget_largest_window doesn't provide a suitable window Fget_lru_window
kicks in.  Hence we can have all sorts of results.  `display-buffer' is
very stochastic.

 >>>1 - since we're in buffer/window A, it would probably be preferable to place
 >>>buffer C closer rather than further, so in this case after splitting B
 >>>display-buffer should prefer using the top window for C and the bottom
 >>>one for B.
 >
 >
 >>With `split-window' the new window is the lower one, we would lose all
 >>associations for B if we did that.
 >
 >
 > I know.  It'a problem.  Independent from the current one.

It's hardly a problem for the OP.  It's a real pain for me.

 >>>3 - we have window-size-fixed for that.
 >
 >
 >>David: Could you set that for the buffer of your window B and look
 >>whether it gives good results.
 >
 >
 > I don't think that's going to help.  This variable is almost never
 > used/obeyed :-(

I was surprised to find out that it is checked more often than I
thought initially.

 > And I don't think it'd help the OP anyway because he doesn't want to go
 > a configure such things.

Maybe he would.  But it's not useful in general (given the default value
of `split-height-threshold' I don't think people use that either).

 > And the window shouldn't be fixed-size anyway
 > (you should still be able to resize it with balance-window, for example).

100% agreement, but it was your suggestion ;-)

 >>>4 - we don't have window-(un)splittable for that (there's a frame parameter
 >>>to prevent splitting windows in that frame, tho).
 >
 >
 >>Earlier I thought about splitting obey a buffer-local value for
 >>`split-height-threshold'.
 >
 >
 > That would make a lot of sense.  But I don't think it'd help the OP either
 > because it's too detailed a configuration.

The OP would do it.  It's not useful as a general suggestion and it
might be hairy to implement.  Strictly spoken, `display-buffer' would
have to - whenever it tries to split a window - check the buffer-local
value of `split-height-threshold' of the buffer displayed in that window
(or should it be the value of the buffer we want to display?).  Anyway,
just try to convey this in a user manual.

 >
 > To get back to the OP's example scenario, starting from
 >
 >
 >>>>+-------------+
 >>>>|             |
 >>>>|      A      |
 >>>>|             |
 >>>>+-------------+
 >>>>|             |
 >>>>|      B      |
 >>>>|             |
 >>>>+-------------+
 >
 >
 > Why would
 >
 >
 >>>>+-------------+
 >>>>|      A      |
 >>>>+-------------+
 >>>>|      C      |
 >>>>+-------------+
 >>>>|             |
 >>>>|      B      |
 >>>>|             |
 >>>>+-------------+
 >
 >
 > be better than
 >
 >
 >>>>+-------------+
 >>>>|             |
 >>>>|      A      |
 >>>>|             |
 >>>>+-------------+
 >>>>|      B      |
 >>>>+-------------+
 >>>>|      C      |
 >>>>+-------------+
 >
 >
 > and why should it depend on B being dedicated?

I can only speculate: B is my fixed point for compiling, tracing,
debugging, observing or controlling the world.  It's the area of the
screen I'm looking first when I run into troubles.  I don't want it to
change size or position because I wouldn't find it at its usual place in
the shape I got used to.

More likely it's because the OP got used to the A / C / B behavior over
the years.  Maybe he can tell us more.

Re: display-buffer-change

[David Kågedal]

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

martin rudalics <rudalics@gmx.at> writes:

>> To get back to the OP's example scenario, starting from
>>
>>
>>>>>+-------------+
>>>>>|             |
>>>>>|      A      |
>>>>>|             |
>>>>>+-------------+
>>>>>|             |
>>>>>|      B      |
>>>>>|             |
>>>>>+-------------+
>>
>>
>> Why would
>>
>>
>>>>>+-------------+
>>>>>|      A      |
>>>>>+-------------+
>>>>>|      C      |
>>>>>+-------------+
>>>>>|             |
>>>>>|      B      |
>>>>>|             |
>>>>>+-------------+
>>
>>
>> be better than
>>
>>
>>>>>+-------------+
>>>>>|             |
>>>>>|      A      |
>>>>>|             |
>>>>>+-------------+
>>>>>|      B      |
>>>>>+-------------+
>>>>>|      C      |
>>>>>+-------------+
>>
>>
>> and why should it depend on B being dedicated?
>
> I can only speculate: B is my fixed point for compiling, tracing,
> debugging, observing or controlling the world.  It's the area of the
> screen I'm looking first when I run into troubles.  I don't want it to
> change size or position because I wouldn't find it at its usual place in
> the shape I got used to.
>
> More likely it's because the OP got used to the A / C / B behavior over
> the years.  Maybe he can tell us more.

Exactly.  "B" is the "*compilation*" buffer in my case.  I need two
things from the window:

 1) The window should be dedicated to *compilation*

 2) The window should stick at the bottom

The size isn't really important, since I change it frequently anyway.

I agree that window-dedicated-p only promises me the first, but Emacs
21 gave me the second and Emacs 22 doesn't.  This make Emacs 22 less
useful and I reported the problem.

A window-local "unsplittable" flag that I can set could probably help.

I'm attaching the actual code I'm using, although the simple test case
I gave you shows the change.

Put these three files in your load-path and load compile-window.  Then
run a compilation with M-x compile.  You'll get a *compilation* window
that you can resize with "C-c ." which sticks to the bottom and stays
there.


[-- Attachment #2: compile-window.tar --]
[-- Type: application/x-tar, Size: 10240 bytes --]

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


-- 
David Kågedal

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: display-buffer-change

[martin rudalics]

 > A window-local "unsplittable" flag that I can set could probably help.

Consider using something like `window-unsplittable-p': With David's
example, A and B have the same size and B would be unsplittable.  If
`window-unsplittable-p' is _not_ handled by Fget_largest_window the
latter might return B although A would be a perfect alternative.
`display-buffer' would decide that there's no sutiable largest window,
continue with the LRU one, find out that it can't be split either and
stick to some suboptimal solution.  Hence, `get-largest-window' and
`get-lru-window' would need a third, optional "unsplittable" argument.
That argument would be hardly set by anything but `display-buffer'.

I earlier suggested to use `window-dedicated-p' to make the window
unsplittable because this can be handled by the current code of
Fget_largest_window and Fget_lru_window.  I'd simply have
`display-buffer' call these with the second argument Qnil and be done.
Obviously, the semantics of "dedicatedness" would change.

Re: display-buffer-change

[David Kågedal]

martin rudalics <rudalics@gmx.at> writes:

> Stefan Monnier schrieb:
>>>>I must have lost too much context: I do not understand the
>>>>above description.  Can someone spell it out in baby-steps for my poor
>>>>excuse for a brain?
>>
>>
>>>The OP explained it as follows:
>>
>>
>>>>Split an emacs frame in two windows showing buffers A and B:
>>>>
>>>>+-------------+
>>>>|             |
>>>>|      A      |
>>>>|             |
>>>>+-------------+
>>>>|             |
>>>>|      B      |
>>>>|             |
>>>>+-------------+
>>>>
>>>>While in the lower window, run
>>>>
>>>>(set-window-dedicated-p (selected-window) t)
>>>>
>>>>Now, in the upper window, run
>>>>
>>>>(display-buffer "C")
>>>>
>>>>In Emacs 21, this will be the result:
>>>>
>>>>+-------------+
>>>>|      A      |
>>>>+-------------+
>>>>|      C      |
>>>>+-------------+
>>>>|             |
>>>>|      B      |
>>>>|             |
>>>>+-------------+

Actually, I think that the size of B is diminished somewhat sometimes.

>>>>In Emacs 22, this will be the result:
>>>>
>>>>+-------------+
>>>>|             |
>>>>|      C      |
>>>>|             |
>>>>+-------------+
>>>>|             |
>>>>|      B      |
>>>>|             |
>>>>+-------------+
>>>>
>>>>In Emacs 22 with split-heigh-threshold=10, this will be the result:
>>>>
>>>>+-------------+
>>>>|             |
>>>>|      A      |
>>>>|             |
>>>>+-------------+
>>>>|      B      |
>>>>+-------------+
>>>>|      C      |
>>>>+-------------+
>>>>
>>
>>
>>>What he apparently wants is window B always display the same buffer, stay
>>>below all other windows, and not change its size.
>>
>>
>> I guess I see the following problems:
>> 0 - it's not clear to me why Emacs chooses to split B rather than A.
>>     It seems unrelated to the split-height-threshold fix, so we need to look
>>     into this before being able to determine how best to fix it.
>
> Fget_largest_window returns the largest window and B could be that
> window.
>
>> 1 - since we're in buffer/window A, it would probably be preferable to place
>>     buffer C closer rather than further, so in this case after splitting B
>>     display-buffer should prefer using the top window for C and the bottom
>>     one for B.
>
> With `split-window' the new window is the lower one, we would lose all
> associations for B if we did that.
>
>
>> 2 - "dedicated" is mostly meant to cause deletion of the buffer to also
>>     cause deletion of the window.  It says nothing about the window having
>>     a fixed size or being non-splittable.
>
> Agreed.

Having a fixed size is not important for me.  The most important
property for me is that it remains being fixed at the bottom of the
frame.  This seemed to hold in Emacs 21, which made me happy. But it
might have been unintended.

>> 3 - we have window-size-fixed for that.
>
> David: Could you set that for the buffer of your window B and look
> whether it gives good results.

No, it gives me an error: "Attempt to split fixed-size window".

I think the (short) instructions at the top should be enough for you
to reproduce it as well.

>> 4 - we don't have window-(un)splittable for that (there's a frame parameter
>>     to prevent splitting windows in that frame, tho).
>
> Earlier I thought about splitting obey a buffer-local value for
> `split-height-threshold'.
>

-- 
David Kågedal

Re: display-buffer-change

[martin rudalics]

 > Having a fixed size is not important for me.  The most important
 > property for me is that it remains being fixed at the bottom of the
 > frame.  This seemed to hold in Emacs 21, which made me happy. But it
 > might have been unintended.
 >
 >
 >>>3 - we have window-size-fixed for that.
 >>
 >>David: Could you set that for the buffer of your window B and look
 >>whether it gives good results.
 >
 >
 > No, it gives me an error: "Attempt to split fixed-size window".
 >
 > I think the (short) instructions at the top should be enough for you
 > to reproduce it as well.

Well I thought together with something like

(setq split-height-threshold 5)

Anyway, this violates the doc-string of `window-size-fixed'

  Emacs won't change the size of any window displaying that buffer,
  unless you explicitly change the size, or Emacs has no other choice.

and I just noted a similar "Window is not resizable" bug with
`temp-buffer-resize-mode'.

Re: bug of display-table & make-glyph-code

[Richard Stallman]

    I suggested to have `display-buffer' not split dedicated windows
    (unless there's just one) which should fix his problem.

Whether or not there is a bug, that sounds like a good feature: don't
split a dedicated window if there is another convenient alternative.
Please try it out.

Re: bug of display-table & make-glyph-code

[Richard Stallman]

    It's not on any list. The only extant Emacs 22 bugs seem to be:

    eshell external commands
    KDE maximization
    getopts_long and etags?
    static locals and HPUX?

If those are the ones in FOR-RELEASE, I think there are 
others not in that file.  I put them info FOR-RELEASE when I send the third
message about a bug.  Maybe Martin Rudalics puts them in
after the second message.

Probably those are all the ones for which I have made several reminders.

Re: bug of display-table & make-glyph-code

[Glenn Morris]

Richard Stallman wrote:

> If those are the ones in FOR-RELEASE, I think there are others not
> in that file.

No, those are not just the ones in F-R, but all the ones I'm aware of
that don't yet have solutions.

> Probably those are all the ones for which I have made several reminders.

Thanks for the vote of confidence. ;)

Re: bug of display-table & make-glyph-code

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     > Can someone reproduce the OP's behavior with Emacs 22 ?
>
>     Neither with Emacs 22 nor the current CVS trunk.
>
> If we cannot make it fail, we can cross it off the list.
> Would you please?

The problem is related to the way we encode face numbers in
glyph codes (as an integer).

The number of bits left over in a glyph code for the face number
is vastly reduced on the unicode-2 branch, so as soon as we
merge that to the trunk, the problem will certainly be
visible on trunk.

The solution is to find some other way to merge a face with a
char-code to make a glyph code.  We have discussed this some
time ago.

One suggestion was to use a cons (CHAR . FACE_ID).

Hiding such details was the main rationale for introducting the
make-glyph-code function in 22.1

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: bug of display-table & make-glyph-code

[martin rudalics]

 > The problem is related to the way we encode face numbers in
 > glyph codes (as an integer).
 >
 > The number of bits left over in a glyph code for the face number
 > is vastly reduced on the unicode-2 branch, so as soon as we
 > merge that to the trunk, the problem will certainly be
 > visible on trunk.
 >
 > The solution is to find some other way to merge a face with a
 > char-code to make a glyph code.  We have discussed this some
 > time ago.
 >
 > One suggestion was to use a cons (CHAR . FACE_ID).
 >
 > Hiding such details was the main rationale for introducting the
 > make-glyph-code function in 22.1

We should make sure that this is resolved before merging in the Unicode
branch.  What would you suggest to do?

Re: bug of display-table & make-glyph-code

[Kim F. Storm]

martin rudalics <rudalics@gmx.at> writes:

> We should make sure that this is resolved before merging in the Unicode
> branch.  What would you suggest to do?

IMO it can wait until unicode is merged.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: bug of display-table & make-glyph-code

[Kenichi Handa]

In article <87bqch1nhz.fsf@kfs-lx.testafd.dk>, storm@cua.dk (Kim F. Storm) writes:

> Richard Stallman <rms@gnu.org> writes:
> >     > Can someone reproduce the OP's behavior with Emacs 22 ?
> >
> >     Neither with Emacs 22 nor the current CVS trunk.
> >
> > If we cannot make it fail, we can cross it off the list.
> > Would you please?

> The problem is related to the way we encode face numbers in
> glyph codes (as an integer).

> The number of bits left over in a glyph code for the face number
> is vastly reduced on the unicode-2 branch, so as soon as we
> merge that to the trunk, the problem will certainly be
> visible on trunk.

> The solution is to find some other way to merge a face with a
> char-code to make a glyph code.  We have discussed this some
> time ago.

> One suggestion was to use a cons (CHAR . FACE_ID).

I started to study the glyph related codes, and ran into the
function create-glyph (disp-table.el).  It is a strange
function,q and I don't understand how to utilize it.  Could
someone please explain it?

---
Kenichi Handa
handa@m17n.org

Re: bug of display-table & make-glyph-code

[Eli Zaretskii]

> From: Kenichi Handa <handa@m17n.org>
> Date: Fri, 07 Sep 2007 14:11:35 +0900
> Cc: rgm@gnu.org, zslevin@gmail.com, rms@gnu.org, rudalics@gmx.at,
> 	emacs-devel@gnu.org
> 
> I started to study the glyph related codes, and ran into the
> function create-glyph (disp-table.el).  It is a strange
> function, and I don't understand how to utilize it.  Could
> someone please explain it?

I'm not sure what is there to explain, since the code looks quite
self-explanatory, if read in together with the "Glyphs" node in the
ELisp manual.  Perhaps I'm missing something; if the below doesn't
help, please ask specific questions.

`create-glyph' is used on a character terminal to create a glyph that
is displayed instead of some character C.  The way you use it is like
this:

  (aset standard-display-table c
	(vector (create-glyph (concat "\e(0" (char-to-string gc) "\e(B")))))

This sets up the slot for C in standard-display-table to send to the
terminal the string `(concat "\e(0" (char-to-string gc) "\e(B")))'
(where GC is a code of some other character).

standard-display-table needs an integer code of a glyph to put in the
slot used to display C.  Therefore, `create-glyph' returns such an
integer, which is an index into a glyph table.  In the glyph table,
the first 256 slots are left unused, to avoid affecting the ASCII and
unibyte non-ASCII ranges.  Starting from entry #256 (zero-based),
`create-glyph' adds a new entry for its argument (which is a string to
be sent to the terminal when a specific character is displayed), and
stores that string argument in glyph-table.

Thereafter, when character C is to be displayed, Emacs will look it up
in standard-display-table and see that its slot has a glyph index.
Emacs will then look up that index's slot in glyph-table, fetch the
string stored at that slot, and send the string to the terminal.
Presumably, the string uses character terminal escape sequences to
produce the desired effect, such as underlining the character etc.

Did I manage to answer your question?

Re: bug of display-table & make-glyph-code

[Kenichi Handa]

In article <uabryuaju.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> > From: Kenichi Handa <handa@m17n.org>
> > Date: Fri, 07 Sep 2007 14:11:35 +0900
> > Cc: rgm@gnu.org, zslevin@gmail.com, rms@gnu.org, rudalics@gmx.at,
> > 	emacs-devel@gnu.org
> > 
> > I started to study the glyph related codes, and ran into the
> > function create-glyph (disp-table.el).  It is a strange
> > function, and I don't understand how to utilize it.  Could
> > someone please explain it?

> I'm not sure what is there to explain, since the code looks quite
> self-explanatory, if read in together with the "Glyphs" node in the
> ELisp manual.  Perhaps I'm missing something; if the below doesn't
> help, please ask specific questions.

Thank you very much for the detailed explanation.  That is
exactly what I just understood from the code.

But, then, it seems that the design is broken (or got broken
because of introduction of multibyte characters).  It grows
glyph-table one by one.  So, at some point a glyph code is
simply a character code, but after several calls of
create-glyph, that same glyph code becomes an index into
glyph-table, and is displayed differently.  That means that
we can't reliably store a vector of non-ASCII characters (>=
U+100) in a slot of display-table.

In addition, the docstring of buffer-display-table says that
each element is a vector of characters (or nil).  It doesn't
say that contents of the vector is actually regarded as a
glyph code.

The Glyphs node of info says this:

----------------------------------------------------------------------
   A glyph is represented in Lisp as a "glyph code".  A glyph code can
be "simple" or it can be defined by the "glyph table".  A simple glyph
code is just a way of specifying a character and a face to output it
in.  *Note Faces::.

   The following functions are used to manipulate simple glyph codes:

 -- Function: make-glyph-code char &optional face
     This function returns a simple glyph code representing char CHAR
     with face FACE.
----------------------------------------------------------------------

But, for instance, the return value of (make-glyph-code 256)
is a simple glyph or not depending on the current length of
glyph-table.

---
Kenichi Handa
handa@m17n.org

> `create-glyph' is used on a character terminal to create a glyph that
> is displayed instead of some character C.  The way you use it is like
> this:

>   (aset standard-display-table c
> 	(vector (create-glyph (concat "\e(0" (char-to-string gc) "\e(B")))))

> This sets up the slot for C in standard-display-table to send to the
> terminal the string `(concat "\e(0" (char-to-string gc) "\e(B")))'
> (where GC is a code of some other character).

> standard-display-table needs an integer code of a glyph to put in the
> slot used to display C.  Therefore, `create-glyph' returns such an
> integer, which is an index into a glyph table.  In the glyph table,
> the first 256 slots are left unused, to avoid affecting the ASCII and
> unibyte non-ASCII ranges.  Starting from entry #256 (zero-based),
> `create-glyph' adds a new entry for its argument (which is a string to
> be sent to the terminal when a specific character is displayed), and
> stores that string argument in glyph-table.

> Thereafter, when character C is to be displayed, Emacs will look it up
> in standard-display-table and see that its slot has a glyph index.
> Emacs will then look up that index's slot in glyph-table, fetch the
> string stored at that slot, and send the string to the terminal.
> Presumably, the string uses character terminal escape sequences to
> produce the desired effect, such as underlining the character etc.

> Did I manage to answer your question?


> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: bug of display-table & make-glyph-code

[Eli Zaretskii]

> From: Kenichi Handa <handa@m17n.org>
> CC: zslevin@gmail.com, emacs-devel@gnu.org
> Date: Fri, 07 Sep 2007 21:25:41 +0900
> 
> But, then, it seems that the design is broken (or got broken
> because of introduction of multibyte characters).

It quite possibly is.  disp-table.el was introduced before multibyte
characters, and most commands in it should not be used in multibyte
buffers, as they assume unibyte characters.

We know for a long time that glyph codes and glyph tables should be
redesigned.  Specifying a face by high-order bits of a character code
is an ugly kludge.

Re: bug of display-table & make-glyph-code

[Richard Stallman]

    But, then, it seems that the design is broken (or got broken
    because of introduction of multibyte characters).  It grows
    glyph-table one by one.  So, at some point a glyph code is
    simply a character code, but after several calls of
    create-glyph, that same glyph code becomes an index into
    glyph-table, and is displayed differently.

Those codes are meaningless as characters.  They start at 256.
Meaningful Mule characters codes are much larger.

If you were to define thousands of glyph codes, you might get into the
range of meaningful Mule characters.  Then indeed things would break.
So there is a bug, in that this could happen.  But it is not the case
that all use of create-glyph is broken.

I am not sure whether create-glyph is very useful nowadays.
Maybe it is obsolete, due to Mule.  Who still ses it
and why does he use it?

    But, for instance, the return value of (make-glyph-code 256)
    is a simple glyph or not depending on the current length of
    glyph-table.

Code 256 is useful only if you have defined it as an entry in
the glyph table.

Re: bug of display-table & make-glyph-code

[Kenichi Handa]

In article <E1ITuJE-00036K-BZ@fencepost.gnu.org>, Richard Stallman <rms@gnu.org> writes:

>     But, then, it seems that the design is broken (or got broken
>     because of introduction of multibyte characters).  It grows
>     glyph-table one by one.  So, at some point a glyph code is
>     simply a character code, but after several calls of
>     create-glyph, that same glyph code becomes an index into
>     glyph-table, and is displayed differently.

> Those codes are meaningless as characters.  They start at 256.
> Meaningful Mule characters codes are much larger.

The current problem is with emacs-unicode-2, and in it, 256
is a valid Unicode character codes for U+0100 (LATIN CAPITAL
LETTER A WITH MACRON).

> If you were to define thousands of glyph codes, you might get into the
> range of meaningful Mule characters.  Then indeed things would break.
> So there is a bug, in that this could happen.  But it is not the case
> that all use of create-glyph is broken.

> I am not sure whether create-glyph is very useful nowadays.
> Maybe it is obsolete, due to Mule.  Who still ses it
> and why does he use it?

I want to know that too.

---
Kenichi Handa
handa@m17n.org

Re: bug of display-table & make-glyph-code

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Sat, 08 Sep 2007 03:00:48 -0400
> Cc: eliz@gnu.org, zslevin@gmail.com, emacs-devel@gnu.org
> 
> I am not sure whether create-glyph is very useful nowadays.
> Maybe it is obsolete, due to Mule.

Not only due to Mule, but also because we now support faces on
character terminals.

Re: bug of display-table & make-glyph-code

[Richard Stallman]

    I started to study the glyph related codes, and ran into the
    function create-glyph (disp-table.el).  It is a strange
    function,q and I don't understand how to utilize it.  Could
    someone please explain it?

This is meant for text terminals.  The idea is that you know
a sequence to send to the terminal to display a certain glyph.
You call create-glyph to allocate a glyph code to represent that
glyph.  Redisplay will display that glyph by sending the sequence.

Does that clear it up?

Re: bug of display-table & make-glyph-code

[Richard Stallman]

    The number of bits left over in a glyph code for the face number
    is vastly reduced on the unicode-2 branch, so as soon as we
    merge that to the trunk, the problem will certainly be
    visible on trunk.

    The solution is to find some other way to merge a face with a
    char-code to make a glyph code.  We have discussed this some
    time ago.

I asked Handa if he could please work on this
in unicode-2.

Re: bug of display-table & make-glyph-code

[Kenichi Handa]

In article <E1IUXpV-00077c-2d@fencepost.gnu.org>, Richard Stallman <rms@gnu.org> writes:

>     The number of bits left over in a glyph code for the face number
>     is vastly reduced on the unicode-2 branch, so as soon as we
>     merge that to the trunk, the problem will certainly be
>     visible on trunk.

>     The solution is to find some other way to merge a face with a
>     char-code to make a glyph code.  We have discussed this some
>     time ago.

> I asked Handa if he could please work on this
> in unicode-2.

I'll work on it.

I think we anyway need some backward imcompatible change,
and require rewriting of old codes that utilize glyph-table.
And, if so, it seems that deleting glyph-table (and
create-glyph) is the easiet solution.

Shall I go ahead along that line?

---
Kenichi Handa
handa@m17n.org

Re: bug of display-table & make-glyph-code

[Stefan Monnier]

>> The number of bits left over in a glyph code for the face number
>> is vastly reduced on the unicode-2 branch, so as soon as we
>> merge that to the trunk, the problem will certainly be
>> visible on trunk.

>> The solution is to find some other way to merge a face with a
>> char-code to make a glyph code.  We have discussed this some
>> time ago.

>> I asked Handa if he could please work on this
>> in unicode-2.

> I'll work on it.

> I think we anyway need some backward imcompatible change,
> and require rewriting of old codes that utilize glyph-table.
> And, if so, it seems that deleting glyph-table (and
> create-glyph) is the easiet solution.

> Shall I go ahead along that line?

Grepping Emacs's source code and Googling emacswiki shows the following uses of
glyph-create:
- in disp-table: standard-display-g1, standard-display-graphic,
  standard-display-underline.  The last one is probably better off using
  make-glyph-code.  I don't know how to mimck the other two using
  other features.  But neither do I know why anybody would want to
  use those.  It seems that using the utf-8 encoding in current xterms
  makes those hacks completely useless.
  `standard-display-g1' seems to only be used in obsolete/iso-swed.el
  (and maybe in W3).  `standard-display-graphic' seems not to be
  used anywhere.
- in some Gnus threading display hack which also would be better off using
  make-glyph-code (http://www.emacswiki.org/cgi-bin/emacs/GnusFormatting).

So I think we can just drop this feature altogether.


        Stefan

Re: bug of display-table & make-glyph-code

[Kenichi Handa]

In article <jwvabrv9ixx.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes:

> > I think we anyway need some backward imcompatible change,
> > and require rewriting of old codes that utilize glyph-table.
> > And, if so, it seems that deleting glyph-table (and
> > create-glyph) is the easiet solution.

> > Shall I go ahead along that line?

> Grepping Emacs's source code and Googling emacswiki shows the following uses of
> glyph-create:
> - in disp-table: standard-display-g1, standard-display-graphic,
>   standard-display-underline.  The last one is probably better off using
>   make-glyph-code.  I don't know how to mimck the other two using
>   other features.  But neither do I know why anybody would want to
>   use those.  It seems that using the utf-8 encoding in current xterms
>   makes those hacks completely useless.
>   `standard-display-g1' seems to only be used in obsolete/iso-swed.el
>   (and maybe in W3).  `standard-display-graphic' seems not to be
>   used anywhere.
> - in some Gnus threading display hack which also would be better off using
>   make-glyph-code (http://www.emacswiki.org/cgi-bin/emacs/GnusFormatting).

> So I think we can just drop this feature altogether.

Thank you for investigating that.  Are there any objections
to dropping them?

---
Kenichi Handa
handa@m17n.org

Re: bug of display-table & make-glyph-code

[Kim F. Storm]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> So I think we can just drop this feature altogether.

Isn't it used if you want to put a face on e.g. the vertical window
separator on a text terminal (or if you have no scroll-bars).

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: bug of display-table & make-glyph-code

[Leo]

On 2007-09-10 12:51 +0100, Kim F. Storm wrote:
> Isn't it used if you want to put a face on e.g. the vertical window
> separator on a text terminal (or if you have no scroll-bars).

While we are on this topic, how to configure the vertical separator for
emacs running in text terminal? For example, I want to change "|" to
":".

Thanks,
-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .:  [ GPG Key: 9283AA3F ]  :.

=>             "(require 'cl) considered harmful" considered harmful
=>           http://dto.freeshell.org/blog/blog-2007-09-07-2323.html

Re: bug of display-table & make-glyph-code

[Stefan Monnier]

>> So I think we can just drop this feature altogether.
> Isn't it used if you want to put a face on e.g. the vertical window
> separator on a text terminal (or if you have no scroll-bars).

No: the feature I'm talking about is linked to `create-glyph', whereas the
one you're talking about is linked to `make-glyph-code'.


        Stefan

Re: bug of display-table & make-glyph-code

[Richard Stallman]

    Isn't it used if you want to put a face on e.g. the vertical window
    separator on a text terminal (or if you have no scroll-bars).

I don't think create-glyph was ever used for that.
You could use make-glyph-code, but that's different.

Re: bug of display-table & make-glyph-code

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     Isn't it used if you want to put a face on e.g. the vertical window
>     separator on a text terminal (or if you have no scroll-bars).
>
> I don't think create-glyph was ever used for that.
> You could use make-glyph-code, but that's different.

You are right - I confused the two issues (make-glyph-code also need
to be updated for unicode.)

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: bug of display-table & make-glyph-code

[Eli Zaretskii]

> From: Kenichi Handa <handa@m17n.org>
> Date: Mon, 10 Sep 2007 13:15:19 +0900
> 
> And, if so, it seems that deleting glyph-table (and
> create-glyph) is the easiet solution.
> 
> Shall I go ahead along that line?

If after deleting them one can still set up the display table to send
a string when a certain character needs to be displayed, I'm okay with
that change.  (Just don't forget to mention it in NEWS.)

Re: bug of display-table & make-glyph-code

[Kenichi Handa]

In article <u4pi2qpgk.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> > From: Kenichi Handa <handa@m17n.org>
> > Date: Mon, 10 Sep 2007 13:15:19 +0900
> > 
> > And, if so, it seems that deleting glyph-table (and
> > create-glyph) is the easiet solution.
> > 
> > Shall I go ahead along that line?

> If after deleting them one can still set up the display table to send
> a string when a certain character needs to be displayed, I'm okay with
> that change.  (Just don't forget to mention it in NEWS.)

I think we can allow one to store a unibyte-string directly
in the display table for that purpose.

---
Kenichi Handa
handa@m17n.org

Re: bug of display-table & make-glyph-code

[Richard Stallman]

    > If after deleting them one can still set up the display table to send
    > a string when a certain character needs to be displayed, I'm okay with
    > that change.  (Just don't forget to mention it in NEWS.)

    I think we can allow one to store a unibyte-string directly
    in the display table for that purpose.

It looks like this is possible; it does not conflict with the other
uses of the display table.  However, why does one want to do this
nowadays?

Re: bug of display-table & make-glyph-code

[Richard Stallman]

    If after deleting them one can still set up the display table to send
    a string when a certain character needs to be displayed, I'm okay with
    that change.

create-glyph is the feature used for that.  We're thinking of deleting
create-glyph because the feature seems to be obsolete and not really
useful or used.

Do you use that feature?  If so, what do you use it for?


As a separate feature, you can use display-table to display a
character code as a series of glyphs.  But each of those glyphs
is supposed to occupy one space on the screen.  But if you want
to send a series of characters to display one glyph, the way
you do that is with create-glyph.

Re: bug of display-table & make-glyph-code

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: handa@m17n.org, emacs-devel@gnu.org
> Date: Tue, 11 Sep 2007 16:31:12 -0400
> 
>     If after deleting them one can still set up the display table to send
>     a string when a certain character needs to be displayed, I'm okay with
>     that change.
> 
> create-glyph is the feature used for that.
> Do you use that feature?  If so, what do you use it for?

term/internal.el uses multi-character glyphs to display characters
that are not supported by the available character set.  But it doesn't
use create-glyph, it sets up display-table so that some characters are
displayed as strings of other characters.

> As a separate feature, you can use display-table to display a
> character code as a series of glyphs.  But each of those glyphs
> is supposed to occupy one space on the screen.

It works as expected even if they occupy more than one screen space.

So I think create-glyph is not important for internal.el.

Re: bug of display-table & make-glyph-code

[Richard Stallman]

    term/internal.el uses multi-character glyphs to display characters
    that are not supported by the available character set.  But it doesn't
    use create-glyph, it sets up display-table so that some characters are
    displayed as strings of other characters.

That is a different feature.  It has nothing to do with create-glyph.

    > As a separate feature, you can use display-table to display a
    > character code as a series of glyphs.  But each of those glyphs
    > is supposed to occupy one space on the screen.

    It works as expected even if they occupy more than one screen space.

I think that is a misunderstanding.  The sequence of glyphs will
naturally use up more than one screen space, but on a tty
each glyph is supposed to use just one, right?

But that detail is not crucial.

    So I think create-glyph is not important for internal.el.

Correct.

Re: bug of display-table & make-glyph-code

[Richard Stallman]

    I think we anyway need some backward imcompatible change,
    and require rewriting of old codes that utilize glyph-table.
    And, if so, it seems that deleting glyph-table (and
    create-glyph) is the easiet solution.

It is surely the easiest.  The question is whether the glyph table
feature is still useful.

Based on Stefan's info, I think we can delete it.  Thanks, Stefan, for
investigating.

RE: bug of display-table & make-glyph-code

[Drew Adams]

>     I think we anyway need some backward imcompatible change,
>     and require rewriting of old codes that utilize glyph-table.
>     And, if so, it seems that deleting glyph-table (and
>     create-glyph) is the easiet solution.
>
> It is surely the easiest.  The question is whether the glyph table
> feature is still useful.
>
> Based on Stefan's info, I think we can delete it.  Thanks, Stefan, for
> investigating.

I haven't followed all of this. I grepped my code for glyph-table and
create-glyph, and I don't use them.

However, I do use what is essentially Kim's `make-glyph-code' (which I
thought was going to be added to Emacs for version 23), so I hope glyphs are
not being removed altogether. (I use `make-glyph-code' to provide
replacement text for "^L" for inserted form-feed chars.)

Re: bug of display-table & make-glyph-code

[Kenichi Handa]

In article <BNELLINCGFJLDJIKDGACEEHOCCAA.drew.adams@oracle.com>, "Drew Adams" <drew.adams@oracle.com> writes:

> However, I do use what is essentially Kim's `make-glyph-code' (which I
> thought was going to be added to Emacs for version 23), so I hope glyphs are
> not being removed altogether. (I use `make-glyph-code' to provide
> replacement text for "^L" for inserted form-feed chars.)

I don't intend to delete the concept of "glyph".  I'm just
going to change the Lispy representation of "glyph" from
integer to something like (CHAR . FACE-ID).  But if we do
that, we can't keep backward compatibility about
glyph-table.  So I suggest to delete it if not that useful
now.

---
Kenichi Handa
handa@m17n.org

RE: bug of display-table & make-glyph-code

[Drew Adams]

> > However, I do use what is essentially Kim's `make-glyph-code' (which I
> > thought was going to be added to Emacs for version 23), so I
> hope glyphs are
> > not being removed altogether. (I use `make-glyph-code' to provide
> > replacement text for "^L" for inserted form-feed chars.)
>
> I don't intend to delete the concept of "glyph".  I'm just
> going to change the Lispy representation of "glyph" from
> integer to something like (CHAR . FACE-ID).  But if we do
> that, we can't keep backward compatibility about
> glyph-table.  So I suggest to delete it if not that useful
> now.

Hmm. It sounds like that change would necessitate a change to Kim's
function. Since I use his definition without really understanding it ;-), I
would appreciate a version that will work after your changes. And I'd like
to know what I can test in my code to know which version to use (for use
with different Emacs versions).

Here is the definition I am using now (Emacs 22.1):

(defun make-glyph-code (char &optional face)
  "Return a glyph code representing char CHAR with face FACE."
  (if face
      (logior char (lsh (face-id face)
                        (if (<= emacs-major-version 22) 19 22)))
    char))

Thanks.

Re: bug of display-table & make-glyph-code

[Richard Stallman]

He says this fails in the latest unicode-2 sources.
Would you please DTRT?

Would someone please DTRT and ack?

From: levin <zslevin@gmail.com>
To: emacs-devel@gnu.org
Date: Mon, 27 Aug 2007 17:32:22 +0800
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain;
  charset="gb18030"
Subject: bug of display-table & make-glyph-code

To reinvent this bug, please follow:

1. Please save the text below as glyph.org, visit it, and `M-x org-mode' to 
turn on org mode. 

2. Keep the first headline collapsed by pressing TAB (if neccessary) on it.

3. you can expand the second/third headline by press TAB on it.

4. eval the lisp code in the second headline, this CANNOT change "..." 
display.

5. eval the lisp code in the third headline, this CAN change "..." display.

I find out that if make-glyph-code returns a negative int, then the 
display table does not take effect on "..." display.

--------8<-------------8<--------
* Please keep me collapsed by pressing TAB (if neccessary)
some info to hide

* please eval me, this CANNOT change "..." display
(describe-face 'org-warning)

(face-id 'org-warning)  # mine is 77 here

(unless buffer-display-table
  (setq buffer-display-table (make-display-table)))

(set-display-table-slot buffer-display-table 'selective-display
			(vconcat (mapcar
				  (lambda (c)
				    (make-glyph-code c 'org-warning))
				  "...")))

* please eval me, this can change ellipse display 
(describe-face 'tooltip)

(face-id 'tooltip)   # mine is 54 here

(unless buffer-display-table
  (setq buffer-display-table (make-display-table)))

(set-display-table-slot buffer-display-table 'selective-display
			(vconcat (mapcar
				  (lambda (c)
				    (make-glyph-code c 'tooltip))
				  "...")))
--------8<-------------8<--------

My environment:
In GNU Emacs 23.0.0.2 (i686-pc-linux-gnu)
 of 2007-08-27 on MagicLinux
configured using `configure  '--with-x-toolkit=no''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: zh_CN.GB18030
  value of $XMODIFIERS: nil
  locale-coding-system: chinese-gb18030-unix
  default-enable-multibyte-characters: t

Major mode: Org

Minor modes in effect:
  encoded-kbd-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-compression-mode: t
  line-number-mode: t

--
Levin


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel