highlight-indent-guides in display engine

highlight-indent-guides in display engine

[Ergus]

Hi guys:

This email is a question about the highlight-indent-guides because some
people find that functionality very useful (and it is very common in
ides/editors around).

I am using the package with that name [1] but It affects performance a
lot. Specially scrolling and responsiveness in general. Even when
disabling the animations. 

So my question is in two parts:

1) Does emacs already provides a way to reproduce this functionality
that does not kill performance so much, even if we sacrifice some
functionality?

else:

2) Does it make sense to implement it in the display engine as we did
with the fill-column-indicator?

Thanks in advance for your replies,
Ergus

[1]: https://github.com/DarthFennec/highlight-indent-guides

Re: highlight-indent-guides in display engine

[Eli Zaretskii]

> Date: Sat, 6 Jul 2019 23:17:16 +0200
> From: Ergus <spacibba@aol.com>
> 
> This email is a question about the highlight-indent-guides because some
> people find that functionality very useful (and it is very common in
> ides/editors around).
> 
> I am using the package with that name [1] but It affects performance a
> lot. Specially scrolling and responsiveness in general. Even when
> disabling the animations. 
> 
> So my question is in two parts:
> 
> 1) Does emacs already provides a way to reproduce this functionality
> that does not kill performance so much, even if we sacrifice some
> functionality?

Not that I know of.  But there are some alternatives mentioned in the
README of that package -- aren't some of them faster?

> 2) Does it make sense to implement it in the display engine as we did
> with the fill-column-indicator?

Hard to answer this question because the requirements aren't clear.
The description of highlight-indent-guides doesn't include any
systematic explanations of what the package does, only some quite
terse description of some options.  Do you want to have all of what
that package does, or only part (and if the latter, which part)?

In general, I see potential difficulties in making this entirely part
of the display code, because what is displayed in the indentation of
each line depends directly and indirectly on what happens in preceding
lines.  This means, for example, that when the display engine is
invoked to lay out a single line, it might need to look backwards,
potentially very far backwards, to find indentation on previous lines,
If I'm not missing something, and this is indeed so, then such
searches will almost certainly slow down redisplay considerably.

Maybe someone will have clever ideas for how to avoid this problem.

Alternatively, we could implement part of the feature in Lisp, and the
other part in C.  For example, determining what indentation levels
should be displayed on a given line could be a job of the Lisp part.
But before we decide that this is a viable alternative, we should
profile the current Lisp implementation and find out which of its
parts are responsible for slowdown.  Then we could decide whether this
or that reimplementation will make the feature significantly faster.

Re: highlight-indent-guides in display engine

[Keith David Bershatsky]

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

I forgot to cc Emacs Devel ...

;;;;;;;;;;;;;;;;;;;;;; FORWARDED MESSAGE ;;;;;;;;;;;;;;;;;;;;;;


[-- Attachment #2: Type: message/rfc822, Size: 1122 bytes --]

From: Keith David Bershatsky <esq@lawlist.com>
To: Ergus <spacibba@aol.com>,Eli Zaretskii <eliz@gnu.org>
Subject: Re: highlight-indent-guides in display engine
Date: Sun, 07 Jul 2019 10:48:51 -0700
Message-ID: <m2wogtd9bw.wl%esq@lawlist.com>

I would suggest devising a method capable of intersecting characters, e,g.,

https://www.lawlist.com/images/22873_17684_light_dark_backgrounds.png

Using features 17684/22873, Emacs can quickly generate up to three lines that are capable of intersecting characters ...  The current draft patch is version 021.004 [06/29/2019]:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22873#155

Using features 17684/22873, I have not run any tests to see how many vertical lines could be drawn before there is an appreciable performance hit.  The current design only redraws what has changed since the previous redisplay, so it may be possible to draw several vertical lines without any performance hit at all ...

One idea that I have not tried would be to use a thin window like a scroll bar window to draw a vertical line ...

Re: highlight-indent-guides in display engine

[Ergus]

On Sun, Jul 07, 2019 at 06:04:10PM +0300, Eli Zaretskii wrote:
>> Date: Sat, 6 Jul 2019 23:17:16 +0200
>> From: Ergus <spacibba@aol.com>
>>
>> This email is a question about the highlight-indent-guides because some
>> people find that functionality very useful (and it is very common in
>> ides/editors around).
>>
>> I am using the package with that name [1] but It affects performance a
>> lot. Specially scrolling and responsiveness in general. Even when
>> disabling the animations.
>>
>> So my question is in two parts:
>>
>> 1) Does emacs already provides a way to reproduce this functionality
>> that does not kill performance so much, even if we sacrifice some
>> functionality?
>
>Not that I know of.  But there are some alternatives mentioned in the
>README of that package -- aren't some of them faster?
>
>> 2) Does it make sense to implement it in the display engine as we did
>> with the fill-column-indicator?
>
Hi Eli:

