bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#64696: 30.0.50; indent-to inherits preceding text properties, includ


From: Stefan Monnier
Subject: bug#64696: 30.0.50; indent-to inherits preceding text properties, including 'invisible
Date: Thu, 27 Jul 2023 22:53:53 -0400
User-agent: Gnus/5.13 (Gnus v5.13)

> For example, consider an Org table like
>
> | *This* | is | some text |
> | more |    |  text     |
>
> It looks aligned in Org buffers ("*" is invisible),

I just tried it in a vanilla Emacs-28 and "*" is not made invisible,
because `org-hide-emphasis-markers` defaults to nil.

> but not when copied to message buffer.

I think what you really want is that the above table be properly aligned
regardless of the value of `org-hide-emphasis-markers` and without
changing the buffer's char contents when changing the value of
`org-hide-emphasis-markers`, and I don't think you can do that without
adding `display` space properties dynamically in accordance with the
current value of `org-hide-emphasis-markers`.

Presumably you'll also want to keep columns aligned dynamically as text
is inserted/deleted.  I suspect that once you try to do that, it's
fairly easy to temporarily let-bind `buffer-invisibility-spec` around
the code that inserts SPCs&TABs to enforce the "vanilla" alignment.

Also enforcing this property that the text will be aligned both while
prettified in Emacs and when displayed in a text terminal may come with
the downside that some columns in Emacs will be "way too large" because
its width is determined by the width of the non-prettified text.

> Sure, but how can an application, say, disable all the effects of visual
> representation without (1) searching and let-binding each specific

Define "disable all the effects of visual representation".  I think what
you mean is something like "pretend the text is displayed by sending it
to an text terminal", but the width can depend on the specific text
terminal (especially for non-ASCII Unicode chars, but also for chars <
32).  So it's a non-trivial problem, in reality.


        Stefan






reply via email to

[Prev in Thread] Current Thread [Next in Thread]