bug#20461: 25.0.50; `use-hard-newlines'

bug#20461: 25.0.50; `use-hard-newlines'

[Drew Adams]

Why is this minor mode not named `use-hard-newlines-mode', to respect
the naming convention?

Reading the doc for this function doesn't even offer a clue that this is
a minor mode and that it is not global.

See, for instance, this user's question, which shows that s?he expected
the function to act globally.
http://stackoverflow.com/q/29949975/729907


In GNU Emacs 25.0.50.1 (i686-pc-mingw32)
 of 2015-04-05 on LEG570
Bzr revision: 16eec6fc55dcc05d1d819f18998e84a9580b2521
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --host=i686-pc-mingw32 --enable-checking=yes,glyphs'

bug#20461: 25.0.50; `use-hard-newlines'

[Lars Ingebrigtsen]

Drew Adams <drew.adams@oracle.com> writes:

> Why is this minor mode not named `use-hard-newlines-mode', to respect
> the naming convention?
>
> Reading the doc for this function doesn't even offer a clue that this is
> a minor mode and that it is not global.
>
> See, for instance, this user's question, which shows that s?he expected
> the function to act globally.
> http://stackoverflow.com/q/29949975/729907

I agree.  An objections to renaming to -mode and marking the old name as
an obsolete alias?  (And fixing the doc string.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#20461: 25.0.50; `use-hard-newlines'

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Drew Adams <drew.adams@oracle.com> writes:
>
>> Why is this minor mode not named `use-hard-newlines-mode', to respect
>> the naming convention?
>>
>> Reading the doc for this function doesn't even offer a clue that this is
>> a minor mode and that it is not global.
>>
>> See, for instance, this user's question, which shows that s?he expected
>> the function to act globally.
>> http://stackoverflow.com/q/29949975/729907
>
> I agree.  An objections to renaming to -mode and marking the old name as
> an obsolete alias?  (And fixing the doc string.)

I agree as well.  No protests within 4+ years could be taken as a sign
that no one minds the change.

Best regards,
Stefan Kangas

bug#20461: 25.0.50; `use-hard-newlines'

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

>> I agree.  An objections to renaming to -mode and marking the old name as
>> an obsolete alias?  (And fixing the doc string.)
>
> I agree as well.  No protests within 4+ years could be taken as a sign
> that no one minds the change.

I had another peek at this, and use-hard-newlines is slightly unusual
in that many functions bind the use-hard-newlines (and use it), like:

(defun fill-flowed-encode (&optional buffer)
[...]
    (when use-hard-newlines

So we'd presumably need to rename the variable, too, and then it just
seems like it's not worth it, really.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#20461: 25.0.50; `use-hard-newlines'

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> So we'd presumably need to rename the variable, too, and then it just
> seems like it's not worth it, really.

I see, yes then it might be better to just leave it alone.

I guess the doc string still need fixing to say it only affects the
current buffer though.  That is perhaps important enough to go on the
first line, but I couldn't come up with a way to do that which doesn't
go over the 67 character limit.

Best regards,
Stefan Kangas

bug#20461: 25.0.50; `use-hard-newlines'

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

> I guess the doc string still need fixing to say it only affects the
> current buffer though.  That is perhaps important enough to go on the
> first line, but I couldn't come up with a way to do that which doesn't
> go over the 67 character limit.

I changed it to "Toggle between hard and soft newlines in the current
buffer".  :-)  So I'm closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#20461: 25.0.50; `use-hard-newlines'

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Thu, 23 Jan 2020 13:55:50 +0100
> Cc: 20461@debbugs.gnu.org
> 
> I guess the doc string still need fixing to say it only affects the
> current buffer though.  That is perhaps important enough to go on the
> first line, but I couldn't come up with a way to do that which doesn't
> go over the 67 character limit.

67-character limit is not a hard limit.  If you can do it in less than
79, go for it.

bug#20461: 25.0.50; `use-hard-newlines'

[Stephen Berman]

On Thu, 23 Jan 2020 13:55:50 +0100 Stefan Kangas <stefan@marxist.se> wrote:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> So we'd presumably need to rename the variable, too, and then it just
>> seems like it's not worth it, really.
>
> I see, yes then it might be better to just leave it alone.
>
> I guess the doc string still need fixing to say it only affects the
> current buffer though.  That is perhaps important enough to go on the
> first line, but I couldn't come up with a way to do that which doesn't
> go over the 67 character limit.

How about this:

Toggle between using hard and soft newlines in the current buffer.

Steve Berman

bug#20461: 25.0.50; `use-hard-newlines'

[Drew Adams]

> I had another peek at this, and use-hard-newlines is slightly unusual
> in that many functions bind the use-hard-newlines (and use it), like:
> 
> (defun fill-flowed-encode (&optional buffer) [...]
>   (when use-hard-newlines
> 
> So we'd presumably need to rename the variable, too,

Yes, of course.  That's true of any minor mode.  Often
people do not use the variable, but they certainly can,
in general.

> and then it just seems like it's not worth it, really.

Why?  No reason given.  The right thing to do, to
respect Emacs convention and not mislead users further,
is to fix this.  And yes, of course, that means also
renaming the variable.  This is trivial to fix.

bug#20461: 25.0.50; `use-hard-newlines'

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Date: Thu, 23 Jan 2020 15:58:35 +0100
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, 20461@debbugs.gnu.org
> 
> Toggle between using hard and soft newlines in the current buffer.

I'd drop "the" for a good measure.