From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: /srv/bzr/emacs/trunk r101338: * lisp/emacs-lisp/syntax.el (syntax-ppss): More sanity check to catch Date: Wed, 12 Feb 2014 17:10:27 +0200 Message-ID: <52FB8EE3.2020905@yandex.ru> References: <87r47bi1e5.fsf@yandex.ru> <52F96284.50507@yandex.ru> <52FAE12B.6060101@yandex.ru> <52FAF761.2020801@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1392217854 5990 80.91.229.3 (12 Feb 2014 15:10:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 12 Feb 2014 15:10:54 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 12 16:11:02 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WDbSf-00077z-V8 for ged-emacs-devel@m.gmane.org; Wed, 12 Feb 2014 16:10:54 +0100 Original-Received: from localhost ([::1]:39561 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WDbSf-0006bn-5t for ged-emacs-devel@m.gmane.org; Wed, 12 Feb 2014 10:10:53 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38862) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WDbSU-0006bZ-Rb for emacs-devel@gnu.org; Wed, 12 Feb 2014 10:10:51 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WDbSL-0001J6-Uz for emacs-devel@gnu.org; Wed, 12 Feb 2014 10:10:42 -0500 Original-Received: from mail-ea0-x22e.google.com ([2a00:1450:4013:c01::22e]:37281) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WDbSL-0001H5-AL for emacs-devel@gnu.org; Wed, 12 Feb 2014 10:10:33 -0500 Original-Received: by mail-ea0-f174.google.com with SMTP id z10so1186074ead.33 for ; Wed, 12 Feb 2014 07:10:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=EiocvBIJht5xE5egKGUBpy3TGDswTAGpQ6lh/Nti6Vk=; b=jH1Fvlhsfj7OWKdO+kXAu+OntDNPJwWZ704CytusYY5dPQiAo6+P3b7ILrZ1ng/uZn fiVBTW5zlSGpQsw98k2eyx5dVfIJoNmwLcWOEmCk2+F255UN5yddUrVPq6Tlaf7cHRFn 15z89UUZZTxZjUZxzDQksdCj6Ctvuc5KOzvyKXxU74qKfypZQVYO6b/dHL15r53ulSoh gNwhB4aLhhzSTQgRrgeYC0BKNlz4UiQqO8ziWmNfIhUWopXa23+ngGmTOtqQ6z2/QBdu mCGw31KYocgOd3furRz1ZyxjBl7AbXz0iErkINHYCICo8GqgWzcaHxPJOv/+KZnSUnZK oIFA== X-Received: by 10.14.205.3 with SMTP id i3mr4480731eeo.23.1392217831013; Wed, 12 Feb 2014 07:10:31 -0800 (PST) Original-Received: from [192.168.0.94] (static-nbl2-118.cytanet.com.cy. [212.31.107.118]) by mx.google.com with ESMTPSA id d9sm82013235eei.9.2014.02.12.07.10.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 12 Feb 2014 07:10:30 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4013:c01::22e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:169559 Archived-At: On 12.02.2014 16:26, Stefan Monnier wrote: >>>> One option is to have a hook that takes a (POS . PPSS) pair, which >>>> syntax-ppss intends to use as a starting point for parsing, and return >>>> a new such pair to use instead, where the returned position should >>>> always be >= POS. >> A problem: suppose point is in a primary mode region, and POS is >> in a submode region above it. Then we can't use the value of PPSS at all. > > I don't understand the problem. Of course your hook would return > a completely different PPSS to use along with the new buffer position > from where to start parsing. How would it calculate the returned PPSS? If the PPSS passed in is in a submode region, the primary mode won't be able to use its value. And the hook won't have access to earlier cached values. Or would it? Or course, if the cache includes NEXT-BOUNDARY information, this situation should never happen. This'll have to be handled in the new `syntax-ppss' cache lookup logic. >> Does the hook re-scan the buffer from the beginning? > > I don't understand the question. If we don't have a cached value we can use, we have to `parse-partial-sexp' from the beginning of the buffer.