From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Theodor Thornhill Newsgroups: gmane.emacs.devel Subject: Re: Missing features in c-ts-mode Date: Wed, 15 Feb 2023 21:21:45 +0100 Message-ID: <87y1oy65nq.fsf@thornhill.no> References: <83wn4iajyy.fsf@gnu.org> <87fsb67pfj.fsf@thornhill.no> <83lekyagwy.fsf@gnu.org> <87a61e7n5j.fsf@thornhill.no> <838rgyae6z.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19598"; mail-complaints-to="usenet@ciao.gmane.io" Cc: casouri@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Feb 15 21:22:39 2023 Return-path: Envelope-to: ged-emacs-devel@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 1pSOIZ-0004tL-9P for ged-emacs-devel@m.gmane-mx.org; Wed, 15 Feb 2023 21:22:39 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pSOHp-0007eS-T3; Wed, 15 Feb 2023 15:21:53 -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 1pSOHo-0007cZ-E8 for emacs-devel@gnu.org; Wed, 15 Feb 2023 15:21:52 -0500 Original-Received: from out-127.mta0.migadu.com ([91.218.175.127]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pSOHm-0008Ex-4H for emacs-devel@gnu.org; Wed, 15 Feb 2023 15:21:52 -0500 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thornhill.no; s=key1; t=1676492507; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=McpFNOucLVEUp7stVOLZnnNR00Hwqg/CNF4ey8oAZLw=; b=qNgJTr0NoElTBKwkstSXkK7gDyfTqnqD4zHTHmXSvyEPcKQvOarmS1ZK6ft03f3MycKLrz cIbmm0LVes8a3PekEZL0zcgYmkMeNwHD/Xj6JPLqO8jq/NN05BFNtsue0FQmE3AIdbLCwa Lc46LBoVJYxo1ilJ7+m2jt5zrgtHuWs/0D0fMAcTDMpdxXnLoej/GgYDQopMyqMrHd+LEi n6RR/S2vyu9lIDQLOPCsMFtTZHU23LwFOM0w8pAps9WIYYCVsVmvt6/9TYwzV6OiV+bPBc aLqkBMgcPLokKHrSHLscybve5BsDmlJ5vfYSgIin/MI0Odl+Vpzfp5HQMUFQmQ== In-Reply-To: <838rgyae6z.fsf@gnu.org> X-Migadu-Flow: FLOW_OUT Received-SPF: pass client-ip=91.218.175.127; envelope-from=theo@thornhill.no; helo=out-127.mta0.migadu.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:303344 Archived-At: Eli Zaretskii writes: >> From: Theodor Thornhill >> Cc: casouri@gmail.com, emacs-devel@gnu.org >> Date: Wed, 15 Feb 2023 20:18:32 +0100 >> >> >> Isn't M-a and M-e available on master? >> > >> > Maybe, I didn't look there, sorry. If they work there, then this one >> > is fine. >> > >> >> They should be there, but they may need tweaking. Let me know if they >> behave unexpectedly. > > Hmm... they behave...strangely. > > Visit dispnew.c, turn on c-ts-mode, then go to line 174. Type M-a and > watch in disbelief where it goes. Same surprise if you type M-e. > Conclusion: preprocessor directives seem to drive this feature crazy. > Hmm, I cannot find any preproc directives there, but I think I understand what you mean anyway. > OK, so let's find a place without cpp directives. Go to line 368: > > static void > adjust_glyph_matrix (struct window *w, struct glyph_matrix *matrix, int x, int y, struct dim dim) > { > int i; > int new_rows; > bool marginal_areas_changed_p = 0; > bool tab_line_changed_p = 0; <<<<<<<<<<<<<<<<<<<< > bool tab_line_p = 0; > > Position point in the middle of the line and press M-a -- point goes > to the first non-blank character of the line: good. Now type M-a > again -- point goes to the first non-blank character of the _previous_ > line: why? Likely because that is the beginning of the "first" previous node covered by the regexp. Is that unexpected? > > Now go to line 382: > > if (w) > { > window_box (w, ANY_AREA, 0, 0, &window_width, &window_height); > > tab_line_p = window_wants_tab_line (w); > tab_line_changed_p = tab_line_p != matrix->tab_line_p; <<<<<<<<<<<<<<< > > header_line_p = window_wants_header_line (w); > header_line_changed_p = header_line_p != matrix->header_line_p; > } > matrix->tab_line_p = tab_line_p; > > Position point anywhere inside that line and press M-a -- point goes > to the "if" that encloses this block: why? Moreover, if you go to the > first line _after_ the braces, the one which begins with "matrix->", > and press M-a, point still goes to that "if": why? > > C-M-f also appears broken: I cannot get it to move from an opening > brace to the matching closing brace -- instead, it goes to the closing > parenthesis of some inner expression. For example, try C-M-f here: > > else > { > /* If MATRIX->pool is null, MATRIX is responsible for managing > its own memory. It is a window matrix for window-based redisplay. > Allocate glyph memory from the heap. */ > if (dim.width > matrix->matrix_w > || new_rows > || tab_line_changed_p > || header_line_changed_p > || marginal_areas_changed_p) > { > struct glyph_row *row = matrix->rows; > Yeah, this is the same bug as in a different bug report, bug#61374. I didn't get to it yet, apologies! > Place point at the opening brace after "else" and type "C-M-f" -- > point goes to the closing paren after "marginal_areas_changed_p". > > So this "needs work", I'd say ;-) Hehe yeah. Thanks! I'll check if just tweaking the regexps is enough, but likely we need something more in the code dealing with this too. Thanks for the detailed report though, now I have some clear expectations to devise tests from. Theo