GNU bug report logs -
#48654
Overfull hbox, Unicode code points style (display.texi)
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 48654 in the body.
You can then email your comments to 48654 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48654
; Package
emacs
.
(Tue, 25 May 2021 15:26:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Sebastian Urban <mrsebastianurban <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Tue, 25 May 2021 15:26:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Changes are in the attached DIFF file (DISPLAY.DIFF).
As for the "overfull hbox", in the end I decided to simply add a
discretionary hyphen (@-) after 2nd hyphen (when I added it after
every hyphen, the line was broken after 2nd hyphen). Alternatively,
someone will have to rearrange the sentence.
As for Unicode code points it was decided to use "U+NNNN @sc{char
name}", so I adjusted all of them.
Additionally, I changed, in the last paragraph of "Visual Line Mode"
section, typesetting of the category char to use @samp{} instead of
``...''.
Finally, in a different file - FIXIT.TEXI - there is line 356, where
the word "dictionary" uses a discretionary hyphens - are they used
somewhere? Because, in the PDF there is no line breaking for this
sentence and if it's correct, perhaps adding this word to
DOCSTYLE.TEXI would be a better option.
--
S. U.
[display.diff (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48654
; Package
emacs
.
(Tue, 25 May 2021 17:22:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 48654 <at> debbugs.gnu.org (full text, mbox):
> From: Sebastian Urban <mrsebastianurban <at> gmail.com>
> Date: Tue, 25 May 2021 17:24:44 +0200
>
> Changes are in the attached DIFF file (DISPLAY.DIFF).
>
> As for the "overfull hbox", in the end I decided to simply add a
> discretionary hyphen (@-) after 2nd hyphen (when I added it after
> every hyphen, the line was broken after 2nd hyphen). Alternatively,
> someone will have to rearrange the sentence.
>
> As for Unicode code points it was decided to use "U+NNNN @sc{char
> name}", so I adjusted all of them.
Please use the exact names of the characters as they appear in the
UnicodeData.txt file.
Also, why remove @code{..} from the "U+NNNN" notation -- what does
that solve?
> Finally, in a different file - FIXIT.TEXI - there is line 356, where
> the word "dictionary" uses a discretionary hyphens - are they used
> somewhere? Because, in the PDF there is no line breaking for this
> sentence and if it's correct, perhaps adding this word to
> DOCSTYLE.TEXI would be a better option.
It depends on surrounding text: if the word gets close to a line
break, we want it to break correctly.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48654
; Package
emacs
.
(Wed, 26 May 2021 07:38:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 48654 <at> debbugs.gnu.org (full text, mbox):
>> As for Unicode code points it was decided to use "U+NNNN @sc{char
>> name}", so I adjusted all of them.
>
> Please use the exact names of the characters as they appear in the
> UnicodeData.txt file.
Hmmm... which one is incorrect?
> Also, why remove @code{..} from the "U+NNNN" notation -- what does
> that solve?
Because, ~2 years ago you decided to follow Unicode docs notation, and
I'm just fixing the leftovers. See your commit:
http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=f68b33f50299339a36da29cd1913d19fd5f288e0
>> Finally, in a different file - FIXIT.TEXI - there is line 356,
>> where the word "dictionary" uses a discretionary hyphens - are they
>> used somewhere? Because, in the PDF there is no line breaking for
>> this sentence and if it's correct, perhaps adding this word to
>> DOCSTYLE.TEXI would be a better option.
>
> It depends on surrounding text: if the word gets close to a line
> break, we want it to break correctly.
I don't know if it's a good idea to keep this just in case someone
changes the text in the future, or makes PDF using A5 page format.
Currently (official PDF), it's not close to a line break.
But if it stays, I suggest moving it to DOCSTYLE.TEXI, where other
problematic words are gathered below this line:
@c It turns out TeX sometimes fails to hyphenate, so we help it here
@hyphenation{...}
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48654
; Package
emacs
.
(Wed, 26 May 2021 12:39:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 48654 <at> debbugs.gnu.org (full text, mbox):
> Cc: 48654 <at> debbugs.gnu.org
> From: Sebastian Urban <mrsebastianurban <at> gmail.com>
> Date: Wed, 26 May 2021 09:37:37 +0200
>
> >> As for Unicode code points it was decided to use "U+NNNN @sc{char
> >> name}", so I adjusted all of them.
> >
> > Please use the exact names of the characters as they appear in the
> > UnicodeData.txt file.
>
> Hmmm... which one is incorrect?
I didn't say there were any, but I saw you were changing the names,
and wanted to make sure you take the names from the official source.
> > Also, why remove @code{..} from the "U+NNNN" notation -- what does
> > that solve?
>
> Because, ~2 years ago you decided to follow Unicode docs notation, and
> I'm just fixing the leftovers. See your commit:
> http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=f68b33f50299339a36da29cd1913d19fd5f288e0
OK, that just emphasizes the importance of providing the commit log
message with reasoning when you propose a patch, TIA.
> >> Finally, in a different file - FIXIT.TEXI - there is line 356,
> >> where the word "dictionary" uses a discretionary hyphens - are they
> >> used somewhere? Because, in the PDF there is no line breaking for
> >> this sentence and if it's correct, perhaps adding this word to
> >> DOCSTYLE.TEXI would be a better option.
> >
> > It depends on surrounding text: if the word gets close to a line
> > break, we want it to break correctly.
>
> I don't know if it's a good idea to keep this just in case someone
> changes the text in the future, or makes PDF using A5 page format.
> Currently (official PDF), it's not close to a line break.
What's the harm?
> But if it stays, I suggest moving it to DOCSTYLE.TEXI, where other
> problematic words are gathered below this line:
> @c It turns out TeX sometimes fails to hyphenate, so we help it here
> @hyphenation{...}
Fine with me.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48654
; Package
emacs
.
(Wed, 26 May 2021 19:01:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 48654 <at> debbugs.gnu.org (full text, mbox):
>>> Please use the exact names of the characters as they appear in the
>>> UnicodeData.txt file.
>> Hmmm... which one is incorrect?
> I didn't say there were any, but I saw you were changing the names,
> and wanted to make sure you take the names from the official source.
I only changed one name, but all are correct, according to the
UnicodeData.txt and 'describe-char'.
>>> Also, why remove @code{..} from the "U+NNNN" notation -- what does
>>> that solve?
>> Because, ~2 years ago you decided to follow Unicode docs notation,
>> and I'm just fixing the leftovers. See your commit:
>> (...)/emacs.git/commit/?id=f68b33f50299339a36da29cd1913d19fd5f288e0
> OK, that just emphasizes the importance of providing the commit log
> message with reasoning when you propose a patch, TIA.
There were various styles of Unicode code points and character names
across Emacs manual ~2 years ago. It was decided to follow Unicode
notation, so I'm following it. Then, the reason is... consistency?
Perhaps you could use the same messages:
Fix styling of Unicode codepoints in manuals
OR
Canonicalize the style of "U+NNNN CHARACTER NAME".
>> I don't know if it's a good idea to keep this just in case someone
>> changes the text in the future, or makes PDF using A5 page format.
>> Currently (official PDF), it's not close to a line break.
> What's the harm?
None? But...
>> (...) if it stays, I suggest moving it to DOCSTYLE.TEXI, (...)
> Fine with me.
...since you agreed with moving it to DOCSTYLE.TEXI, let it be the
solution.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48654
; Package
emacs
.
(Sat, 29 May 2021 08:25:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 48654 <at> debbugs.gnu.org (full text, mbox):
> From: Sebastian Urban <mrsebastianurban <at> gmail.com>
> Cc: 48654 <at> debbugs.gnu.org
> Date: Wed, 26 May 2021 21:00:47 +0200
>
> >>> Also, why remove @code{..} from the "U+NNNN" notation -- what does
> >>> that solve?
> >> Because, ~2 years ago you decided to follow Unicode docs notation,
> >> and I'm just fixing the leftovers. See your commit:
> >> (...)/emacs.git/commit/?id=f68b33f50299339a36da29cd1913d19fd5f288e0
> > OK, that just emphasizes the importance of providing the commit log
> > message with reasoning when you propose a patch, TIA.
>
> There were various styles of Unicode code points and character names
> across Emacs manual ~2 years ago. It was decided to follow Unicode
> notation, so I'm following it. Then, the reason is... consistency?
>
> Perhaps you could use the same messages:
> Fix styling of Unicode codepoints in manuals
> OR
> Canonicalize the style of "U+NNNN CHARACTER NAME".
>
> >> I don't know if it's a good idea to keep this just in case someone
> >> changes the text in the future, or makes PDF using A5 page format.
> >> Currently (official PDF), it's not close to a line break.
> > What's the harm?
>
> None? But...
>
> >> (...) if it stays, I suggest moving it to DOCSTYLE.TEXI, (...)
> > Fine with me.
>
> ...since you agreed with moving it to DOCSTYLE.TEXI, let it be the
> solution.
Thanks, could you please post an updated patch with all of the above
taken care of?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48654
; Package
emacs
.
(Sat, 29 May 2021 16:51:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 48654 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> Thanks, could you please post an updated patch with all of the above
> taken care of?
Attached.
[all.diff (text/plain, attachment)]
Added tag(s) patch.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Sun, 30 May 2021 04:32:02 GMT)
Full text and
rfc822 format available.
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>
:
You have taken responsibility.
(Sun, 06 Jun 2021 10:01:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Sebastian Urban <mrsebastianurban <at> gmail.com>
:
bug acknowledged by developer.
(Sun, 06 Jun 2021 10:01:01 GMT)
Full text and
rfc822 format available.
Message #30 received at 48654-done <at> debbugs.gnu.org (full text, mbox):
> Cc: 48654 <at> debbugs.gnu.org
> From: Sebastian Urban <mrsebastianurban <at> gmail.com>
> Date: Sat, 29 May 2021 18:50:10 +0200
>
> > Thanks, could you please post an updated patch with all of the above
> > taken care of?
>
> Attached.
Thanks, installed.
Btw, I think with this contribution you have all but exhausted the
limit of changes we can accept without copyright assignment, so would
you like to start your legal paperwork now, to allow us to accept
further contributions from you?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48654
; Package
emacs
.
(Mon, 07 Jun 2021 13:18:01 GMT)
Full text and
rfc822 format available.
Message #33 received at 48654 <at> debbugs.gnu.org (full text, mbox):
> Btw, I think with this contribution you have all but exhausted the
> limit of changes we can accept without copyright assignment, so
> would you like to start your legal paperwork now, to allow us to
> accept further contributions from you?
I thought these changes need to be more non-trivial, then those I
made.
As for copyright assignment, is it one of those where I have to write
my postal address, right? And there is no way to avoid that?
Because I have no patches waiting to be sent for now (like, anytime
soon), I think, I'll skip the copyright thing.
I'll come back to this, when it'll be needed.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Tue, 06 Jul 2021 11:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 267 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.