unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Leo Liu <sdl.web@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 16804@debbugs.gnu.org
Subject: bug#16804: 24.3.50; [PATCH] fix with-silent-modifications
Date: Thu, 20 Feb 2014 08:33:54 +0800	[thread overview]
Message-ID: <m11tyyipvx.fsf@gmail.com> (raw)
In-Reply-To: <jwvmwhnot42.fsf-monnier+emacsbugs@gnu.org> (Stefan Monnier's message of "Wed, 19 Feb 2014 13:30:25 -0500")

On 2014-02-20 02:30 +0800, Stefan Monnier wrote:
> Sounds like there's a bug in js2-mode which causes it to run
> eldoc-documentation-function from within a with-silent-modifications
> (maybe because of a sit-for within a with-silent-modifications?).
> This would be a bug regardless of whether we change
> with-silent-modifications.

Steve Yegge tried very hard to keep js2-mode performant. It seems his
strategy is to pause every few statements. (see js2-parse-statement). If
js2 find a way to disable all timers while parsing, it might for
example, cause dropping connections in rcirc. We already have Gnus doing
that.

> Again, a backtrace would be much more useful.

There is no backtrace. In my case the type inference engine for
javascript is implemented in js and the only efficient way to
communicate with it is to tell it the file and ask for information. you
could send the whole buffer over and give it a fake filename, but then
it will have to do a re-parse in full every time i.e. inefficient for
large buffers. So when buffer-file-name is nil the engine gives you no
information and thus eldoc prints nothing. This is what I meant by `not
working' without the true value of buffer-file-name.

All the above information is only remotely related because I think the
real bug is in with-silent-modifications and nxml will have similar
issues.

So to sum up:

1. buffer-file-name has many uses and disable it makes other uses
   impossible
2. what if the body in with-silent-modifications change buffers

Sorry if I fail to articulate the case. For now I have worked around it
by saving buffer-file-name to another variable.

Leo





  reply	other threads:[~2014-02-20  0:33 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-19  0:34 bug#16804: 24.3.50; [PATCH] fix with-silent-modifications Leo Liu
2014-02-19  4:39 ` Stefan Monnier
2014-02-19  6:10   ` Leo Liu
2014-02-19 14:28     ` Stefan Monnier
2014-02-19 15:35       ` Leo Liu
2014-02-19 18:30         ` Stefan Monnier
2014-02-20  0:33           ` Leo Liu [this message]
2014-02-20  4:57             ` Stefan Monnier
2014-02-20  5:57               ` Leo Liu
2014-02-20 14:01                 ` Stefan Monnier
2014-02-20 14:38                   ` Leo Liu
2014-02-20 17:14                     ` Stefan Monnier
2014-02-21  0:29                       ` Leo Liu
2016-02-24  3:10                         ` Lars Ingebrigtsen

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=m11tyyipvx.fsf@gmail.com \
    --to=sdl.web@gmail.com \
    --cc=16804@debbugs.gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /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).