tags 25132 fixed
close 25132 25.2
quit
npost...@users.sourceforge.net writes:
> Dmitry Gutov writes:
>
>> So, personally, I'd try to fix the particular instance
>> first. Switching buffers inside with-silent-modifications is not a
>> very common usage, I think.
>>
>> Maybe org-src should itself
Dmitry Gutov writes:
> On 20.01.2017 03:52, npost...@users.sourceforge.net wrote:
>
>> My feeling is that inhibit-modification-hooks should usually be buffer
>> local anyway.
>
> Maybe you're right.
>
> inhibit-read-only, bound nearby, seems to be in the same situation.
>
>>> If we are not, why n
On 20.01.2017 03:52, npost...@users.sourceforge.net wrote:
My feeling is that inhibit-modification-hooks should usually be buffer
local anyway.
Maybe you're right.
inhibit-read-only, bound nearby, seems to be in the same situation.
If we are not, why not make inhibit-modification-hooks alwa
Clément Pit--Claudel writes:
> On 2017-01-19 19:52, npost...@users.sourceforge.net wrote:
>> because even after doing (make-variable-buffer-local 'var), (let
>> ((var 'foo))...) still makes a global binding.
>> `make-variable-buffer-local' only has effect for `setq', which I
>> think will hardly
On 2017-01-19 19:52, npost...@users.sourceforge.net wrote:
> because even after doing (make-variable-buffer-local 'var), (let
> ((var 'foo))...) still makes a global binding.
> `make-variable-buffer-local' only has effect for `setq', which I
> think will hardly ever happen for `inhibit-modification
Dmitry Gutov writes:
> On 08.01.2017 00:20, npost...@users.sourceforge.net wrote:
>> -(inhibit-modification-hooks t))
>> +(inhibit-modification-hooks
>> + (progn (make-local-variable 'inhibit-modification-hooks) t)))
>
> Are we not worried that inhibit-modifica
On 08.01.2017 00:20, npost...@users.sourceforge.net wrote:
-(inhibit-modification-hooks t))
+(inhibit-modification-hooks
+ (progn (make-local-variable 'inhibit-modification-hooks) t)))
Are we not worried that inhibit-modificaiton-hooks will become
buffer-loc
tags 25132 patch
quit
npost...@users.sourceforge.net writes:
> The problem is that org updates its temporary fontification buffer from
> its fontify rules which are called by jit-lock-function, which means
> that inhibit-modification-hooks is bound to t. Therefore, when
> org-src-font-lock-fontif
tags 25132 confirmed
quit
The problem is that org updates its temporary fontification buffer from
its fontify rules which are called by jit-lock-function, which means
that inhibit-modification-hooks is bound to t. Therefore, when
org-src-font-lock-fontify-block calls delete-region to remove lefto
Dear Glenn + bug-gnu-emacs,
Did you try the steps to reproduce? Indeed Clément was right! The bug also
reliably reproduces also with org 8.2.10, if you additionally set
org-src-fontify-natively to t.
Please let me know if you need any more information for the bug report,
David
Clément Pit--Cla
On 2016-12-07 21:08, Glenn Morris wrote:
> David Dynerman wrote:
>> The bug does NOT occur with org 8.2.10.
>
> Since that's the version included with Emacs, I'm confused as to why
> you've been encouraged to report this to bug-gnu-emacs.
I can reproduce the issue in emacs -Q on master; hence my
David Dynerman wrote:
> The bug does NOT occur with org 8.2.10.
Since that's the version included with Emacs, I'm confused as to why
you've been encouraged to report this to bug-gnu-emacs.
12 matches
Mail list logo