Sorry for the delay, but I've been very busy. 

>Hard to answer this question because the requirements aren't clear.
>The description of highlight-indent-guides doesn't include any
>systematic explanations of what the package does, only some quite
>terse description of some options.  Do you want to have all of what
>that package does, or only part (and if the latter, which part)?
>
Actually I like simplicity, so I will only support the simplest possible
approach that affects performance as least as possible. I don't care to
sacrifice functionality. Actually if there is not an efficient way to
do this it is better no implement it at all. (In my opinion)


>In general, I see potential difficulties in making this entirely part
>of the display code, because what is displayed in the indentation of
>each line depends directly and indirectly on what happens in preceding
>lines.  This means, for example, that when the display engine is
>invoked to lay out a single line, it might need to look backwards,
>potentially very far backwards, to find indentation on previous lines,
>If I'm not missing something, and this is indeed so, then such
>searches will almost certainly slow down redisplay considerably.
>
>Maybe someone will have clever ideas for how to avoid this problem.
>
Actually I had something like:

  (defun my/whitespace-mode () "My whitespace mode."
	 (setq whitespace-style '(face tabs tab-mark trailing)
	       whitespace-display-mappings	'((tab-mark 9 [?\u2502 9] [?\u2502 9])))
	 (custom-set-faces '(whitespace-tab ((t (:foreground "#444444")))))
	 (whitespace-mode 1))

As a prog-mode hook and with it's obvious limitations it used to be
enough for me. It is actually the approach that most of the editors
around implement more or less.

The only extra consideration it needs are:
1) What to do when people indent with spaces instead of tabs.
2) And how to avoid the tabs to be highlighted when not in the
indentation. (beginning of the line)

But none of them seems to be unsolvable.

From the packages:

I specially I don't want the dynamic part of the package that changes
colors when moving the cursor. But this is a personal choice (and
obviously there  will appear people asking for it in a while)

As a background I should mention that some time ago I was asking for the
indent-with-tabs align-with-spaces functionality to work out of the box,
specially because this code used to work perfectly fine for me with that
(And because I strongly believe that indent-with-tabs align-with-spaces
is much better than what provides indent-tabs-mode by default, because
it already mixes tabs with spaces but in a way that always produces the
wrong effect when changing the editor tab-width ...)

>Alternatively, we could implement part of the feature in Lisp, and the
>other part in C.  For example, determining what indentation levels
>should be displayed on a given line could be a job of the Lisp part.
>But before we decide that this is a viable alternative, we should
>profile the current Lisp implementation and find out which of its
>parts are responsible for slowdown.  Then we could decide whether this
>or that reimplementation will make the feature significantly faster.
>
I totally agree, I don't thing it is possible to implement this
efficiently enough purely in the lisp side with all the checks it
does. Which in spite of useful and accurate seems to be a bit expensive
and unneeded in most of the cases.

So lets go for the simplest case:

Check if indenting with spaces or tabs && add the indicator for
those character (or every tab-width spaces) from the beginning of the line
until the first different character of the line. And that's it...

