highlight-indent-guides in display engine

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Reply | Threaded
Open this post in threaded view
|

Re: highlight-indent-guides in display engine

Eli Zaretskii
> Date: Sat, 6 Jul 2019 23:17:16 +0200
> From: Ergus <[hidden email]>
>
> 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.

Reply | Threaded
Open this post in threaded view
|

Re: highlight-indent-guides in display engine

Keith David Bershatsky
In reply to this post by Ergus
I forgot to cc Emacs Devel ...

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


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 ...
Reply | Threaded
Open this post in threaded view
|

Re: highlight-indent-guides in display engine

Ergus
In reply to this post by Eli Zaretskii
On Sun, Jul 07, 2019 at 06:04:10PM +0300, Eli Zaretskii wrote:

>> Date: Sat, 6 Jul 2019 23:17:16 +0200
>> From: Ergus <[hidden email]>
>>
>> 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.


Reply | Threaded
Open this post in threaded view
|

Re: highlight-indent-guides in display engine

Eli Zaretskii
> Date: Thu, 11 Jul 2019 21:06:51 +0200
> From: Ergus <[hidden email]>
> Cc: [hidden email]
>
> 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?

Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>
>> Cc: [hidden email]
>>
>> 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?





Reply | Threaded
Open this post in threaded view
|

Re: highlight-indent-guides in display engine

Eli Zaretskii
> Date: Fri, 12 Jul 2019 02:21:27 +0200
> From: Ergus <[hidden email]>
> Cc: [hidden email]
>
> >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?

Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>
>> Cc: [hidden email]
>>
>> >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

Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>
>>>Cc: [hidden email]
>>>
>>>>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?

Reply | Threaded
Open this post in threaded view
|

Re: highlight-indent-guides in display engine

Eli Zaretskii
In reply to this post by Ergus
> Date: Fri, 12 Jul 2019 11:58:43 +0200
> From: Ergus <[hidden email]>
> Cc: [hidden email]
>
> But I agree that we must ask in reddit. May you please add a reddit
> poster about?

Done.

Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>
>> Cc: [hidden email]
>>
>> But I agree that we must ask in reddit. May you please add a reddit
>> poster about?
>
>Done.

Reply | Threaded
Open this post in threaded view
|

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.

Reply | Threaded
Open this post in threaded view
|

Re: highlight-indent-guides in display engine

Eli Zaretskii
In reply to this post by Ergus
> Date: Fri, 12 Jul 2019 20:51:00 +0200
> From: Ergus <[hidden email]>
> Cc: [hidden email]
>
> 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.

Reply | Threaded
Open this post in threaded view
|

Re: highlight-indent-guides in display engine

Joost Kremers-2

On Sat, Jul 13 2019, Eli Zaretskii wrote:

>> Date: Fri, 12 Jul 2019 20:51:00 +0200
>> From: Ergus <[hidden email]>
>> Cc: [hidden email]
>>
>> 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

Reply | Threaded
Open this post in threaded view
|

Re: highlight-indent-guides in display engine

Eli Zaretskii
> From: Joost Kremers <[hidden email]>
> Date: Sat, 13 Jul 2019 10:32:14 +0200
> Cc: Ergus <[hidden email]>
>
> > <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.

Reply | Threaded
Open this post in threaded view
|

Re: highlight-indent-guides in display engine

Joost Kremers-2

On Sat, Jul 13 2019, Eli Zaretskii wrote:

>> From: Joost Kremers <[hidden email]>
>> Date: Sat, 13 Jul 2019 10:32:14 +0200
>> Cc: Ergus <[hidden email]>
>>
>> > <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

Reply | Threaded
Open this post in threaded view
|

Re: highlight-indent-guides in display engine

Eli Zaretskii
> From: Joost Kremers <[hidden email]>
> Date: Sat, 13 Jul 2019 23:37:15 +0200
> Cc: [hidden email]
>
> > 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?

Reply | Threaded
Open this post in threaded view
|

Re: highlight-indent-guides in display engine

Ergus
In reply to this post by Joost Kremers-2
On Sat, Jul 13, 2019 at 11:37:15PM +0200, Joost Kremers wrote:

>
>On Sat, Jul 13 2019, Eli Zaretskii wrote:
>>>From: Joost Kremers <[hidden email]>
>>>Date: Sat, 13 Jul 2019 10:32:14 +0200
>>>Cc: Ergus <[hidden email]>
>>>
>>>> <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

Reply | Threaded
Open this post in threaded view
|

Re: highlight-indent-guides in display engine

Joost Kremers-2
In reply to this post by Eli Zaretskii

On Sun, Jul 14 2019, Eli Zaretskii wrote:

>> From: Joost Kremers <[hidden email]>
>> 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

Reply | Threaded
Open this post in threaded view
|

Re: highlight-indent-guides in display engine

Stefan Monnier
In reply to this post by Ergus
> 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


12