emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: trunk r116426: * lisp/jit-lock.el (jit-lock-mode): Keep it disabled


From: Stefan Monnier
Subject: Re: trunk r116426: * lisp/jit-lock.el (jit-lock-mode): Keep it disabled in indirect buffers.
Date: Fri, 23 May 2014 16:49:09 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)

> That would be great, but how often can I update it at ELPA?

`elpa' is a Git repository, so you can hack there to your heart's content.

> AFAIK elpa is for "stable" packages

That's a common misconception.

> and polymode is still pretty far from being stable. There is still
> some work to be done - chunk cashing with text properties, indentation
> tweaks, poly-web-mode, etc.  MELPA works just great for quick syncs.

Currently, the scripts at elpa.gnu.org only build "stable" packages,
i.e. a new package is released on GNU ELPA only when you bump the
"Version:" header of your package in the `elpa' repository.

I'd like to extend this so people can also install "whatever is at the
head of the branch".  Currently, they can do it by checking out the
`elpa' branch and using "make" in it, which puts into into an
"installed" state (so just just need to add the directory to their
package-directory-list), but then they get not just that one package,
but *all* GNU ELPA packages.

We could change the elpa.gnu.org scripts so that they additionally build
a secondary archive that would be a sort of GNU MELPA.  Or we could
provide new commands (a la "quelpa") to install a package directly from
the `elpa' branch.

> Why exactly after/before-change-functions should work in the base buffer
> only?

It's the simplest option.  If you want them to apply to other buffers as
well, then you can still get that by adding
a after/before-change-function to the base buffer which runs the
after/before-change-functions in the indirect buffer.

> So, if I am in C++ chunk, font-lock and change-functions better be
> from and act on current C++ buffer, not on the base buffer which is
> typically in fundamental mode.

What happens if you're inside a HTML chunk which has an embedded PHP
chunk and you edit that PHP chunk from that HTML-mode buffer instead of
from the PHP-mode buffer?

> I guess for after/before-change-functions this argument applies more
> broadly. One might want to have a change-function that acts differently
> depending on whether the current buffer is indirect or not. For example
> auto complete popup implemented with overlays must act in current buffer
> because overlays are not shared.

Indeed, there are all kinds of possible scenarios, so the C code can't
know which set of options to choose.  Instead it has to choose one
option which is "safe" and from which your code can then do what needs
to be done.


        Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]