Error during redisplay

Error during redisplay

[Juanma Barranquero]

emacs -q --eval '(progn (ielm) (pop-to-buffer "*Messages*"))'

=> "Error during redisplay: (error Attempt to modify read-only object)"

             Juanma

Re: Error during redisplay

[Juanma Barranquero]

On Sun, Feb 24, 2008 at 3:56 AM, Juanma Barranquero <lekktu@gmail.com> wrote:

> emacs -q --eval '(progn (ielm) (pop-to-buffer "*Messages*"))'
>
>  => "Error during redisplay: (error Attempt to modify read-only object)"

Seems like a consequence of auto-composition-mode. Adding

  (global-auto-composition-mode -1)

to .emacs fixes the problem. Apparently, pure strings in
mode-line-format don't like to be added auto-composed properties.

             Juanma

Re: Error during redisplay

[Kenichi Handa]

In article <f7ccd24b0802251748v7fa8478aue0ab6d347a8db1f6@mail.gmail.com>, "Juanma Barranquero" <lekktu@gmail.com> writes:

> On Sun, Feb 24, 2008 at 3:56 AM, Juanma Barranquero <lekktu@gmail.com> wrote:
> > emacs -q --eval '(progn (ielm) (pop-to-buffer "*Messages*"))'
> >
> >  => "Error during redisplay: (error Attempt to modify read-only object)"

> Seems like a consequence of auto-composition-mode. Adding

>   (global-auto-composition-mode -1)

> to .emacs fixes the problem. Apparently, pure strings in
> mode-line-format don't like to be added auto-composed properties.

In auto-compose-chars, inhibit-read-only is bound to t while
the code add auto-composed property.  If it's still not
allowed, are there anyway to detect that the string is pure?

---
Kenichi Handa
handa@ni.aist.go.jp

Re: Error during redisplay

[Stefan Monnier]

> In auto-compose-chars, inhibit-read-only is bound to t while
> the code add auto-composed property.  If it's still not
> allowed, are there anyway to detect that the string is pure?

The only way I can think of is to try it and catch the error signalled.


        Stefan

Re: Error during redisplay

[Richard Stallman]

    > to .emacs fixes the problem. Apparently, pure strings in
    > mode-line-format don't like to be added auto-composed properties.

    In auto-compose-chars, inhibit-read-only is bound to t while
    the code add auto-composed property.  If it's still not
    allowed, are there anyway to detect that the string is pure?

There is something not clean about trying to modify a string in
mode-line-format when a user turns on a feature that doesn't intend to
change the mode line.  That seems like a flaw in the design of
something.

The strings in mode-line-format are supposed to be set up correct when
Emacs is dumped.  Should they have these properties, or not?  That is
the first question.

If they SHOULD have these properties, probably we should make sure they have
these properties from the start, or from an early point in building Emacs.

If they SHOULD NOT have these properties, why is anything trying to give
them these properties?

Stefan wrote:

    > In auto-compose-chars, inhibit-read-only is bound to t while
    > the code add auto-composed property.  If it's still not
    > allowed, are there anyway to detect that the string is pure?

    The only way I can think of is to try it and catch the error signalled.

One possible solution is to avoid making those strings pure in the
first place.  But this could be papering over a design flaw, so first
we should look at the questions above.

Re: Error during redisplay

[Kenichi Handa]

In article <E1JU9V5-0001nM-1x@fencepost.gnu.org>, Richard Stallman <rms@gnu.org> writes:

> to .emacs fixes the problem. Apparently, pure strings in
> mode-line-format don't like to be added auto-composed properties.

>     In auto-compose-chars, inhibit-read-only is bound to t while
>     the code add auto-composed property.  If it's still not
>     allowed, are there anyway to detect that the string is pure?

> There is something not clean about trying to modify a string in
> mode-line-format when a user turns on a feature that doesn't intend to
> change the mode line.  That seems like a flaw in the design of
> something.

