[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#11944: 24.1.50; newcomment needs comment-normalize-vars in more func
bug#11944: 24.1.50; newcomment needs comment-normalize-vars in more functions
Sat, 17 Aug 2019 14:50:03 -0700
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)
Reuben Thomas <address@hidden> writes:
> When adding a word to a per-buffer dictionary in an AuCTeX buffer, I get
> an error caused by the fact that AuCTeX sets comment-padding to 1, then
> calls comment-padright, which assumes comment-padding is a string.
> A similar bug report is here:
> Making comment-padright call comment-normalize-vars fixes this problem;
> presumably at least comment-padleft and perhaps other functions need the
> same treatment.
> (As far as I can see, setting comment-padding to an integer is still
> allowed, as per its docstring.)
(I'm going through old bug reports that have unfortunately gotten no
The doc in newcomment.el specifies that any command that calls the
newcomment functions should call `comment-normalize-vars' first, so I
don't think this is a bug in newcomment.el. (All the commands in that
file do this.)
So this sounds like a bug in AuCTeX. Are you still seeing this bug, and
if so, do you have a backtrace that'll show where AuCTeX is bugging out?
The referenced URL is just somebody calling `commend-padright' directly,
which isn't allowed.
(I'll add that to the doc string of that function.)
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
- bug#11944: 24.1.50; newcomment needs comment-normalize-vars in more functions,
Lars Ingebrigtsen <=