Maybe add an option to highlight tabs when using spaces to indent and
vice-versa but that's a minor detail I don't really care too much.

Usually the users don't need more.

Re: highlight-indent-guides in display engine

[Eli Zaretskii]

> Date: Thu, 11 Jul 2019 21:06:51 +0200
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org
> 
> Check if indenting with spaces or tabs && add the indicator for
> those character (or every tab-width spaces) from the beginning of the line
> until the first different character of the line. And that's it...

I don't think I understand: what do you mean by "add the indicator"?
How would this indicator look like?

Re: highlight-indent-guides in display engine

[Ergus]

On Thu, Jul 11, 2019 at 10:15:21PM +0300, Eli Zaretskii wrote:
>> Date: Thu, 11 Jul 2019 21:06:51 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: emacs-devel@gnu.org
>>
>> Check if indenting with spaces or tabs && add the indicator for
>> those character (or every tab-width spaces) from the beginning of the line
>> until the first different character of the line. And that's it...
>
>I don't think I understand: what do you mean by "add the indicator"?
>How would this indicator look like?
>
Maybe a vertical bar (like our previous column indicator) or a width
line. Or something customizable somehow. We just need to look around,
there are several alternatives. We must chose the one that fits better
and produces less complications for us. But provides the functionality
somehow.

I don't thing how the indicator looks like may be a problem, but how
accurate or specific it behaves.

I am just looking around and Geany adds some vertical points as the
indicator positions (every tab or every x spaces). But the spaces are
only "indicated" when used for the indentation..

Sublime behaves in the same way. But there is an option to highlight the
indicator only in the blocks around the current cursor. (As in the
attachement)

Athom on the other hand seems to behave as in the
highlight-indent-guides.el package:
https://atom.io/packages/indent-guide-improved

With the animations and so on. Which seems to be the most complete
behavior, but less efficient.

In all the cases I just see that they add the indicator based on the
characters between the beginning of the line and the indentation (first
non blank character) not looking at the previous lines. They ignore if
there is a previous line  with wrong indentation or if the current line
adds 3 tabs more respecting to the previous one.

So, implementing it in this way doesn't seems to be so complex right?

Re: highlight-indent-guides in display engine

[Eli Zaretskii]

> Date: Fri, 12 Jul 2019 02:21:27 +0200
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org
> 
> >I don't think I understand: what do you mean by "add the indicator"?
> >How would this indicator look like?
> >
> Maybe a vertical bar (like our previous column indicator) or a width
> line. Or something customizable somehow. We just need to look around,
> there are several alternatives. We must chose the one that fits better
> and produces less complications for us. But provides the functionality
> somehow.
> 
> I don't thing how the indicator looks like may be a problem, but how
> accurate or specific it behaves.
> 
> I am just looking around and Geany adds some vertical points as the
> indicator positions (every tab or every x spaces). But the spaces are
> only "indicated" when used for the indentation..
> 
> Sublime behaves in the same way. But there is an option to highlight the
> indicator only in the blocks around the current cursor. (As in the
> attachement)

I didn't receive any attachments with your message.

> Athom on the other hand seems to behave as in the
> highlight-indent-guides.el package:
> https://atom.io/packages/indent-guide-improved
> 
> With the animations and so on. Which seems to be the most complete
> behavior, but less efficient.

The animations and highlighting inside the current block should be in
Lisp, not in the display code.  If at all.

> In all the cases I just see that they add the indicator based on the
> characters between the beginning of the line and the indentation (first
> non blank character) not looking at the previous lines. They ignore if
> there is a previous line  with wrong indentation or if the current line
> adds 3 tabs more respecting to the previous one.
> 
> So, implementing it in this way doesn't seems to be so complex right?

