bug#37324: Small typo in Emacs manual (frame parameters)

bug#37324: Small typo in Emacs manual (frame parameters)

[Sebastian Urban]

In Emacs manual INFO 21.11 Frame Parameters
- (add-to-list 'default-frame-alist '(width  . 90))
+ (add-to-list 'default-frame-alist '(width . 90))

Line 932 in 'FRAMES.TEXI'.

I think there is one unnecessary "space".


S. U.

bug#37324: Small typo in Emacs manual (frame parameters)

[Eli Zaretskii]

> From: Sebastian Urban <mrsebastianurban@gmail.com>
> Date: Fri, 6 Sep 2019 19:24:30 +0200
> 
> In Emacs manual INFO 21.11 Frame Parameters
> - (add-to-list 'default-frame-alist '(width  . 90))
> + (add-to-list 'default-frame-alist '(width . 90))
> 
> Line 932 in 'FRAMES.TEXI'.
> 
> I think there is one unnecessary "space".

That's on purpose: the example tries to align this line with the next.

bug#37324: Small typo in Emacs manual (frame parameters)

[Sebastian Urban]

>> In Emacs manual INFO 21.11 Frame Parameters
>> - (add-to-list 'default-frame-alist '(width  . 90))
>> + (add-to-list 'default-frame-alist '(width . 90))
>> (...)
>> I think there is one unnecessary "space".
>
> That's on purpose: the example tries to align this line with the
> next.

Ok, so I'm guessing that the number of spaces - in this example -
before and after the dot is insignificant from perspective of the code
(well, perhaps 1 is needed).  But... is changing the insides of the
code example just to align it to the next line is reasonable?  If
everywhere (I think) there is PARAMETER-ONE_SPACE-DOT-ONE_SPACE-VALUE
perhaps it would be better to stick to that, because otherwise someone
may think that there is an error in the code example.

bug#37324: Small typo in Emacs manual (frame parameters)

[Eli Zaretskii]

> From: Sebastian Urban <mrsebastianurban@gmail.com>
> Cc: 37324@debbugs.gnu.org
> Date: Sat, 7 Sep 2019 21:14:31 +0200
> 
> >> I think there is one unnecessary "space".
> >
> > That's on purpose: the example tries to align this line with the
> > next.
> 
> Ok, so I'm guessing that the number of spaces - in this example -
> before and after the dot is insignificant from perspective of the code
> (well, perhaps 1 is needed).  But... is changing the insides of the
> code example just to align it to the next line is reasonable?  If
> everywhere (I think) there is PARAMETER-ONE_SPACE-DOT-ONE_SPACE-VALUE
> perhaps it would be better to stick to that, because otherwise someone
> may think that there is an error in the code example.

I don't see anything unreasonable in that example.  Whitespace is
insignificant in cons cells (and in many other places in Lisp).

bug#37324: Small typo in Emacs manual (frame parameters)

[Sebastian Urban]

> I don't see anything unreasonable in that example.  Whitespace is
> insignificant in cons cells (and in many other places in Lisp).

Alignment is unreasonable.  I just think this example should look like
other examples of this kind - one space, before and after dot - even
if from perspective of code it is correct to put more than one space.

If I'm the only one with this "problem", i.e. no one else will add
anything in few(?) days, then you can close this bug as "wontfix"
or "not a bug" or something.

bug#37324: Small typo in Emacs manual (frame parameters)

[Eli Zaretskii]

> Cc: 37324@debbugs.gnu.org
> From: Sebastian Urban <mrsebastianurban@gmail.com>
> Date: Sun, 8 Sep 2019 13:00:01 +0200
> 
> If I'm the only one with this "problem", i.e. no one else will add
> anything in few(?) days, then you can close this bug as "wontfix"
> or "not a bug" or something.

I cannot know if you are the only one.  IME, some people object
vociferously when their bug reports are closed as "wontfix", so I
stopped doing that except when the report is obviously wrong.

bug#37324: Small typo in Emacs manual (frame parameters)

[Stefan Kangas]

tags 37324 + wontfix
close 37324
quit

Sebastian Urban <mrsebastianurban@gmail.com> writes:

> If I'm the only one with this "problem", i.e. no one else will add
> anything in few(?) days, then you can close this bug as "wontfix"
> or "not a bug" or something.

No further comments in 8 days, so I'm closing this now.

Thanks for the report -- I think it's highly useful when people point
out things that they think could be improved.  Unfortunately sometimes
people will disagree about what is best, especially when it comes to
stylistic choices which will inevitably be a a bit subjective.

Best regards,
Stefan Kangas