search

emacs-ess / ESS

Emacs Speaks Statistics: ESS
https://ess.r-project.org/
GNU General Public License v3.0
613 stars 160 forks source link

Font-lock broken in iESS #376

Closed uhkeller closed 6 years ago

uhkeller commented 7 years ago

Font-lock no longer works reliably for me in iESS buffers. It's most obvious with longer character vectors as in the attached screenshot. I'm not sure exactly when the problem appeared. I'm using ESS 16.04 with Emacs 25.1 on Arch Linux. I have the default font-lock configuration.

2016-09-30-145319_958x1159_scrot

lionel- commented 7 years ago

I don't think there has been a change on that front. This is a known problem and the only efficient solution is to turn off fontification of outputs in inferior buffers. That's probably what we'll do in the future but we first need to figure out a way to turn it off for outputs while still fontifying inputs.

uhkeller commented 7 years ago

Thanks for the reply. That's astonishing… I've been using ESS for years and only noticed this now.

lionel- commented 7 years ago

maybe the problem has gotten worse with recent Emacs?

uhkeller commented 7 years ago

I downgraded to Emacs 24.5, and the problem is gone. Do you think it's worth filing a bug report for Emacs, given that apparently iESS fontification isn't even supposed to work?

lionel- commented 7 years ago

hmm I don't think it's an Emacs bug, they probably just changed the default value for how far back fontlock should go before fontifying (just a guess). If this guess is right this means there is more chance for fontification to start in the middle of a string.

This is normally fixed by providing fontlock with a function that finds a safe place to start, but this has the potential to slow down the inferior buffer for long outputs.

lionel- commented 7 years ago

this problem has been bugging me as well lately, especially when compiling packages.

mmaechler commented 7 years ago

If it is just a new default... we should raise the value in ESS. Honestly, I'm also appalled at the result since I've been using Emacs 25.1 ... only one week now.

Anybody knowing what the configuration variables are ?

nverno commented 7 years ago

It looks like a jit-lock thing. Increasing jit-lock-chunk-size results in larger regions getting syntactically font-locked. Adding to jit-lock-after-change-extend-region-functions seems to fix it, but with noticeable delay.

mmaechler commented 7 years ago

Thanks @nverno ! So the jit-*-size default is just 500 which is only half a dozen lines of length 80. What are you suggesting to add to the jit-lock-after-change-extend-region-functions?
And follow-up Q: can we / "is it good emacs-citizenship" if we modifiy some of these by default when ess-site is loaded?

lionel- commented 7 years ago

can we / "is it good emacs-citizenship" if we modifiy some of these by default when ess-site is loaded?

uhh I would say not :) But we could increase it buffer-locally in inferiors. Maybe it should be a multiple of max inferior buffer size, like a tenth? With reasonable predefined max and min values. Some tests are needed to assess impact on performance.

nverno commented 7 years ago

I just tried extending the beginning point to be extended a previous sexp backward. But it seemed to result in fontification happening twice, and being noticeably slower, so I abandonded it and just setq-local jit-lock-chunk-size to 5000 in inferior-ess-mode-hook.

I don't know it you have an easy way to access getOption("max.print"), but maybe that could influence the choice of chunk size.

mmaechler commented 7 years ago

I've pushed a version with 4880e9d.