emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Missing features in c-ts-mode


From: Theodor Thornhill
Subject: Re: Missing features in c-ts-mode
Date: Wed, 15 Feb 2023 21:21:45 +0100

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Theodor Thornhill <theo@thornhill.no>
>> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]