> On Nov 18, 2022, at 2:34 PM, Philip Kaludercic <philipk@posteo.net> wrote: > > Jostein Kjønigsen <jostein@secure.kjonigsen.net> writes: > >> Instead of waiting for "every" major-mode to be re-implemented into a >> tree-sitter derivative in the feature/tree-sitter branch before we >> merge... How about we just accept the current "core" tree-sitter >> implementation as good enough, and consider merging that to git master >> as is. > > I think this sounds like a good idea -- as someone who has mostly just > been following the discussions. The core bindings and major modes that > are based on these are separate issues, with a clear dependency linked > them. > > As an aside: This might also be a good opportunity to clean up some of > the current major mode implementations and make them more consistent. > The issue with custom options to enable tree-sitter for every major mode > has revealed an inherent duplication of features. There are other > inconsistencies, especially regarding bindings for equivalent operations > (e.g. in interpreted language with a repl, how to load function into the > current session: Lisp, Prolog, Python all differ in minor details). Iâve though of this too, other things are indent level, and documentation. I wrote ghelp[1] to get a uniform interface for getting documentation in different major modes (because I donât have the heart to understand and modify help.el). A builtin, unified documentation system would be nice, like eldoc. But eldoc is for at-point short and quick signature/doc more than for full-fledged documentation like help.el. > I can imagine a more specialised `define-generic-mode' could be of use > here, along with more "abstract" major modes for various types of > programming languages (using `prog-mode' as a base to add > `compiled-prog-mode' that has generic commands for building program, > `interpreted-prog-mode' that has generic commands for REPL > communication, ...), where the tree-sitter configuration would be one of > the attributes these modes would specify. Sounds nice. Though what do you mean by âone of the attributesâ? >> How about it? Are there any good arguments for NOT merging >> feature/tree-sitter at this point? :) > > The current branch has major modes, should these be deleted before > merging? I think they can stay, weâll work on them and improve them before branch is cut. Yuan
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4