The current design requires to add `composition' property to
a string to properly display the string if it contains, for
instance, some of Indic characters, and to add
`auto-composed' property to avoid the repeated generation of
`composition' property.

> The strings in mode-line-format are supposed to be set up correct when
> Emacs is dumped.  Should they have these properties, or not?  That is
> the first question.

If mode-line-format has not been modified, I think it
doesn't contain any characters that require composition
(except for the case that we support such ligatures as "Fi"
in the future).  One way is to check if the string contains
any such characters, and if not, avoid any composition
processing.  As the string tends to be short, doing that
check repeatedly will not be that inefficient.

> If they SHOULD have these properties, probably we should make sure they have
> these properties from the start, or from an early point in building Emacs.

That's impossible.  How to compose them depends on which
font to use.

---
Kenichi Handa
handa@ni.aist.go.jp

Error during redisplay

[Bob Rogers]

   From: "Juanma Barranquero" <lekktu@gmail.com>
   Date: Sun, 24 Feb 2008 03:56:36 +0100

   emacs -q --eval '(progn (ielm) (pop-to-buffer "*Messages*"))'

   => "Error during redisplay: (error Attempt to modify read-only object)"

		Juanma

I have a simpler way to reproduce what looks like the same problem:

   1.  emacs -Q

   2.  M-x shell RET

   3.  C-x C-b

It appears that, for the *shell* buffer, mode-line-process is
initialized to ":%s" in "define-derived-mode comint-mode" (comint.el
line 622), and this particular value is what format-mode-line (called
from list-buffers-noselect, buff-menu.el line 751) is complaining about.
But I'm not sure how to debug it further.

					-- Bob Rogers
					   http://rgrjr.dyndns.org/

Re: Error during redisplay

[David Kastrup]

Kenichi Handa <handa@m17n.org> writes:

> The current design requires to add `composition' property to a string
> to properly display the string if it contains, for instance, some of
> Indic characters, and to add `auto-composed' property to avoid the
> repeated generation of `composition' property.
>
>> If they SHOULD have these properties, probably we should make sure they have
>> these properties from the start, or from an early point in building Emacs.
>
> That's impossible.  How to compose them depends on which
> font to use.

Since the same string can be displayed with different fonts
simultaneously, this would look like a fault in the design.  The
composition property/whatever apparently needs to be associated with the
actual display, not just the string.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Error during redisplay

[Kenichi Handa]

In article <85ir0aubo1.fsf@lola.goethe.zz>, David Kastrup <dak@gnu.org> writes:

> Kenichi Handa <handa@m17n.org> writes:
> > The current design requires to add `composition' property to a string
> > to properly display the string if it contains, for instance, some of
> > Indic characters, and to add `auto-composed' property to avoid the
> > repeated generation of `composition' property.
> >
>>> If they SHOULD have these properties, probably we should make sure they have
>>> these properties from the start, or from an early point in building Emacs.
> >
> > That's impossible.  How to compose them depends on which
> > font to use.

> Since the same string can be displayed with different fonts
> simultaneously, this would look like a fault in the design.  The
> composition property/whatever apparently needs to be associated with the
> actual display, not just the string.

In such a case, the composition property is generated each
time.  The same situation happens when you display the same
portion of a buffer in two frames with different fonts.

It may result in a little bit slower redisplay.  If such a
situation happens often and the slowness is so painful,
perhaps the composition property must be an alist of fonts
vs the current value.  It's not that difficult to implement.

By the way, I think the slowness is mainly because the
property generation is done by Lisp code through the
function in composition-function-table and that involves
generating many Lisp objects.  With unicode merge, the
underling actual task of deciding glyphs and positions is
mainly done by C functions of font-backends, and that should
not be that slow.

So, another way is to re-design the current redisplay engine
to generate a composition glyph every time just by calling C
functions.  I think it's an interesting experiment.

---
Kenichi Handa
handa@ni.aist.go.jp

Re: Error during redisplay

[David Kastrup]

Kenichi Handa <handa@m17n.org> writes:

> In article <85ir0aubo1.fsf@lola.goethe.zz>, David Kastrup <dak@gnu.org> writes:
>
>> Since the same string can be displayed with different fonts
>> simultaneously, this would look like a fault in the design.  The
>> composition property/whatever apparently needs to be associated with
>> the actual display, not just the string.
>
> In such a case, the composition property is generated each
> time.  The same situation happens when you display the same
> portion of a buffer in two frames with different fonts.
>
> It may result in a little bit slower redisplay.  If such a
> situation happens often and the slowness is so painful,
> perhaps the composition property must be an alist of fonts
> vs the current value.  It's not that difficult to implement.

I still think it wrong to change the text according to where it is
displayed.  This would appear to call at most for overlays (which can be
window specific and where changing them does not change the underlying
text).  So this sort of information probably belongs in the glyph matrix
or whatever it is called.

As far as I know, text properties are also subject to undo treatment.
It just makes me queasy to think about this.

> So, another way is to re-design the current redisplay engine
> to generate a composition glyph every time just by calling C
> functions.  I think it's an interesting experiment.

Sounds more like "sane" than "an interesting experiment" to me.  But on
the other hand, I have no relevant experience or knowledge whatsoever.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Error during redisplay

[Stefan Monnier]

>> Since the same string can be displayed with different fonts
>> simultaneously, this would look like a fault in the design.  The
>> composition property/whatever apparently needs to be associated with the
>> actual display, not just the string.

> In such a case, the composition property is generated each
> time.  The same situation happens when you display the same
> portion of a buffer in two frames with different fonts.

Hmm.. I'm confused.  The auto-composed property is boolean, so at least
the auto-composition-mode code should only run once and should hence
generate a `composition' property value that does not depend on the
font used.