So basically you are talking about displaying some special glyph at
every tab stop inside leading whitespace of a line, or making each
tab-stop width have a different background color?  Yes, this should be
possible to do in the display code.  I just hope enough people will
see this as sufficient, because if most current users of these
packages won't switch, this new feature will not be worth its
development, documentation, and maintenance effort.  Maybe we should
ask on Reddit first?

Re: highlight-indent-guides in display engine

[Ergus]

On Fri, Jul 12, 2019 at 09:57:24AM +0300, Eli Zaretskii wrote:
>> Date: Fri, 12 Jul 2019 02:21:27 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: emacs-devel@gnu.org
>>
>> >I don't think I understand: what do you mean by "add the indicator"?
>> >How would this indicator look like?
>> >
>> Maybe a vertical bar (like our previous column indicator) or a width
>> line. Or something customizable somehow. We just need to look around,
>> there are several alternatives. We must chose the one that fits better
>> and produces less complications for us. But provides the functionality
>> somehow.
>>
>> I don't thing how the indicator looks like may be a problem, but how
>> accurate or specific it behaves.
>>
>> I am just looking around and Geany adds some vertical points as the
>> indicator positions (every tab or every x spaces). But the spaces are
>> only "indicated" when used for the indentation..
>>
>> Sublime behaves in the same way. But there is an option to highlight the
>> indicator only in the blocks around the current cursor. (As in the
>> attachement)
>
>I didn't receive any attachments with your message.
>
>> Athom on the other hand seems to behave as in the
>> highlight-indent-guides.el package:
>> https://atom.io/packages/indent-guide-improved
>>
>> With the animations and so on. Which seems to be the most complete
>> behavior, but less efficient.
>
>The animations and highlighting inside the current block should be in
>Lisp, not in the display code.  If at all.
>
>> In all the cases I just see that they add the indicator based on the
>> characters between the beginning of the line and the indentation (first
>> non blank character) not looking at the previous lines. They ignore if
>> there is a previous line  with wrong indentation or if the current line
>> adds 3 tabs more respecting to the previous one.
>>
>> So, implementing it in this way doesn't seems to be so complex right?
>
>So basically you are talking about displaying some special glyph at
>every tab stop inside leading whitespace of a line, or making each
>tab-stop width have a different background color?  Yes, this should be
>possible to do in the display code.  I just hope enough people will
>see this as sufficient, because if most current users of these
>packages won't switch, this new feature will not be worth its
>development, documentation, and maintenance effort.  Maybe we should
>ask on Reddit first?

Hi Eli:

I think several people will prefer to have the whole functionalities and
options to customize (as usual in emacs if there is a feature that
solves N issues, then somebody will come asking for the N+1 option.)

But in any case the minimal solution will be enough for a big number of
users if it compensates with performance.

But I agree that we must ask in reddit. May you please add a reddit
poster about?  Because as I don't use reddit very often, most users
ignore them.

Thanks in advance,
Ergus

Re: highlight-indent-guides in display engine

[Ergus]

