From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#59468: 29.0.50; c-ts-mode cannot fontify after macros are encountered Date: Thu, 24 Nov 2022 08:36:13 +0800 Message-ID: <87v8n5194y.fsf@yahoo.com> References: Reply-To: Po Lu Mime-Version: 1.0 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="18411"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 59468@debbugs.gnu.org To: Yuan Fu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Nov 24 01:37:18 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 1oy0Ew-0004f2-Bz for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 24 Nov 2022 01:37:18 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oy0Ei-0001ol-W3; Wed, 23 Nov 2022 19:37:05 -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 1oy0Eh-0001oV-77 for bug-gnu-emacs@gnu.org; Wed, 23 Nov 2022 19:37:03 -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 1oy0Eg-0004LJ-Ns for bug-gnu-emacs@gnu.org; Wed, 23 Nov 2022 19:37:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oy0Eg-0007QM-DN for bug-gnu-emacs@gnu.org; Wed, 23 Nov 2022 19:37:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Po Lu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 24 Nov 2022 00:37:02 +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.166925019728504 (code B ref 59468); Thu, 24 Nov 2022 00:37:02 +0000 Original-Received: (at 59468) by debbugs.gnu.org; 24 Nov 2022 00:36:37 +0000 Original-Received: from localhost ([127.0.0.1]:56695 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oy0EG-0007Pf-B2 for submit@debbugs.gnu.org; Wed, 23 Nov 2022 19:36:36 -0500 Original-Received: from sonic303-22.consmr.mail.ne1.yahoo.com ([66.163.188.148]:44833) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oy0ED-0007PO-1m for 59468@debbugs.gnu.org; Wed, 23 Nov 2022 19:36:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1669250187; bh=p1C2+YxmMKmUqkFEvogbBWi8vN2K33mzBPSU+DgzN88=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=VPrDTUWPlRvLJS5QavvNAAxeKcLIGVXKL8rVXeF8B5wufLhnjdlXecHVYhFQy5pnoXnj0Q5NP9aCb9qksTGOkXgn8v3wZGO2PmxOeOkmSD+1BkRF9KhHHsJB1bAEtV1seG2vsFjuT++PyD8qCK99bnIJ711FjqygBl8JLiPsDBM4ejMy5BzrSBN4S2vRPW6U70Sf3Jg7T8XAG0Zele9M2mRtRKM4b4DCB/bxzUrhZsE0DdM/5UcMBvEWf8v5j2ym6Djoao/+DE/0orlqL8b4uyc5FxWeqtX27wVLw2b4auJIPl8i4lv6JbQQXwaDrgipdEDFf2imPqO8/6Y+q4+PIw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1669250187; bh=slDDy4BgClYmO2VxjMsR/ckbcr5TI9OpwQFAv2ZcVsl=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=AM3Fbt+o4QzQMgO5pA0Er1GLrz1VxhIxPgEZ14rFjKPpcda38fudvhhc33iF8JvxY7DwmaMyVTu4c+BfYZql58Y45A+BsWlwAdLF5xjVnadxsBy6tKUkWIc0+A7V/4CQYWE5DWw4f69wrz0SAzGoBWS8Mu7TYR4YDmdez9rsD8byyyrAWKQhARu1TyFyjGONOQKowm3m5IKwzSaxkxzVZZ5otKYMBVyzBhB2YhrZWIwczOsx+AGyp404vEsgBMylFrdK1H7x1Wh2C/CxOaGiG+A7EPviH8FHhZl0MKdOsERHd8IymjEJypLboz7uH838pt3yTmXlkIR0tHjAahrdPg== X-YMail-OSG: lnj7kJkVM1nf254IaTHLcFoblJOLc0zzuZ8Mhk6HD011PZt60VH4FVdws8cMABG kWvu0FBBgLgSUyuTEc9_12IZxHl2NkyUai.nuEpgsmYY5MQauVvaEpS3Hs_emnT7l_WiPl5EJTEu DgNjr7X0_d7F48PwOENeKt4LBMsr7Hidom9qKk.xEOUoOgx79fInfAf6ERrse_wPGUv4e7K_t5gX 2I_8Ah0cXeCpHoJhXy_yZwZJQ0Xdn8jBXVccFQooDDPWHWJIHHDdoUz4C2qyDcJXulLlNHk_LwE. KMG0HaV0pslotkoTWDdSI7bkOhU0Vr4.1Q7XnUeawvoGNRfCch.01mShzORtMzRYAvTyTiD__kRu ANKBHZFEFf2FRAZ6B80IqcJMypsbHhYs_JQWA4Y22dW4NBxssIHViI67aeY0DiAnARg3yCu7zPbU _0IDw9Bw3MK7hTGT9nN78ImgyKPpPU.nwRqVgvLsnroKZxN1HRD0m33_kHe98FS.kwJi2xEHHcFR ogDuBYF8nNp8UUNv2x2YDArn5xvawGMzg3DoCsgsrK3x1Vkb6o4BZgKNNWfLoy0rYRaIc7hBPjAv PaN0e04VHIW7iGjqhwX8oUbu.K1vL13xOmlFRT6hKNgu1K7B.aPmaZlIWbfbX7TowemzvA3LOApn rGDAX0EClq8RziynYrPTsAD..DgV9fWlzSgOQRpGf8y1ro6.SadHZkJJhCUf9k2oGcZIqZNInRR6 lQyrk5Ry3iJ0J2Hcz9dcsYmI634eAHBiykPiKuls2V56Wr81bz45xwg5bBHLr.KcKW3S1yNnwYBm FlLRW6qoD.dAXimPKlzvisPEWCNYJadwpWEdmC_Bj7 X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.ne1.yahoo.com with HTTP; Thu, 24 Nov 2022 00:36:27 +0000 Original-Received: by hermes--production-sg3-6c8895b545-pb7wm (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 454bde5c3b64741397e6e04d3feec55a; Thu, 24 Nov 2022 00:36:19 +0000 (UTC) In-Reply-To: (Yuan Fu's message of "Wed, 23 Nov 2022 16:03:40 -0800") X-Mailer: WebService/1.1.20863 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo 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:248799 Archived-At: Yuan Fu writes: > 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 sourc= e. > > >> 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 someon= e 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. L= ike 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) a= fter > 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. This is valid C. PRIuFAST64 is a standard macro containing the format specifier for a uint_fast64_t. > 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. Maybe you scrolled up the file instead of down? That sometimes matters. > 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 t= o 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. Can't #ifdef simply not be passed to tree-sitter, if it is so bad at understanding them?