Maybe what you're saying is that this `composition' property is later
changed by the redisplay code and this can be redone if the same text
gets displayed with another font?

> By the way, I think the slowness is mainly because the

What slowness?

> property generation is done by Lisp code through the
> function in composition-function-table and that involves
> generating many Lisp objects.

By the way, it might be good to replace the composition-function-table
(which is a char-table that maps chars to regexps and then to code) with
a lex-style FSM.  Such a thing would also be useful for syntax-tables to
be able to deal with multi-char lexemes (like "begin" and "end").

> So, another way is to re-design the current redisplay engine
> to generate a composition glyph every time just by calling C
> functions.  I think it's an interesting experiment.

Might be worthwhile as well, tho I have no idea if there's an actual
performance problem to solve here.  Going through elisp is also
convenient: I currently use font-lock in haskell-mode, sml-mode, and
coq-mode to compose things like "->" into "→", but auto-composition-mode
would seem like an even better fit.


        Stefan

Re: Error during redisplay

[Richard Stallman]

    The current design requires to add `composition' property to
    a string to properly display the string if it contains, for
    instance, some of Indic characters, and to add
    `auto-composed' property to avoid the repeated generation of
    `composition' property.

It seems unclean to modify a string just because it gets used for
redisplay.  We do that for fontification, but that's an explicit
add-on feature which is not part of mere correct display of some text.

What happens with a read-only buffer?  Does auto-composition modify
the read-only buffer, or does the text display wrong?

    If mode-line-format has not been modified, I think it
    doesn't contain any characters that require composition
    (except for the case that we support such ligatures as "Fi"
    in the future).  One way is to check if the string contains
    any such characters, and if not, avoid any composition
    processing.  As the string tends to be short, doing that
    check repeatedly will not be that inefficient.

That sounds like a good fix for this case, but it may not fix
the whole problem.

    > If they SHOULD have these properties, probably we should make sure they have
    > these properties from the start, or from an early point in building Emacs.

    That's impossible.  How to compose them depends on which
    font to use.

Does this mean that redisplaying with different fonts
will keep changing the composition properties in one string
back and forth between different values?

Re: Error during redisplay

[Richard Stallman]

    I still think it wrong to change the text according to where it is
    displayed.

I agree -- I get a very bad feeling about that.

    As far as I know, text properties are also subject to undo treatment.

That is another good argument.
     
		This would appear to call at most for overlays 

At present, strings cannot have overlays.  And I am not sure
if overlays are really right for this data; just because text properties
have a bad aspect, that doesn't mean overlays don't.

There could be some other internal cache for this.

It calls for more thought.

> So, another way is to re-design the current redisplay engine
> to generate a composition glyph every time just by calling C
> functions.  I think it's an interesting experiment.

That is cleaner, for sure.  It could also be slower, but how much?

Re: Error during redisplay

[Kenichi Handa]

In article <jwvk5kq2y5p.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> Hmm.. I'm confused.  The auto-composed property is boolean, so at least
> the auto-composition-mode code should only run once and should hence
> generate a `composition' property value that does not depend on the
> font used.