On Fri, Jul 12, 2019 at 11:58:43AM +0200, Ergus wrote:
>On Fri, Jul 12, 2019 at 09:57:24AM +0300, Eli Zaretskii wrote:
>>>Date: Fri, 12 Jul 2019 02:21:27 +0200
>>>From: Ergus <spacibba@aol.com>
>>>Cc: emacs-devel@gnu.org
>>>
>>>>I don't think I understand: what do you mean by "add the indicator"?
>>>>How would this indicator look like?
>>>>
>>>Maybe a vertical bar (like our previous column indicator) or a width
>>>line. Or something customizable somehow. We just need to look around,
>>>there are several alternatives. We must chose the one that fits better
>>>and produces less complications for us. But provides the functionality
>>>somehow.
>>>
>>>I don't thing how the indicator looks like may be a problem, but how
>>>accurate or specific it behaves.
>>>
>>>I am just looking around and Geany adds some vertical points as the
>>>indicator positions (every tab or every x spaces). But the spaces are
>>>only "indicated" when used for the indentation..
>>>
>>>Sublime behaves in the same way. But there is an option to highlight the
>>>indicator only in the blocks around the current cursor. (As in the
>>>attachement)
>>
>>I didn't receive any attachments with your message.
>>
>>>Athom on the other hand seems to behave as in the
>>>highlight-indent-guides.el package:
>>>https://atom.io/packages/indent-guide-improved
>>>
>>>With the animations and so on. Which seems to be the most complete
>>>behavior, but less efficient.
>>
>>The animations and highlighting inside the current block should be in
>>Lisp, not in the display code.  If at all.
>>
>>>In all the cases I just see that they add the indicator based on the
>>>characters between the beginning of the line and the indentation (first
>>>non blank character) not looking at the previous lines. They ignore if
>>>there is a previous line  with wrong indentation or if the current line
>>>adds 3 tabs more respecting to the previous one.
>>>
>>>So, implementing it in this way doesn't seems to be so complex right?
>>
>>So basically you are talking about displaying some special glyph at
>>every tab stop inside leading whitespace of a line, or making each
>>tab-stop width have a different background color?  Yes, this should be
>>possible to do in the display code.  I just hope enough people will
>>see this as sufficient, because if most current users of these
>>packages won't switch, this new feature will not be worth its
>>development, documentation, and maintenance effort.  Maybe we should
>>ask on Reddit first?
>
>Hi Eli:
>
>I think several people will prefer to have the whole functionalities and
>options to customize (as usual in emacs if there is a feature that
>solves N issues, then somebody will come asking for the N+1 option.)
>
>But in any case the minimal solution will be enough for a big number of
>users if it compensates with performance.
>
>But I agree that we must ask in reddit. May you please add a reddit
>poster about?  Because as I don't use reddit very often, most users
>ignore them.
>
>Thanks in advance,
>Ergus
>

BTW:

Thinking more about this, there is an important corner case with my
simplistic solution: Lisp.

While the simplest solution will work in most of the cases: the
more popular languages (C, C++, Java, PHP, Python, Rust, Ruby,
JavaScript), and others no so popular (Fortran, Lua, Assembler, Bash,
Go) because their indentation is very regular; the lisp indentation is
very different and irregular (As Emacs indents it, I don't know the
rules it follows).

