[Top][All Lists]

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

Re: How to add pseudo vector types

From: Richard Stallman
Subject: Re: How to add pseudo vector types
Date: Thu, 29 Jul 2021 20:35:33 -0400

[[[ 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. ]]]

  > s two options to convey this change to the tree-sitter parser: 1)
  > it does not, then tree-sitter still thinks the buffer is AA,
  > essentially the portion where tree-sitter sees is pushed forward
  > by one character, 2) it tells tree-sitter the user inserted a
  > character at the beginning, then tree-sitter thinks the buffer is
  > BAA.

  > Which option is correct depends on how does lisp later narrows: if
  > lisp narrows to AA, then option 1 is correct, if lisp narrows to
  > BAA, then option 2 is correct. But how do we know which option is
  > correct before lisp narrows?

I suggest we create a way for the program to declare the purpose for
each instance of narrowing.

I know of two kinds of purposes for using narrowing.

1. To focus operations on syntactic entity in a buffer containing
other things which are essentially unrelated.  Let's call this "semantic" 

For instance, when Rmail narrows the file buffer to just one message,
that is semantic narrowing.  Whatever is outside the buffer bounds is
unrelated to parsing the current message.

2. To show just part of the text you're looking at.  This is a display
feature, usually temporary, and would be enabled or disabled by the
user.  Let's call it "display" narrowing.

I don't think Emacs can tell heuristically which kind of narrowing a
program is doing.

I propose we create a way for Lisp programs to declare when they do
semantic narrowing.  They could specify markers for the beginning and
end of that narrowing.

Facilities for parsing the buffer should heed semantic narrowing but
disregard display narrowing.

Various kinds of semantic narrowing should be able to nest, and
display narrowing should be able to nest inside semantic narrowings.

Comments or critiques?

Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

reply via email to

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