> Maybe what you're saying is that this `composition' property is later
> changed by the redisplay code and this can be redone if the same text
> gets displayed with another font?

Yes.

> > By the way, I think the slowness is mainly because the

> What slowness?

Slowness of calculating composition properties.

> > property generation is done by Lisp code through the
> > function in composition-function-table and that involves
> > generating many Lisp objects.

> By the way, it might be good to replace the composition-function-table
> (which is a char-table that maps chars to regexps and then to code) with
> a lex-style FSM.  Such a thing would also be useful for syntax-tables to
> be able to deal with multi-char lexemes (like "begin" and "end").

Does FSM stands for Finit State Machine?

Currently those regexps are very simple, and just an alist
(((FROM-CHAR . TO-CHAR) FUNC) ...) will work.  But, at the
moment, I'm not sure that such a simple specification works
for all scripts.

> > So, another way is to re-design the current redisplay engine
> > to generate a composition glyph every time just by calling C
> > functions.  I think it's an interesting experiment.

> Might be worthwhile as well, tho I have no idea if there's an actual
> performance problem to solve here.  Going through elisp is also
> convenient: I currently use font-lock in haskell-mode, sml-mode, and
> coq-mode to compose things like "->" into "→", but auto-composition-mode
> would seem like an even better fit.

But, if we can't attach `auto-composed' and `composition'
property to a buffer, the requirement for the speed will be
higher.  We have to do some experiment to check the
performance.

Another idea is to have an alist of
  (FRAME . INTERVAL-FOR-COMPOSITION)
for each buffer.

---
Kenichi Handa
handa@ni.aist.go.jp

Re: Error during redisplay

[Stefan Monnier]

>> Hmm.. I'm confused.  The auto-composed property is boolean, so at least
>> the auto-composition-mode code should only run once and should hence
>> generate a `composition' property value that does not depend on the
>> font used.

>> Maybe what you're saying is that this `composition' property is later
>> changed by the redisplay code and this can be redone if the same text
>> gets displayed with another font?

> Yes.

I see.  So this is not directly related to the auto-composition-mode.
It can appear just as well with composition properties applied manually.

>> > By the way, I think the slowness is mainly because the
>> What slowness?
> Slowness of calculating composition properties.

I'm not sure whether by "calculating composition properties" you're
talking about the work done by auto-composition-mode to add
`composition' text properties where necessary, of the work done by the
redisplay to compile those properties into some other representation
(which I'd propose we call "compilation" of composition properties).

Also, I still don't know what slowness you're talking about: in which
circumstance is it slow?

>> > property generation is done by Lisp code through the
>> > function in composition-function-table and that involves
>> > generating many Lisp objects.

>> By the way, it might be good to replace the composition-function-table
>> (which is a char-table that maps chars to regexps and then to code) with
>> a lex-style FSM.  Such a thing would also be useful for syntax-tables to
>> be able to deal with multi-char lexemes (like "begin" and "end").

> Does FSM stands for Finit State Machine?

Yes, I meant a deterministic finite state automaton (DFA).

> Currently those regexps are very simple, and just an alist
> (((FROM-CHAR . TO-CHAR) FUNC) ...) will work.  But, at the
> moment, I'm not sure that such a simple specification works
> for all scripts.

For my application this won't be sufficient because I do things like map
"lambda" to λ (for example).  Of course, I could just catch "la" and
then use FUNC to do the rest of the matching.

> But, if we can't attach `auto-composed' and `composition' property to
> a buffer, the requirement for the speed will be higher.  We have to do
> some experiment to check the performance.

> Another idea is to have an alist of
>   (FRAME . INTERVAL-FOR-COMPOSITION)
> for each buffer.

Not sure how this would work for strings.


        Stefan