From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Yuan Fu Newsgroups: gmane.emacs.bugs Subject: bug#59468: 29.0.50; c-ts-mode cannot fontify after macros are encountered Date: Wed, 23 Nov 2022 16:03:40 -0800 Message-ID: References: <87k03n4v0r.fsf@yahoo.com> Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23378"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 59468@debbugs.gnu.org To: Po Lu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Nov 24 01:04:25 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oxzj7-0005sM-Ct for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 24 Nov 2022 01:04:25 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oxzim-0004AO-Dl; Wed, 23 Nov 2022 19:04:04 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oxzik-0004A5-88 for bug-gnu-emacs@gnu.org; Wed, 23 Nov 2022 19:04:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oxzij-0003lR-V6 for bug-gnu-emacs@gnu.org; Wed, 23 Nov 2022 19:04:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oxzij-0006aX-Qg for bug-gnu-emacs@gnu.org; Wed, 23 Nov 2022 19:04:01 -0500 X-Loop: help-debbugs@gnu.org In-Reply-To: <87k03n4v0r.fsf@yahoo.com> Resent-From: Yuan Fu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 24 Nov 2022 00:04:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59468 X-GNU-PR-Package: emacs Original-Received: via spool by 59468-submit@debbugs.gnu.org id=B59468.166924823425305 (code B ref 59468); Thu, 24 Nov 2022 00:04:01 +0000 Original-Received: (at 59468) by debbugs.gnu.org; 24 Nov 2022 00:03:54 +0000 Original-Received: from localhost ([127.0.0.1]:56662 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oxzib-0006a5-Fz for submit@debbugs.gnu.org; Wed, 23 Nov 2022 19:03:54 -0500 Original-Received: from mail-pl1-f172.google.com ([209.85.214.172]:46843) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oxziW-0006Zp-TI for 59468@debbugs.gnu.org; Wed, 23 Nov 2022 19:03:52 -0500 Original-Received: by mail-pl1-f172.google.com with SMTP id jn7so16186737plb.13 for <59468@debbugs.gnu.org>; Wed, 23 Nov 2022 16:03:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:cc:date:message-id:subject:mime-version :content-transfer-encoding:from:from:to:cc:subject:date:message-id :reply-to; bh=JyLkpSumc2JEijw1+Nf+p/raMMAHNklTdZwJqE1YZUM=; b=SKtf4rrseO5+Bt1gqX2fTjhxQFefYH3970GMAD9tf/uRWjNo0N1TWEIW8qK5NIt9f/ oZSe42alBHAOGzGSAt5eogrVj1y9G0nJQudummlXOkuLiVTHYTlZZYjg6Jh7vLTBZtx2 CPu8nDVAsMZ0nJEFJK+VVzD/9ZdFKjJd7FUhkP8nnTfYbBESI5T2H1vd+SBCSk9Z5saP 3bXfy9PHuVWELXcsfJf2vEYfVOvo87UZO9F3Fzngv0vhs4rtuDrKPfvxRxdhBMNgddMS +dkYRcz8jY6t1yKzZmIa0BpADeANMqPee1CiqMPXkzE3T3/4tCnN9N+p9efIpAxuXHdE OP0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:cc:date:message-id:subject:mime-version :content-transfer-encoding:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=JyLkpSumc2JEijw1+Nf+p/raMMAHNklTdZwJqE1YZUM=; b=o0sH3nRn+5epNahPrR8Fdxj/nFP2yMxwFs7cUlPjqt5TTa2ok4zc8QVWyEQED3t2NI juFfKrJsK0xqtA0adMziu89y2sp12jd28p8PAVQ0ymQe4wgL2iq/h9la8mQXdQipFAm4 LDFtVxWmrcT04w5+WsCLcaikeVX/P3yYjHvF4WvhbUydWOej9Fe7etTeBblcSEPmyveT WOi+0OcnvtiCI9ui9DjEuwbuU1wTt3Xlia/AD+VDrxU0gDjOCp3+/Vp/n+6XBe5UvuMn gN0X8s4vE5cE08f0r/m4vGiJSpvR2DZH/jx93/nTN8HgKGdnFW21uoSuQSokuTGRagqD tYCQ== X-Gm-Message-State: ANoB5pnz2xRVWyHq/Qx4NLoOEH4uyK+bV/EQqqmud7tI43AFIPbVU7bJ hRj+/Cg5sRWfLBIfYTCsg5E= X-Google-Smtp-Source: AA0mqf7DYr+SRE7DvN2UxywboA6+MSFhuqzJNO/jZ+dHu6zLZW6XXlWQrRmC/da7PX4XsTCf4+xDgg== X-Received: by 2002:a17:902:6943:b0:188:ab16:2393 with SMTP id k3-20020a170902694300b00188ab162393mr14203000plt.87.1669248222833; Wed, 23 Nov 2022 16:03:42 -0800 (PST) Original-Received: from smtpclient.apple (cpe-172-117-161-177.socal.res.rr.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id b20-20020a63d814000000b004769983b52csm11135138pgh.19.2022.11.23.16.03.42 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Nov 2022 16:03:42 -0800 (PST) X-Mailer: Apple Mail (2.3696.120.41.1.1) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:248797 Archived-At: Po Lu writes: Ok, I had a look at each of these cases, comments: > Insert the following code in a buffer, and enable c-ts-mode. > > #define CheckExtension(name) \ > if (!name) \ > { \ > if (display) \ > eglTerminate (display); \ > fprintf (stderr, "Missing: egl%s\n", #name + 1); \ > return False; \ > } > > #define CheckExtensionGl(name) \ > if (!name) \ > { \ > /* If the context remains current, then nothing \ > will get released upon eglTerminate. */ \ > eglMakeCurrent (display, EGL_NO_SURFACE, \ > EGL_NO_SURFACE, EGL_NO_CONTEXT); \ > eglTerminate (display); \ > fprintf (stderr, "Missing: gl%s\n", #name + 1); \ > return False; \ > } > > #define LoadProc(name, ext, extname) \ > if (HaveEglExtension (extname)) \ > I##name \ > =3D (void *) eglGetProcAddress ("egl" #name ext) > > #define LoadProcGl(name, ext, extname) \ > if (HaveGlExtension (extname)) \ > I##name \ > =3D (void *) eglGetProcAddress ("gl" #name ext) > > #define CheckGlExtension(name) \ > if (!HaveGlExtension (name)) \ > { \ > fprintf (stderr, "Missing %s\n", name); \ > \ > eglMakeCurrent (display, EGL_NO_SURFACE, \ > EGL_NO_SURFACE, \ > EGL_NO_CONTEXT); \ > eglTerminate (display); \ > return False; \ > } > > There will be no fontification of types or string constants inside the > macro bodies. CC Mode works fine. Tree-sitter right now doesn=E2=80=99t parse the content of macro bodies. = I think it should be reasonable for tree-sitter-c to parse them. In the meantime I=E2=80=99ll see if I can trick tree-sitter to parse it as normal C = source. > Now, insert the following code below the macro definition: > > static Visual * > FindVisual (VisualID visual, int *depth) > { > XVisualInfo vinfo, *visuals; > Visual *value; > int nvisuals; > const char *override; > } > > visual, depth, visuals, value and override are not fontified as > identifiers. Line feed characters below the macros are also fontfied = as > "errors". That should fixed by a recent change. > Within the following code: > > static BufferActivityRecord * > FindBufferActivityRecord (PictureBuffer *buffer, PictureTarget = *target) > { > BufferActivityRecord *record; > > /* Look through the global activity list for a record matching > the given values. */ > record =3D all_activity.global_next; > while (record !=3D &all_activity) > { > if (record->buffer =3D=3D buffer > && record->target =3D=3D target) > return record; > > record =3D record->global_next; > } > > return NULL; > } > > "record" is fontified as an identifier, but not within the condition = in > the while loop. That=E2=80=99s expected, since the font-lock rule is to fontify LHS of assignments (the first record), but not all appearances of identifiers. Now we have font-lock rules that fontifies all occurrences of functions and variables. I personally don=E2=80=99t find them useful, but if = someone wants it it=E2=80=99s there. > > Within the following code: > > static void > compare_single_row_8bpc4 (unsigned char *data, unsigned char *xdata, > size_t size, > struct image_difference_statistics = *statistics) > { > unsigned char channel_a, channel_b; > int diff; > size_t i; > > for (i =3D 0; i < size; ++i) > { > channel_a =3D data[i]; > channel_b =3D xdata[i]; > > diff =3D (int) channel_b - (int) channel_a; > statistics->min_diff =3D MIN (statistics->min_diff, > diff); > statistics->max_diff =3D MAX (statistics->max_diff, > diff); > } > } > > the "i" in "size_t i" is fontified as an identifier the first time, = but > not in future appearances in the function. In the first appearance, i is a declaration, so it=E2=80=99s fontified. = Like the previous case, not all i are declaration or assignment, so they are not all fontified. And now you can enable the "variable" feture to fontify all of them. > > Within src/xterm.c, every appearance of ATOM_REFS_INIT is fontified in > the error face. Also, inside `xm_setup_dnd_targets', > > xm_targets_table_header header; > xm_targets_table_rec **recs UNINIT; > xm_byte_order byteorder; I think tree-sitter isn=E2=80=99t expecting another identifier (UNINIT) = after recs. Here if we don=E2=80=99t enable highlighting errors recs would be highlighted fine, as an identifier. > > "recs" is fontified in the error face. > > recs =3D xmalloc (sizeof *recs); > recs[0] =3D xmalloc (FLEXSIZEOF (struct = xm_targets_table_rec, > targets, ntargets * 4)); > > recs[0]->n_targets =3D ntargets; > > "struct" is fontified in the error face. Within > x_sync_note_frame_times: Tree-sitter thinks FLEXSIZEOF is a function call and struct xm_targets_table_rec is an argument. We can add a heuristic here: (ERROR (identifier)) is either type or struct/enum keyword. I should be able to fix that. > #ifdef FRAME_DEBUG > uint_fast64_t last_frame_ms =3D output->last_frame_time / 1000; > fprintf (stderr, > "Drawing the last frame took: %"PRIuFAST64" ms = (%"PRIuFAST64")\n", > last_frame_ms, time); > #endif > > "PRIuFAST64" is fontified in the error face. Is this valid C? If it it, we should report to tree-sitter-c. If not, we can add a heuristic. Within > x_dnd_begin_drag_and_drop: > > if (x_dnd_movement_frame > /* FIXME: how come this can end up with movement frames > from other displays on GTK builds? */ > && (FRAME_X_DISPLAY (x_dnd_movement_frame) > =3D=3D FRAME_X_DISPLAY (f)) > /* If both those variables are false, then F is no > longer protected from deletion by Lisp code. This > can only happen during the final iteration of the DND > event loop. */ > && (x_dnd_in_progress || x_dnd_waiting_for_finish)) > { > XSETFRAME (frame_object, x_dnd_movement_frame); > > is fontified incorrectly: the "if" is not fontified at all, and the = last > three lines show up in the error faces. It fontifies fine here. I guess it=E2=80=99s fixes by some changes I = made, although I don=E2=80=99t recall making changes related to if statements. > In addition: > > Lisp_Object > x_dnd_begin_drag_and_drop (struct frame *f, Time time, Atom xaction, > Lisp_Object return_frame, Atom = *ask_action_list, > const char **ask_action_names, size_t = n_ask_actions, > bool allow_current_frame, Atom *target_atoms, > int ntargets, Lisp_Object = selection_target_list, > bool follow_tooltip) > > "Lisp_Object" and "x_dnd_begin_drag_and_drop" are not fontified at = all. They are fontified fine here. > Here: > > /* Select for input extension events used by scroll bars. This will > result in the corresponding core events not being generated for > SCROLL_BAR. */ > > MAYBE_UNUSED static void > xi_select_scroll_bar_events (struct x_display_info *dpyinfo, > Window scroll_bar) > > "void" is fontified in the error face. I=E2=80=99ll try to come up with a heuristic. > Here, in handle_one_xevent: > > #ifdef HAVE_XINPUT2 > if (event->type !=3D GenericEvent) > #endif > any =3D x_any_window_to_frame (dpyinfo, event->xany.window); > #ifdef HAVE_XINPUT2 > else > any =3D NULL; > #endif > > the "else" is fontified as a type. The "else" is separated from the "if" in the parse tree by the preprocessor directive, I=E2=80=99ll report this to tree-sitter-c and = see if they can do anything. > > static int > handle_one_xevent (struct x_display_info *dpyinfo, > #ifndef HAVE_XINPUT2 > const XEvent *event, > #else > XEvent *event, > #endif > int *finish, struct input_event *hold_quit) > > the "const XEvent *" is fontified in the error face. Similar to the previous case. There could be better ways to handle ifdef=E2=80=99s in tree-sitter-c, I don=E2=80=99t know if they are easy = to implement. > Here: > > case GraphicsExpose: /* This occurs when an XCopyArea's > source area was obscured or not > available. */ > f =3D x_window_to_frame (dpyinfo, = event->xgraphicsexpose.drawable); > if (f) > { > expose_frame (f, event->xgraphicsexpose.x, > event->xgraphicsexpose.y, > event->xgraphicsexpose.width, > event->xgraphicsexpose.height); > #ifndef USE_TOOLKIT_SCROLL_BARS > x_scroll_bar_handle_exposure (f, (XEvent *) event); > #endif > #ifdef USE_GTK > x_clear_under_internal_border (f); > #endif > #ifdef HAVE_XDBE > show_back_buffer (f); > #endif > } > #ifdef USE_X_TOOLKIT > else > goto OTHER; > #endif /* USE_X_TOOLKIT */ > break; > > "goto OTHER" is fontified in the error face, and "else" as a type. Same as above. > Here: > > #ifdef HAVE_XINPUT2 > if (event->xkey.time =3D=3D pending_keystroke_time) > { > source =3D xi_device_from_id (dpyinfo, > = dpyinfo->pending_keystroke_source); > > if (source) > inev.ie.device =3D source->name; > } > #endif > > "inev" is fontified in the error face. Fontifies fine here, should be fixed. > Here: > > #ifdef USE_GTK > /* See comment in EnterNotify above */ > else if (dpyinfo->last_mouse_glyph_frame) > x_note_mouse_movement (dpyinfo->last_mouse_glyph_frame, > &event->xmotion, Qnil); > #endif > > "else" and "dpyinfo" are fontified as types. Same. > #ifdef USE_MOTIF > Widget widget; > > widget =3D XtWindowToWidget (dpyinfo->display, > event->xbutton.window); > > if (widget && XmIsCascadeButton (widget) > && XtIsSensitive (widget)) > { > #endif > if (!f->output_data.x->saved_menu_event) > f->output_data.x->saved_menu_event =3D xmalloc (sizeof = *event); > *f->output_data.x->saved_menu_event =3D *event; > inev.ie.kind =3D MENU_BAR_ACTIVATE_EVENT; > XSETFRAME (inev.ie.frame_or_window, f); > *finish =3D X_EVENT_DROP; > #ifdef USE_MOTIF > } > #endif > > here, the last closing brace is fontified in the error face. Still, blame #ifdef. I don=E2=80=99t have good ideas for these. > Here: > > static void NO_INLINE > x_error_quitter (Display *display, XErrorEvent *event) > { > char buf[256], buf1[400 + INT_STRLEN_BOUND (int) > + INT_STRLEN_BOUND (unsigned long)]; > > "NO_INLINE" and "unsigned long" are fontified in the error face. I=E2=80=99ll try heuristics. Yuan