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: Ihor Radchenko
Subject: bug#64696: 30.0.50; indent-to inherits preceding text properties, including 'invisible
Date: Sun, 23 Jul 2023 07:30:34 +0000

Eli Zaretskii <eliz@gnu.org> writes:

>> > With the patch below, Test #2 shows "current-column = 6", which is
>> > correct, since the cursor is shown after "* Test", with all the rest
>> > invisible.
>> 
>> This will definitely break indentation code.
>
> But is correct, don't you agree?

Depends on the usage of `current-column' and design of Emacs
indentation.

On one hand, Emacs' indentation is nicely aligning text as is it
actually displayed in the buffer, taking into account all kinds of bells
and whistles that alter the displayed text width.

On the other hand, such visual indentation is not always good. Visuals
present in one Emacs config may not be enabled in another config. And
code/text nicely aligned on one machine will suddenly look ugly on
other. For example, see
http://endlessparentheses.com/using-prettify-symbols-in-clojure-and-elisp-without-breaking-indentation.html

In Org mode, visual indentation is also not necessarily good thing:

1. Org mode is generally aiming for the produced Org files to be
   readable as unfontified plain text. So, quirks related to visual
   indentation generally tend to mess things up.
2. Org mode uses indentation as part of the syntax. I had to get rid of
   using `current-column' and calculated "true textual indentation"
   manually to avoid breakage after `current-column' started to take
   into account invisibility. (bug#56837)

>> I am pretty sure that it is not the only breakage.
>
> I don't insist in making that change.  Quite the opposite, actually.
> I also expect it to break gobs of indentation code where invisible
> text is involved.  Indentation code should probably temporarily remove
> the invisibility spec, while indenting, or something.

That would make sense, yes.

> The main motivation to fix scan_for_column to consider more visual
> effects was so vertical cursor motion works as expected when large
> portions of text are hidden.

What about having something like `current-visual-column' that will be
used when we really need to examine which display column the cursor is
it, accounting for all the display-affecting properties?

Or maybe even have `use-visual-columns' variable that will modify how
`current-column' behaves ('visual, 'textual, 'visual-ignore-invisible,
etc)

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>





reply via email to

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