So, the simplistic solution won't work at all for the Lisp (common-lisp,
Scheme, Elisp) family and may be even a nuisance when writing Lisp :(. I
don't find any other language family with the same issue, but probably
there are other examples

Any idea here?
At least for the lisp case?

Re: highlight-indent-guides in display engine

[Eli Zaretskii]

> Date: Fri, 12 Jul 2019 11:58:43 +0200
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org
> 
> But I agree that we must ask in reddit. May you please add a reddit
> poster about?

Done.

Re: highlight-indent-guides in display engine

[Ergus]

Thanks Eli.

It looks like there are some people already interested and commenting;
lets give it a couple of days more.

Actually only one of them just suggested that the guide should appear in
the blank lines too.. but I don't think it is possible to add that
option with the simplistic implementation we have in mind right now.

But also there is not any answer/suggestion about what to do with the
irregular indentation in Lisp...



On Fri, Jul 12, 2019 at 04:45:11PM +0300, Eli Zaretskii wrote:
>> Date: Fri, 12 Jul 2019 11:58:43 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: emacs-devel@gnu.org
>>
>> But I agree that we must ask in reddit. May you please add a reddit
>> poster about?
>
>Done.

RE: highlight-indent-guides in display engine

[Drew Adams]

> But also there is not any answer/suggestion about what to do with the
> irregular indentation in Lisp...

Since you've asked that a couple times now,
here's my take on it.

It's not at all _needed_ for Lisp.  And personally
I wouldn't find it useful for Lisp.

Lisp has simple syntax - it's sufficient to
balance parens.  Automatic and on-demand
indentation work off of that syntax.

And most Lisp code does not have many-line
stretches with a large indentation, so you don't
often need to worry about line-of-sight alignment.
And checking column number is easy enough for any
exceptional cases.

Many other languages are different.  For them I
can see how it could be useful for some users.

Just one opinion.

Re: highlight-indent-guides in display engine

[Eli Zaretskii]

> Date: Fri, 12 Jul 2019 20:51:00 +0200
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org
> 
> Actually only one of them just suggested that the guide should appear in
> the blank lines too.. but I don't think it is possible to add that
> option with the simplistic implementation we have in mind right now.

We could do that only if the cursor is not on that empty line.  Would
that be sufficient?

> But also there is not any answer/suggestion about what to do with the
> irregular indentation in Lisp...

<Shrug> we could pretend that tab-width is 1 in Lisp, perhaps.  Or
maybe this feature should just ignore Lisp.

Re: highlight-indent-guides in display engine

[Joost Kremers]

On Sat, Jul 13 2019, Eli Zaretskii wrote:
>> Date: Fri, 12 Jul 2019 20:51:00 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: emacs-devel@gnu.org
>> 
>> Actually only one of them just suggested that the guide should 
>> appear in
>> the blank lines too.. but I don't think it is possible to add 
>> that
>> option with the simplistic implementation we have in mind right 
>> now.
>
> We could do that only if the cursor is not on that empty line. 
> Would
> that be sufficient?
>
>> But also there is not any answer/suggestion about what to do 
>> with the
>> irregular indentation in Lisp...
>
> <Shrug> we could pretend that tab-width is 1 in Lisp, perhaps. 
> Or
> maybe this feature should just ignore Lisp.

I use this feature mainly in Lisp...

-- 
Joost Kremers
Life has its moments

Re: highlight-indent-guides in display engine

[Eli Zaretskii]

> From: Joost Kremers <joostkremers@fastmail.fm>
> Date: Sat, 13 Jul 2019 10:32:14 +0200
> Cc: Ergus <spacibba@aol.com>
> 
> > <Shrug> we could pretend that tab-width is 1 in Lisp, perhaps.  Or
> > maybe this feature should just ignore Lisp.
> 
> I use this feature mainly in Lisp...

Then I guess you are one of those for whom the built-in feature will
not be good enough, and you will keep using some 3rd party package.

Re: highlight-indent-guides in display engine

[Joost Kremers]

On Sat, Jul 13 2019, Eli Zaretskii wrote:
>> From: Joost Kremers <joostkremers@fastmail.fm>
>> Date: Sat, 13 Jul 2019 10:32:14 +0200
>> Cc: Ergus <spacibba@aol.com>
>> 
>> > <Shrug> we could pretend that tab-width is 1 in Lisp, 
>> > perhaps.  Or
>> > maybe this feature should just ignore Lisp.
>> 
>> I use this feature mainly in Lisp...
>
> Then I guess you are one of those for whom the built-in feature 
> will
> not be good enough, and you will keep using some 3rd party 
> package.

Just my opinion, but from a user's perspective it might seem 
rather strange that a feature that Emacs supports out of the box 
does *not* work with Lisp. With any other editor I might think "oh 
well", but Emacs *is* Lisp.




-- 
Joost Kremers
Life has its moments

Re: highlight-indent-guides in display engine

[Eli Zaretskii]

> From: Joost Kremers <joostkremers@fastmail.fm>
> Date: Sat, 13 Jul 2019 23:37:15 +0200
> Cc: spacibba@aol.com
> 
> > Then I guess you are one of those for whom the built-in feature
> > will not be good enough, and you will keep using some 3rd party
> > package.
> 
> Just my opinion, but from a user's perspective it might seem 
> rather strange that a feature that Emacs supports out of the box 
> does *not* work with Lisp. With any other editor I might think "oh 
> well", but Emacs *is* Lisp.

So you are saying that we should not provide this as a built-in
feature unless we also support dynamic indentation that doesn't heed
to tab stops and tab-width?

Re: highlight-indent-guides in display engine

[Ergus]

On Sat, Jul 13, 2019 at 11:37:15PM +0200, Joost Kremers wrote:
>
>On Sat, Jul 13 2019, Eli Zaretskii wrote:
>>>From: Joost Kremers <joostkremers@fastmail.fm>
>>>Date: Sat, 13 Jul 2019 10:32:14 +0200
>>>Cc: Ergus <spacibba@aol.com>
>>>
>>>> <Shrug> we could pretend that tab-width is 1 in Lisp, > perhaps.  
>>>Or
>>>> maybe this feature should just ignore Lisp.
>>>
>>>I use this feature mainly in Lisp...
>>
>>Then I guess you are one of those for whom the built-in feature will
>>not be good enough, and you will keep using some 3rd party package.
>
>Just my opinion, but from a user's perspective it might seem rather 
>strange that a feature that Emacs supports out of the box does *not* 
>work with Lisp. With any other editor I might think "oh well", but 
>Emacs *is* Lisp.
>
>
Hi

I tend to agree with the fact that Lisp should be specially supported in
all the emacs functionalities.

But with this minimal support at least there will be something "good
enough" for C and all the derived from cc-mode (Java, C++, Ruby, Perl,
Lua) plus Python, Latex, Makefiles, Bash, Tcl, SQL, Assembly, Rust. So,
many users will be benefited... I think it is still a good deal right?.
>
>
>-- 
>Joost Kremers
>Life has its moments
>
Ergus

