unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Lynn Winebarger <owinebar@gmail.com>
Cc: acm@muc.de, gregory@heytings.org, larsi@gnus.org, emacs-devel@gnu.org
Subject: Re: New optimisations for long raw strings in C++ Mode.
Date: Fri, 12 Aug 2022 16:18:01 +0300	[thread overview]
Message-ID: <835yixob1y.fsf@gnu.org> (raw)
In-Reply-To: <CAM=F=bCCPL3n_F=xcVtPQoxiDwC9hwKQhsOSM4H0CcpX1oJFmg@mail.gmail.com> (message from Lynn Winebarger on Fri, 12 Aug 2022 09:05:06 -0400)

> From: Lynn Winebarger <owinebar@gmail.com>
> Date: Fri, 12 Aug 2022 09:05:06 -0400
> Cc: Alan Mackenzie <acm@muc.de>, gregory@heytings.org, Lars Ingebrigtsen <larsi@gnus.org>, 
> 	emacs-devel <emacs-devel@gnu.org>
> 
>  Really?  Then please tell me how is it that we the humans can detect
>  incorrect fontifications even when shown partial strings and comments?
>  We know that fontifications are incorrect, and where strings or
>  comments start or end immediately, just after a single glance.  We
>  never need to go to BOB to find that out.
> 
> Serious question: is fontification intended to display text according to what the author probably intended, or
> according to how a compiler will process that text (leaving correctness to a more precise tool than font-lock,
> whether Semantic, tree-sitter, LSP, whatever)?

I fail to see how this question is relevant to the issue at hand,
which is what should be the behavior of fontification functions in
very large files and files with very long lines.

> Because I can definitely write code that has some subtle issue that I will miss, and erroneously think should
> display one way but which would be processed in a different way.  Should fontification show my likely
> intention (plus, and only for bonus points, possibly highlight the error that disconnects the likely intended from
> the actual parse), or should it display according to the way the tools will interpret it so the author will find
> errors that way? 

Ideally, the latter.  But not at a prise of making moving through and
editing the file impractical.

> When I use a dedicated IDE of recent vintage, it feels  less like I am writing a stream of characters than filling
> in partially constructed objects representing the abstract syntax of the language I'm writing in (with grammar
> that has allowances for incomplete or erroneous constructs), with the text being displayed as a
> representation of the underlying object.  IOW, the relationship of the syntactic object and the text is inverted
> compared to emacs's design, where (if I understand correctly) the properties of the syntactic object are only
> tied to the text through text properties.  With the other approach, the fontification and the syntax object are
> tied together, but with emacs the relationship seems much more tenuous. E.g. completion and fontification
> are completely separate activities as far as I know, though the same contextual information should be useful
> for both activities.

That is correct, for the current Emacs design.

> If CC mode is determining more syntactic information than tree-sitter's incremental parsing provides (per
> Immanuel Lizroth's comment in this thread)

I don't think this is true, FWIW.



  reply	other threads:[~2022-08-12 13:18 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-06 21:29 New optimisations for long raw strings in C++ Mode Alan Mackenzie
2022-08-07 12:49 ` Lars Ingebrigtsen
2022-08-07 13:25   ` Alan Mackenzie
2022-08-07 13:34     ` Lars Ingebrigtsen
2022-08-07 14:40       ` Alan Mackenzie
2022-08-07 14:41         ` Lars Ingebrigtsen
2022-08-07 14:54         ` Lars Ingebrigtsen
2022-08-07 16:13           ` Alan Mackenzie
2022-08-07 16:17             ` Eli Zaretskii
2022-08-09 11:00               ` Alan Mackenzie
2022-08-09 15:35                 ` Lars Ingebrigtsen
2022-08-09 15:38                   ` Lars Ingebrigtsen
2022-08-09 16:05                     ` Alan Mackenzie
2022-08-09 16:34                       ` Eli Zaretskii
2022-08-09 20:39                         ` Gregory Heytings
2022-08-09 21:43                           ` Alan Mackenzie
2022-08-09 23:05                             ` Stefan Monnier
2022-08-10  2:43                               ` Eli Zaretskii
2022-08-10  7:42                             ` Gregory Heytings
2022-08-10 13:28                             ` Eli Zaretskii
2022-08-10 16:23                               ` Alan Mackenzie
2022-08-10 16:35                                 ` Eli Zaretskii
2022-08-10 16:50                                   ` Alan Mackenzie
2022-08-10 16:58                                     ` Eli Zaretskii
2022-08-10 17:32                                       ` Alan Mackenzie
2022-08-10 17:41                                         ` Eli Zaretskii
2022-08-10 22:31                                           ` Stefan Monnier
2022-08-11  6:21                                             ` Eli Zaretskii
2022-08-11  7:37                                               ` Stefan Monnier
2022-08-11  6:27                                             ` Immanuel Litzroth
2022-08-11 16:54                                           ` Alan Mackenzie
2022-08-11 17:15                                             ` Eli Zaretskii
2022-08-12 13:05                                           ` Lynn Winebarger
2022-08-12 13:18                                             ` Eli Zaretskii [this message]
2022-08-11 15:47                                         ` Yuri Khan
2022-08-11 16:04                                           ` Eli Zaretskii
2022-08-10 17:19                                 ` Gregory Heytings
2022-08-10 17:21                                   ` Eli Zaretskii
2022-08-10 19:45                                   ` Alan Mackenzie
2022-08-14 20:15                                     ` Alan Mackenzie
2022-08-15  8:00                                       ` Gregory Heytings
2022-08-10 13:25                     ` Eli Zaretskii
2022-08-12 12:44                       ` Lars Ingebrigtsen
2022-08-12 12:52                         ` Eli Zaretskii
2022-08-07 15:00         ` Eli Zaretskii

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=835yixob1y.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=acm@muc.de \
    --cc=emacs-devel@gnu.org \
    --cc=gregory@heytings.org \
    --cc=larsi@gnus.org \
    --cc=owinebar@gmail.com \
    /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).