unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Vitalie Spinu <spinuvit@gmail.com>
Cc: emacs-devel@gnu.org
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	[thread overview]
Message-ID: <jwv4n0g5j42.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <87ioowcr7l.fsf@gmail.com> (Vitalie Spinu's message of "Fri, 23 May 2014 10:58:22 -0700")

> 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	other threads:[~2014-05-23 20:49 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-07 18:34 trunk r116426: * lisp/jit-lock.el (jit-lock-mode): Keep it disabled in indirect buffers João Távora
2014-04-07 20:37 ` Glenn Morris
2014-04-07 20:48   ` João Távora
2014-04-07 20:40 ` Stefan Monnier
2014-05-22  4:51   ` Vitalie Spinu
2014-05-23 13:27     ` Stefan Monnier
2014-05-23 17:58       ` Vitalie Spinu
2014-05-23 20:49         ` Stefan Monnier [this message]
2014-05-23 23:15           ` Vitalie Spinu
2014-05-24  3:10             ` Stefan Monnier
2014-05-24  9:46               ` Vitalie Spinu
2014-05-24 14:35                 ` Stefan Monnier
2014-05-30 19:26                   ` Vitalie Spinu
2014-05-30 19:54                     ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwv4n0g5j42.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=emacs-devel@gnu.org \
    --cc=spinuvit@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).