From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: Overlay mechanic improvements Date: Sat, 20 Sep 2014 09:21:02 -0400 Message-ID: References: Reply-To: rms@gnu.org NNTP-Posting-Host: plane.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: ger.gmane.org 1411219499 27100 80.91.229.3 (20 Sep 2014 13:24:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 20 Sep 2014 13:24:59 +0000 (UTC) Cc: emacs-devel@gnu.org To: Vladimir Kazanov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 20 15:24:54 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 1XVKej-0008UW-Em for ged-emacs-devel@m.gmane.org; Sat, 20 Sep 2014 15:24:53 +0200 Original-Received: from localhost ([::1]:34610 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XVKej-0005fe-1Y for ged-emacs-devel@m.gmane.org; Sat, 20 Sep 2014 09:24:53 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43849) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XVKe5-0004X3-Ry for emacs-devel@gnu.org; Sat, 20 Sep 2014 09:24:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XVKe4-0004cs-1P for emacs-devel@gnu.org; Sat, 20 Sep 2014 09:24:13 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:47196) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XVKe3-0004bw-V4 for emacs-devel@gnu.org; Sat, 20 Sep 2014 09:24:11 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1XVKb0-0006SR-TO; Sat, 20 Sep 2014 09:21:02 -0400 In-reply-to: (message from Vladimir Kazanov on Sat, 20 Sep 2014 11:08:27 +0300) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e 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:174579 Archived-At: [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] The problem here is that tokens are not just lexemes(token text). To be general and granular enough one also has to remember dependencies between tokens. So, a token is: ["lexeme", lookback, lookahead, position]. Ok, but why is it a "problem"? It seems easy enough to construct a list (LEXEME LOOKBACK LOOKAHEAD) and put it as the value of the `token' property for all the characters in the token. There is no need to include POSITION in this list, since you can find the start of the token by calling `previous-char-property-change'. > All I need > is an ability to save position pairs, the positions should survive text > insertion/deletion > > I see multiple meanings for that; could you clarify? I mean something like relative positioning of markers/overlays: changes in unrelated buffer parts should change positions accordingly. Text properties do that. Yes, properties do survive copying, but token context might change and the whole thing will have to be reparsed anyway. If it needs to be reparsed, that's no problem; it is easy to delete the `token' property from a region. In fact, we can specify automatic deletion of a certain text property from text copied into the buffer. But there are many cases where it does not need to be reparsed. If you can detect such cases, and reparse only near the boundaries, it would be a nice optimization for cases like killing a whole function and yanking it between two other functions. You could use `yank-handler' to hook this in. It would check whether the existing parsing of the text being yanked fits the new context; if so, it would preserve the `token' property; if not, it would erase the `token' property of the yanked text and cause it all to be reparsed. Another idea: even if the beginning of the yanked text has to be interpreted differently in the new context, maybe tokens later on in the yanked text will still be right in the new context. If you can detect when this happens, you might be able to skip reparsing of some of the yanked text. That could be a substantial speedup. Citing the "Special properties" documentation page for text properties: "you can't predict how many times the function will be called". One can imagine a workaround for this, but it would be just too cumbersome. If you put a timestamp into the token data structure, it will be easy to detect duplicate calls, and make them do nothing. I think it would be less work to change text properties to give you whatever interface features are convenient, than to redesign how overlays are stored. After all overlays do have to be fixed anyway. Why so? Aside from not being suitable for this use, what is wrong with overlays that needs to be fixed? The feature you want to implement is very useful, and we should provide the low-level support needed to make it clean and fast. But if that is easy to do with text properties, let's do it with text properties. -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use Ekiga or an ordinary phone call.