Re: highlight-indent-guides in display engine

[Joost Kremers]

On Sun, Jul 14 2019, Eli Zaretskii wrote:
>> From: Joost Kremers <joostkremers@fastmail.fm>
>> Just my opinion, but from a user's perspective it might seem 
>> rather strange that a feature that Emacs supports out of the 
>> box 
>> does *not* work with Lisp. With any other editor I might think 
>> "oh 
>> well", but Emacs *is* Lisp.
>
> So you are saying that we should not provide this as a built-in
> feature unless we also support dynamic indentation that doesn't 
> heed
> to tab stops and tab-width?

No, it's probably better to provide this feature for some 
languages than not to provide it at all. I'm just saying that that 
will raise some eyebrows in the future and may lead to some 
surprised questions on the relevant fora. So perhaps some thought 
about how it might (eventually) be implemented for Lisp may be in 
order. (Perhaps as a completely separate package written in Lisp, 
or perhaps with some additional Lisp code that uses the underlying 
functionality in the C code? I have no idea what's feasible.)



-- 
Joost Kremers
Life has its moments

Re: highlight-indent-guides in display engine

[Stefan Monnier]

> But with this minimal support at least there will be something "good
> enough" for C and all the derived from cc-mode (Java, C++, Ruby, Perl,
> Lua) plus Python, Latex, Makefiles, Bash, Tcl, SQL, Assembly, Rust. So,
> many users will be benefited... I think it is still a good deal right?.

I'm not sure I understand the problem that makes it work for those modes
but not for Lisp.

E.g. in C mode by default we get indentation of this form:

    int main ()
    {
      sfgasfgasfg(tot(x
                      + 3),
                  y);
    }

How is this fundamentally different from what happens in Lisp?


        Stefan

Re: highlight-indent-guides in display engine

[Ergus]

On Mon, Jul 15, 2019 at 08:58:00AM -0400, Stefan Monnier wrote:
>> But with this minimal support at least there will be something "good
>> enough" for C and all the derived from cc-mode (Java, C++, Ruby, Perl,
>> Lua) plus Python, Latex, Makefiles, Bash, Tcl, SQL, Assembly, Rust. So,
>> many users will be benefited... I think it is still a good deal right?.
>
Hi Stefan:

First, what I propose is not a general solution for all the cases,
actually it is VERY restrictive, but we don't have anything better and
efficient enough.

