frame-local standard-display-table?

[Mark Plaksin]

The THINGS TO DO section of README.multy-tty contains this:

** standard-display-table should be display-local.
standard-display-european should be display-local.

Would making them frame-local have the same effect? And is frame-local
extra hard or am I just dumb? :)

I've been playing with fancy thread glyphs in Gnus (mainly by trying to
follow http://www.emacswiki.org/cgi-bin/wiki/GnusFormatting). I run 'emacs
-nw' inside of screen and then 'emacsclient' to get an X frame. I finally
managed to get fancy glyphs in the X frame. But once I run
'emacsclient -t', the glyphs are broken in X and I just get question
marks.

I've tried to make standard-display-table frame-local but haven't been able
to make that work.

Ideally, I'd have Gnus using the appropriate line-drawing in X, the
original 'emacs -nw', and in clients created with 'emacsclient -t'. The
whole thing seems unnecessarily hard but maybe I'm just dense! :)

[Noah Friedman]

Post by Mark Plaksin
** standard-display-table should be display-local.
standard-display-european should be display-local.
Would making them frame-local have the same effect? And is frame-local
extra hard or am I just dumb? :)

The display table probably should be shared among all frames on the same
display, but as a practical matter, implementing it by making it
frame-local as new frames are instantiated is the easiest way to do it.
The other alternative, stuffing it in the kboard structure, seems... well,
hackish in a different way but also not as flexible.

I started work on this, and you can see the functions which do the work in
http://www.splode.com/~friedman/software/emacs-lisp/src/frame-fns.el. But
right now that code maintains a display table per window-system type rather
than per display. Since you've brought this up and reminded me I feel some
motivation to fix that now, so I'll try to send in a real patch soon.

Post by Mark Plaksin
I've tried to make standard-display-table frame-local but haven't been able
to make that work.

The other thing that needs to be done is to change the references in the C
code to do lookup through the symbol table instead of using
Vstandard_display_table directly. In fact that variable should probably go
away.

[Mark Plaksin]

Post by Noah Friedman

Post by Mark Plaksin
** standard-display-table should be display-local.
standard-display-european should be display-local.
Would making them frame-local have the same effect? And is frame-local
extra hard or am I just dumb? :)

The display table probably should be shared among all frames on the same
display,

Good point!

Post by Noah Friedman
I started work on this, and you can see the functions which do the work in
http://www.splode.com/~friedman/software/emacs-lisp/src/frame-fns.el. But
right now that code maintains a display table per window-system type rather
than per display. Since you've brought this up and reminded me I feel some
motivation to fix that now, so I'll try to send in a real patch soon.

Wow--thanks! I'm happy to help test.

Post by Noah Friedman

Post by Mark Plaksin
I've tried to make standard-display-table frame-local but haven't been able
to make that work.

The other thing that needs to be done is to change the references in the C
code to do lookup through the symbol table instead of using
Vstandard_display_table directly. In fact that variable should probably go
away.

Ah! This makes me feel less dumb :) Or at least dumb about different
things! I know nothing about the C code Emacs for Emacs.

[Károly Lőrentey]

Post by Noah Friedman

Post by Mark Plaksin
** standard-display-table should be display-local.
standard-display-european should be display-local.
Would making them frame-local have the same effect? And is frame-local
extra hard or am I just dumb? :)

The display table probably should be shared among all frames on the same
display,

I agree. These tables should have individual values on each terminal.

However, I think frames on the same terminal should share their
display tables. Changing standard-display-table on one frame
should affect the others on the same terminal as well.

Post by Noah Friedman
but as a practical matter, implementing it by making it frame-local
as new frames are instantiated is the easiest way to do it.
The other alternative, stuffing it in the kboard structure, seems... well,
hackish in a different way but also not as flexible.

I think if there is a compelling reason to make a built-in variable
terminal-local, then stuffing it in either `struct terminal' or
`struct kboard' is the natural way to go. This is usually not
particularly hard to implement, and these structs are the natural
places to collect such variables.

In this particular case, `struct terminal' seems the best place to put
these tables. However, this would make these tables inaccessible from
Lisp code (unless a DEFVAR_TERMINAL is written). Using `struct
kboard' would be a functionally equivalent solution without this
defect, although it would indeed be a hack.

Considering that buffers and even windows may have their own display
tables, I think we may even decide to keep standard-display-table
global, and introduce a new terminal-local variant instead (with
accessor functions similar to `window-display-table'). However,
existing packages that use standard-display-table would then remain
broken with multi-tty.

I dislike simply converting standard-display-table to a frame-local
variable, but that may well turn out to be the best approach. (I find
it confusing for frames to have shared parameters. We already have
two of those ('client and 'environment) and I would rather not add a
third.)

In summary, all approaches to solve the problem have some defect. I
am yet undecided which way to follow.

Post by Noah Friedman
I started work on this, and you can see the functions which do the work in
http://www.splode.com/~friedman/software/emacs-lisp/src/frame-fns.el.

Excellent; I'll check this out when I get online.