Hi Uwe,

If you think it is useful, then feel free to turn that error into a warning.

A problem with the algorithm is it doesn’t plan ahead.  It tries to break at 
the fill-column, and if that happens to be at the beginning of a string, then 
the resultant split adds some syntax to re-assemble the broken string.  Once 
you do that, the remaining string can’t be re-broken b/c the words may be too 
long.   There are a series of other similar problems like this for different 
kinds of syntaxes.

The reason it used to “work” is because it treated a line as all comment even 
if it was an end-of-code comment.  To treat it correctly, I needed to treat the 
beginning as code.  Ie – need to fill the code in order to get the comment 
close enough to the fill column that it will be fillable.  That’s why comments 
would fill erratically sometimes.

There is lots of room to make the algorithm a bit better, but like I said, it 
needs a deeper heuristic.  Maybe tweaking matlab-fill-fudge will help.  I 
haven’t worked on this bit in a long time to remember how it all works.

Eric

From: Uwe Brauer <o...@mat.ucm.es>
Sent: Monday, July 31, 2023 11:57 AM
To: Eric Ludlam <elud...@mathworks.com>
Cc: Uwe Brauer <o...@mat.ucm.es>; Matlab-emacs-discuss 
<matlab-emacs-discuss@lists.sourceforge.net>
Subject: Re: the filling patch and its problems

>>> "EL" == Eric Ludlam <elud...@mathworks.com<mailto:elud...@mathworks.com>> 
>>> writes:

> Is anyone out there interested in the "code fill" feature?

You mean besides me 😇 I do hope so!


> It was a hairy thing to implement back in the day, and most of the
> feedback I got was "how do I turn this off?" It is likely easier to
> drop the feature than figure out how to fix it for all cases.

I cannot judge this and I don't want to cause you headaches.

However I can tell you that code that is written with the native matlab
editor (say by my students) tend to have these enormous comment lines as
in the files


fill_prob2.m
fill_prob.m

So filling these lines would help me quite a bit and I thought emacs
users sharing code with those using the native editor might face similar
problems.


The thing that puzzles me:

in commit 0f305501f26d633048c83a89b6652db169394a3f
that line filling problems seemed to be solved

But in the last two commits it throws an error.

So what changed and can't we just go back?


> Basically, it isn't hard to create a line of code it can't fill, in
> which case it throws this error. Maybe a warning is better?

Yes I think so.

Uwe
--
Warning: Content may be disturbing to some audiences
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military.
I support the NATO membership of the Ukraine.
I support the EU membership of the Ukraine.
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/<https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view>
_______________________________________________
Matlab-emacs-discuss mailing list
Matlab-emacs-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matlab-emacs-discuss

Reply via email to