Your example is a typical example of indent + align and the emacs align
policy to mix spaces and tabs is actually the worst possible (in my very
modest opinion) I suppose there is an historical reason for it... But I
won't argue about it (there is a recent thread I started about that and
Alan gave a nice workaround (which for me should be like the default
when using tabs)).

In the general situation the indent will be a fix number of spaces >=2
|| a tab. And no lines will start, for example, in the half of the
indentation which in lisp happens very often (for example when there are
two opening parenthesis together).

Your example actually breaks very short lines into pieces, but it will
look like this more or less:

int main ()
{
  sfgasfgasfg(tot(x
  |  |  |  |  |  |+ 3),
  |  |  |  |  |y);
}

But even in this way it is better than nothing and it is not much
different than what most of the other editors do right now. And in
python it is specially useful because a typical error is to mix spaces
with tabs due to opening a file edited somewhere else.

But also there are some people doing the same just setting:

whitespace-style '(face tabs tab-mark trailing)
whitespace-display-mappings	'((tab-mark 9 [?\u2502 9] [?\u2502 9])))

In whitespace mode, because it works and don't kills performance.

In any case, I just made a proposal, any improvement you think works
better is very very welcome.

Thanks for putting some interest on this,
Ergus

>I'm not sure I understand the problem that makes it work for those modes
>but not for Lisp.
>
>E.g. in C mode by default we get indentation of this form:
>
>    int main ()
>      {
>        sfgasfgasfg(tot(x
>                      + 3),
>                  y);
>      }
>
>How is this fundamentally different from what happens in Lisp?
>
>
>        Stefan
>

Re: highlight-indent-guides in display engine

[Stefan Monnier]

> int main ()
> {
>  sfgasfgasfg(tot(x
>  |  |  |  |  |  |+ 3),
>  |  |  |  |  |y);
> }

AFAICT this will work just as well in Lisp.


        Stefan

Re: highlight-indent-guides in display engine

[Ergus]

On Mon, Jul 15, 2019 at 10:49:20AM -0400, Stefan Monnier wrote:
>> int main ()
>> {
>>  sfgasfgasfg(tot(x
>>  |  |  |  |  |  |+ 3),
>>  |  |  |  |  |y);
>> }
>
>AFAICT this will work just as well in Lisp.
>
>
>        Stefan
>
>
If it works also for lisp, better then, my concern was that in case
there are things like:

  (setq
   isearch-adjusted nil
   isearch-yank-flag nil)

or `cond', where the indentation is usually one space instead of 2, it
may become more confusing than beneficial.

Re: highlight-indent-guides in display engine

[Stefan Monnier]

> If it works also for lisp, better then, my concern was that in case
> there are things like:
>
>  (setq
>   isearch-adjusted nil
>   isearch-yank-flag nil)
>
> or `cond', where the indentation is usually one space instead of 2, it
> may become more confusing than beneficial.

My point is that those same kinds of problem can show up in any
major mode.  It may work better in some modes than others, but it's
a question of degree, not a binary "works / doesn't work":

    int main ()
    {
       x = (3 +
            (tmp = y + 1,
             (4 +
              5 +
              6)));
    }



        Stefan

Re: highlight-indent-guides in display engine

[Eli Zaretskii]

On July 15, 2019 7:43:24 PM GMT+01:00, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> > If it works also for lisp, better then, my concern was that in case
> > there are things like:
> >
> >  (setq
> >   isearch-adjusted nil
> >   isearch-yank-flag nil)
> >
> > or `cond', where the indentation is usually one space instead of 2,
> it
> > may become more confusing than beneficial.
> 
> My point is that those same kinds of problem can show up in any
> major mode.  It may work better in some modes than others, but it's
> a question of degree, not a binary "works / doesn't work":
> 
>     int main ()
>     {
>        x = (3 +
>             (tmp = y + 1,
>              (4 +
>               5 +
>               6)));
>     }
> 
> 
> 
>         Stefan

I'm all for supporting these use cases, of course, and welcome ideas for how to do that without significantly slowing down redisplay by looking far back in the buffer.