emacs-typescript
Fix byte-compiler warnings
GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.1) of 2019-02-26
Leaving directory ‘/home/thomas/.emacs.d/elpa/typescript-mode-20181221.905’
Compiling file /home/thomas/.emacs.d/elpa/typescript-mode-20181221.905/typescript-mode-test-utilities.el at Thu Feb 28 19:29:48 2019
Entering directory ‘/home/thomas/.emacs.d/elpa/typescript-mode-20181221.905/’
Compiling file /home/thomas/.emacs.d/elpa/typescript-mode-20181221.905/typescript-mode.el at Thu Feb 28 19:29:48 2019
Compiling internal form(s) at Thu Feb 28 19:29:48 2019
Warning (bytecomp): ‘font-lock-fontify-buffer’ is for interactive use only; use ‘font-lock-ensure’ or ‘font-lock-flush’ instead. [2 times]
Warning (bytecomp): ‘syntax-begin-function’ is an obsolete variable (as of 25.1).
First of all: This is Emacs using Git master, right?
Second: I'm not sure this can be fixed while maintaining full compatibility with all supported versions of Emacs.
So... Are these just warnings, or are they causing actual errors too?
First of all: This is Emacs using Git master, right?
Yes, this is a bleeding edge emacs ;)
I created this issue, because there may be performance problems in the case of large files that would be fixed by replacing the font-lock-fontify-buffer by the one suggested in the output above. See https://github.com/thisch/python-cell.el/issues/8
I think the warnings above are also output on a released version of emacs, but I haven't checked it.
Feel free to try out the proposed changes in the PR. If it breaks compatibility, I'm sure the CI will let us know :)
font-lock-fontify-buffer is already avoided on versions of Emacs that provide font-lock-ensure, as the code surrounding the warning's location show:
"A custom predicate to help `flyspell-prog-mode' determine whether a word should be checked."
;; We depend on fontification for our results. font-lock-ensure is defined on
;; Emacs 25 and over. Earlier versions use font-lock-fontify-buffer.
(if (fboundp 'font-lock-ensure)
(font-lock-ensure)
(font-lock-fontify-buffer))
(@josteink I guess we should for typescript-mode do the same thing you argued for tide and have an analogue of tide--emacs-at-least here.)
I don't know how the warnings are triggered. If the warning is issued only if font-lock-fontify-buffer is compiled, then it may be avoidable by using conditional compilation. This might be preferable as the choice about which branch to take would be done just once during compilation. Otherwise, with-no-warnings could be used.
syntax-begin-function is something typescript-mode inherited "lock, stock, and barrel" from js-mode. AFAICT, it just became obsolete from 25.1 onwards and was not replaced with anything. I've not been able to track the whole story about it, but it's been discussed here, and the change to js-mode was made here. It was not replaced with anything else there.
I suspect something changed in Emacs' internals that made it so that whatever information it was providing is provided through other means, and this is why it is not replaced with anything. But for us, the issue is as with font-lock-fontify-buffer. We support old versions that assumed that this variable was present and properly set, so we cannot just remove it from the code base.
font-lock-fontify-buffer is already avoided on versions of Emacs that provide font-lock-ensure, as the code surrounding the warning's location show
Yeah. This was the reason why I asked about actual problems and not just compiler warnings.
I guess we should for typescript-mode do the same thing you argued for tide and have an analogue of tide--emacs-at-least here.
That's a good suggestion, although in this case it is fairly well documented what we're doing and why.
I don't know how the warnings are triggered. If the warning is issued only if font-lock-fontify-buffer is compiled, then it may be avoidable by using conditional compilation.
I haven't looked too deeply into this either, but that sounds plausible.
This might be preferable as the choice about which branch to take would be done just once during compilation.
On the other hand, my experience trying to uncover what was actually run in csharp-mode (which IMO relied too heavily on compile-time constructs) makes me somewhat hesitant to recommend this route.
Maybe if we can put it in a corner, where it is equally well documented as this is?
Otherwise, with-no-warnings could be used.
I think that is a bit drastic. Warnings often show us things which we should do something about, and I'm pretty sure we've made improvements based on warnings in the past.
@josteink I meant to reply earlier, but forgot. The one thing that I feel I need to reply to is:
I think that is a bit drastic. Warnings often show us things which we should do something about, and I'm pretty sure we've made improvements based on warnings in the past.
Hmm... are we on the same page here? with-no-warnings can be scoped to the one line that causes the warnings so:
(with-no-warnings
(setq-local syntax-begin-function #'typescript--syntax-begin-function)))
I suppose a line that is wrapped like this could someday generate additional warnings that it may be good to know about but I'd expect the risk to be fairly small.
This being said, I'm fine with not doing anything to prevent the warnings.
Hmm... are we on the same page here?
Probably not. I was replying from my phone (quite busy handling babies these days :smiley: ), and assumed you meant a global compile-flag passed to the general build process.
with-no-warnings can be scoped to the one line that causes the warnings
Right. In that case I agree, and have no issues with it what so ever.
Old issue id old. Typescript is now supported in core emacs. Closing this issue.