bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#56796: 29.0.50; Hard newlines not respected in code comments?


From: Visuwesh
Subject: bug#56796: 29.0.50; Hard newlines not respected in code comments?
Date: Fri, 29 Jul 2022 21:46:16 +0530
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

[வெள்ளி ஜூலை 29, 2022] Stefan Monnier via "Bug reports for GNU Emacs, the Swiss 
army knife of text editors" wrote:

>> More generally: I'm not sure how common this pattern is but I tend to do
>>
>>     ;; TODO/FIXME: Something...
>>     ;; Ideas and thoughts on how to clear it here.
>>
>> Now if you do M-q there, your neatly arranged text is destroyed.  (I am
>> probably biased) I also catch this pattern in the Emacs source tree as
>> well.
>
> It never occurred to me to use hard newlines for such cases.  What I use
> instead is either:
> - add extra newlines to mark the paragraph boundaries to use
>   (that's just as easy as adding hard newlines, but requires removing
>   those extra newlines afterward).

This is what I did but frankly I am really tired of this pattern since
when you go back to revise the text, you have to do the thing yet again.
(Granted, you only avoid this when you haven't killed the buffer or
Emacs but we don't do that here, do we?  ;-)

> - Select the intended paragraph rather than rely on M-q's automatic
>   decision of what's a paragraph.

I always forget that M-q takes an active region, this is a viable option
as well.  I think the first option is quicker though.

> Hard newlines are a good idea, for this use-case, indeed, tho it would
> be even better if we could somehow represent that info in the text
> itself so it's properly saved into the file.

You're not the first one: 
https://yhetil.org/emacs-devel/CAArVCkQHmwqHvcOEurBYLcWS74nov8OAH4fnX8XbUr2JY2nCKA@mail.gmail.com/

[வெள்ளி ஜூலை 29, 2022] Stefan Monnier via "Bug reports for GNU Emacs, the Swiss 
army knife of text editors" wrote:

>> But maybe me using hard newlines to tame adaptive-fill-mode is the wrong
>> approach: I would like to write lists such as
>>
>>     . blah blah blah
>>     . blah blah blah
>
> I'm not sure "." should be accepted by default, but...

Indeed, it's a bit too "out there" if you know what I mean.

>> I can't blame adaptive-fill-mode for it: it can only be ever so smart
>> and hard newlines seemed like the solution for "when I say newline, I
>> MEAN IT".
>
> I do think it's worth a bug report, because we should handle at least
> some "common" cases of itemized lists in ELisp comments, and AFAIK we
> currently don't handle any at all.

When I was searching for discussions on adaptive-fill-mode in
emacs-devel to make sense of it, I found the past you agreeing with me
in the wild.  The discussion can be found here: 
https://yhetil.org/emacs-devel/jwvk5wvx5jv.fsf-monnier+emacs@gnu.org/
but I'm not sure what happened afterwards.  Hmm... but now that I
re-read it, it is not the same problem but it is a problem that
often bites me in the back.





reply via email to

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