unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#48654: Overfull hbox, Unicode code points style (display.texi)
@ 2021-05-25 15:24 Sebastian Urban
  2021-05-25 17:21 ` Eli Zaretskii
  0 siblings, 1 reply; 9+ messages in thread
From: Sebastian Urban @ 2021-05-25 15:24 UTC (permalink / raw)
  To: 48654

[-- Attachment #1: Type: text/plain, Size: 859 bytes --]

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.

[-- Attachment #2: display.diff --]
[-- Type: text/plain, Size: 5429 bytes --]

--- old/doc/emacs/display.texi	2021-05-18 21:14:36.794570300 +0200
+++ new/doc/emacs/display.texi	2021-05-19 10:54:39.778502900 +0200
@@ -1189,8 +1189,8 @@
 program.
 
   To activate the fill-column indication display, use the minor modes
-@w{@kbd{M-x display-fill-column-indicator-mode}} and
-@w{@kbd{M-x global-display-fill-column-indicator-mode}}, which enable
+@kbd{M-x display-fill-@-column-indicator-mode} and
+@kbd{M-x global-display-fill-column-indicator-mode}, which enable
 the indicator locally or globally, respectively.
 
 Alternatively, you can set the two buffer-local variables
@@ -1220,8 +1220,8 @@
 through the functions @code{display-fill-column-indicator-mode} or
 @code{global-display-fill-column-indicator-mode}, they will use the
 character specified by this variable, if it is non-@code{nil};
-otherwise Emacs will use the character @samp{U+2502 VERTICAL LINE},
-falling back to @samp{|} if @code{U+2502} cannot be displayed.
+otherwise Emacs will use the character U+2502 @sc{box drawings light vertical},
+falling back to @samp{|} if U+2502 cannot be displayed.
 
 @item fill-column-indicator
 @vindex fill-column-indicator
@@ -1577,8 +1577,8 @@
 @cindex control characters on display
   The @acronym{ASCII} character set contains non-printing @dfn{control
 characters}.  Two of these are displayed specially: the newline
-character (Unicode code point @code{U+000A}) is displayed by starting
-a new line, while the tab character (@code{U+0009}) is displayed as a
+character (Unicode code point U+000A) is displayed by starting
+a new line, while the tab character (U+0009) is displayed as a
 space that extends to the next tab stop column (normally every 8
 columns).  The number of spaces per tab is controlled by the
 buffer-local variable @code{tab-width}, which must have an integer
@@ -1587,17 +1587,17 @@
 definition of @key{TAB} as a command.
 
   Other @acronym{ASCII} control characters, whose codes are below
-@code{U+0020} (octal 40, decimal 32), are displayed as a caret
+U+0020 (octal 40, decimal 32), are displayed as a caret
 (@samp{^}) followed by the non-control version of the character, with
 the @code{escape-glyph} face.  For instance, the @samp{control-A}
-character, @code{U+0001}, is displayed as @samp{^A}.
+character, U+0001, is displayed as @samp{^A}.
 
 @cindex octal escapes
 @vindex ctl-arrow
-  The raw bytes with codes @code{U+0080} (octal 200) through
-@code{U+009F} (octal 237) are displayed as @dfn{octal escape
+  The raw bytes with codes U+0080 (octal 200) through
+U+009F (octal 237) are displayed as @dfn{octal escape
 sequences}, with the @code{escape-glyph} face.  For instance,
-character code @code{U+0098} (octal 230) is displayed as @samp{\230}.
+character code U+0098 (octal 230) is displayed as @samp{\230}.
 If you change the buffer-local variable @code{ctl-arrow} to
 @code{nil}, the @acronym{ASCII} control characters are also displayed
 as octal escape sequences instead of caret escape sequences.  (You can
@@ -1616,11 +1616,11 @@
 realization, e.g., by yanking; for instance, source code compilers
 typically do not treat non-@acronym{ASCII} spaces as whitespace
 characters.  To deal with this problem, Emacs displays such characters
-specially: it displays @code{U+00A0} (no-break space) and other
+specially: it displays U+00A0 @sc{no-break space} and other
 characters from the Unicode horizontal space class with the
-@code{nobreak-space} face, and it displays @code{U+00AD} (soft
-hyphen), @code{U+2010} (hyphen), and @code{U+2011} (non-breaking
-hyphen) with the @code{nobreak-hyphen} face.  To disable this, change
+@code{nobreak-space} face, and it displays U+00AD @sc{soft hyphen},
+U+2010 @sc{hyphen}, and U+2011 @sc{non-breaking
+hyphen} with the @code{nobreak-hyphen} face.  To disable this, change
 the variable @code{nobreak-char-display} to @code{nil}.  If you give
 this variable a non-@code{nil} and non-@code{t} value, Emacs instead
 displays such characters as a highlighted backslash followed by a
@@ -1829,15 +1829,15 @@
 That produces incorrect results when CJK and Latin text are mixed
 together (because CJK characters don't use whitespace to separate
 words).  You can customize the option @code{word-wrap-by-category} to
-allow Emacs to break lines after any character with ``|'' category
+allow Emacs to break lines after any character with @samp{|} category
 (@pxref{Categories,,, elisp, the Emacs Lisp Reference Manual}), which
 provides better support for CJK characters.  Also, if this variable is
 set using Customize, Emacs automatically loads @file{kinsoku.el}.
 When @file{kinsoku.el} is loaded, Emacs respects kinsoku rules when
-breaking lines.  That means characters with the ``>'' category don't
-appear at the beginning of a line (e.g., U+FF0C FULLWIDTH COMMA), and
-characters with the ``<'' category don't appear at the end of a line
-(e.g., U+300A LEFT DOUBLE ANGLE BRACKET).  You can view the category
+breaking lines.  That means characters with the @samp{>} category don't
+appear at the beginning of a line (e.g., U+FF0C @sc{fullwidth comma}), and
+characters with the @samp{<} category don't appear at the end of a line
+(e.g., U+300A @sc{left double angle bracket}).  You can view the category
 set of a character using the commands @code{char-category-set} and
 @code{category-set-mnemonics}, or by typing @kbd{C-u C-x =} with point
 on the character and looking at the ``category'' section in the

^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#48654: Overfull hbox, Unicode code points style (display.texi)
  2021-05-25 15:24 bug#48654: Overfull hbox, Unicode code points style (display.texi) Sebastian Urban
@ 2021-05-25 17:21 ` Eli Zaretskii
  2021-05-26  7:37   ` Sebastian Urban
  0 siblings, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2021-05-25 17:21 UTC (permalink / raw)
  To: Sebastian Urban; +Cc: 48654

> From: Sebastian Urban <mrsebastianurban@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.





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#48654: Overfull hbox, Unicode code points style (display.texi)
  2021-05-25 17:21 ` Eli Zaretskii
@ 2021-05-26  7:37   ` Sebastian Urban
  2021-05-26 12:38     ` Eli Zaretskii
  0 siblings, 1 reply; 9+ messages in thread
From: Sebastian Urban @ 2021-05-26  7:37 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 48654

 >> 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{...}






^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#48654: Overfull hbox, Unicode code points style (display.texi)
  2021-05-26  7:37   ` Sebastian Urban
@ 2021-05-26 12:38     ` Eli Zaretskii
  2021-05-26 19:00       ` Sebastian Urban
  0 siblings, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2021-05-26 12:38 UTC (permalink / raw)
  To: Sebastian Urban; +Cc: 48654

> Cc: 48654@debbugs.gnu.org
> From: Sebastian Urban <mrsebastianurban@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.





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#48654: Overfull hbox, Unicode code points style (display.texi)
  2021-05-26 12:38     ` Eli Zaretskii
@ 2021-05-26 19:00       ` Sebastian Urban
  2021-05-29  8:24         ` Eli Zaretskii
  0 siblings, 1 reply; 9+ messages in thread
From: Sebastian Urban @ 2021-05-26 19:00 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 48654

>>> 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.





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#48654: Overfull hbox, Unicode code points style (display.texi)
  2021-05-26 19:00       ` Sebastian Urban
@ 2021-05-29  8:24         ` Eli Zaretskii
  2021-05-29 16:50           ` Sebastian Urban
  0 siblings, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2021-05-29  8:24 UTC (permalink / raw)
  To: Sebastian Urban; +Cc: 48654

> From: Sebastian Urban <mrsebastianurban@gmail.com>
> Cc: 48654@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?





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#48654: Overfull hbox, Unicode code points style (display.texi)
  2021-05-29  8:24         ` Eli Zaretskii
@ 2021-05-29 16:50           ` Sebastian Urban
  2021-06-06 10:00             ` Eli Zaretskii
  0 siblings, 1 reply; 9+ messages in thread
From: Sebastian Urban @ 2021-05-29 16:50 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 48654

[-- Attachment #1: Type: text/plain, Size: 99 bytes --]

> Thanks, could you please post an updated patch with all of the above
> taken care of?

Attached.

[-- Attachment #2: all.diff --]
[-- Type: text/plain, Size: 6301 bytes --]

diff -u /old/doc/emacs/ /new/doc/emacs/
diff -u /old/doc/emacs/display.texi /new/doc/emacs/display.texi
--- /old/doc/emacs/display.texi	2021-05-29 10:57:18.174619900 +0200
+++ /new/doc/emacs/display.texi	2021-05-29 15:42:19.781309600 +0200
@@ -1189,8 +1189,8 @@
 program.
 
   To activate the fill-column indication display, use the minor modes
-@w{@kbd{M-x display-fill-column-indicator-mode}} and
-@w{@kbd{M-x global-display-fill-column-indicator-mode}}, which enable
+@kbd{M-x display-fill-@-column-indicator-mode} and
+@kbd{M-x global-display-fill-column-indicator-mode}, which enable
 the indicator locally or globally, respectively.
 
 Alternatively, you can set the two buffer-local variables
@@ -1220,8 +1220,8 @@
 through the functions @code{display-fill-column-indicator-mode} or
 @code{global-display-fill-column-indicator-mode}, they will use the
 character specified by this variable, if it is non-@code{nil};
-otherwise Emacs will use the character @samp{U+2502 VERTICAL LINE},
-falling back to @samp{|} if @code{U+2502} cannot be displayed.
+otherwise Emacs will use the character U+2502 @sc{box drawings light vertical},
+falling back to @samp{|} if U+2502 cannot be displayed.
 
 @item fill-column-indicator
 @vindex fill-column-indicator
@@ -1577,8 +1577,8 @@
 @cindex control characters on display
   The @acronym{ASCII} character set contains non-printing @dfn{control
 characters}.  Two of these are displayed specially: the newline
-character (Unicode code point @code{U+000A}) is displayed by starting
-a new line, while the tab character (@code{U+0009}) is displayed as a
+character (Unicode code point U+000A) is displayed by starting
+a new line, while the tab character (U+0009) is displayed as a
 space that extends to the next tab stop column (normally every 8
 columns).  The number of spaces per tab is controlled by the
 buffer-local variable @code{tab-width}, which must have an integer
@@ -1587,17 +1587,17 @@
 definition of @key{TAB} as a command.
 
   Other @acronym{ASCII} control characters, whose codes are below
-@code{U+0020} (octal 40, decimal 32), are displayed as a caret
+U+0020 (octal 40, decimal 32), are displayed as a caret
 (@samp{^}) followed by the non-control version of the character, with
 the @code{escape-glyph} face.  For instance, the @samp{control-A}
-character, @code{U+0001}, is displayed as @samp{^A}.
+character, U+0001, is displayed as @samp{^A}.
 
 @cindex octal escapes
 @vindex ctl-arrow
-  The raw bytes with codes @code{U+0080} (octal 200) through
-@code{U+009F} (octal 237) are displayed as @dfn{octal escape
+  The raw bytes with codes U+0080 (octal 200) through
+U+009F (octal 237) are displayed as @dfn{octal escape
 sequences}, with the @code{escape-glyph} face.  For instance,
-character code @code{U+0098} (octal 230) is displayed as @samp{\230}.
+character code U+0098 (octal 230) is displayed as @samp{\230}.
 If you change the buffer-local variable @code{ctl-arrow} to
 @code{nil}, the @acronym{ASCII} control characters are also displayed
 as octal escape sequences instead of caret escape sequences.  (You can
@@ -1616,11 +1616,11 @@
 realization, e.g., by yanking; for instance, source code compilers
 typically do not treat non-@acronym{ASCII} spaces as whitespace
 characters.  To deal with this problem, Emacs displays such characters
-specially: it displays @code{U+00A0} (no-break space) and other
+specially: it displays U+00A0 @sc{no-break space} and other
 characters from the Unicode horizontal space class with the
-@code{nobreak-space} face, and it displays @code{U+00AD} (soft
-hyphen), @code{U+2010} (hyphen), and @code{U+2011} (non-breaking
-hyphen) with the @code{nobreak-hyphen} face.  To disable this, change
+@code{nobreak-space} face, and it displays U+00AD @sc{soft
+hyphen}, U+2010 @sc{hyphen}, and U+2011 @sc{non-breaking
+hyphen} with the @code{nobreak-hyphen} face.  To disable this, change
 the variable @code{nobreak-char-display} to @code{nil}.  If you give
 this variable a non-@code{nil} and non-@code{t} value, Emacs instead
 displays such characters as a highlighted backslash followed by a
@@ -1829,15 +1829,15 @@
 That produces incorrect results when CJK and Latin text are mixed
 together (because CJK characters don't use whitespace to separate
 words).  You can customize the option @code{word-wrap-by-category} to
-allow Emacs to break lines after any character with ``|'' category
+allow Emacs to break lines after any character with @samp{|} category
 (@pxref{Categories,,, elisp, the Emacs Lisp Reference Manual}), which
 provides better support for CJK characters.  Also, if this variable is
 set using Customize, Emacs automatically loads @file{kinsoku.el}.
 When @file{kinsoku.el} is loaded, Emacs respects kinsoku rules when
-breaking lines.  That means characters with the ``>'' category don't
-appear at the beginning of a line (e.g., U+FF0C FULLWIDTH COMMA), and
-characters with the ``<'' category don't appear at the end of a line
-(e.g., U+300A LEFT DOUBLE ANGLE BRACKET).  You can view the category
+breaking lines.  That means characters with the @samp{>} category don't
+appear at the beginning of a line (e.g., U+FF0C @sc{fullwidth comma}), and
+characters with the @samp{<} category don't appear at the end of a line
+(e.g., U+300A @sc{left double angle bracket}).  You can view the category
 set of a character using the commands @code{char-category-set} and
 @code{category-set-mnemonics}, or by typing @kbd{C-u C-x =} with point
 on the character and looking at the ``category'' section in the
diff -u /old/doc/emacs/docstyle.texi /new/doc/emacs/docstyle.texi
--- /old/doc/emacs/docstyle.texi	2021-01-28 18:52:15.000000000 +0100
+++ /new/doc/emacs/docstyle.texi	2021-05-29 15:43:32.071836500 +0200
@@ -15,4 +15,5 @@
 @hyphenation{work-a-round}
 @hyphenation{work-a-rounds}
 @hyphenation{un-marked}
+@hyphenation{dic-tion-ary}
 @end iftex
diff -u /old/doc/emacs/fixit.texi /new/doc/emacs/fixit.texi
--- /old/doc/emacs/fixit.texi	2021-05-29 10:57:08.352602700 +0200
+++ /new/doc/emacs/fixit.texi	2021-05-29 15:43:39.778250100 +0200
@@ -365,7 +365,7 @@
 information.
 
 @item u
-Insert the lower-case version of this word in your private dic@-tion@-ary
+Insert the lower-case version of this word in your private dictionary
 file.
 
 @item l @var{word} @key{RET}

^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#48654: Overfull hbox, Unicode code points style (display.texi)
  2021-05-29 16:50           ` Sebastian Urban
@ 2021-06-06 10:00             ` Eli Zaretskii
  2021-06-07 13:17               ` Sebastian Urban
  0 siblings, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2021-06-06 10:00 UTC (permalink / raw)
  To: Sebastian Urban; +Cc: 48654-done

> Cc: 48654@debbugs.gnu.org
> From: Sebastian Urban <mrsebastianurban@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?





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#48654: Overfull hbox, Unicode code points style (display.texi)
  2021-06-06 10:00             ` Eli Zaretskii
@ 2021-06-07 13:17               ` Sebastian Urban
  0 siblings, 0 replies; 9+ messages in thread
From: Sebastian Urban @ 2021-06-07 13:17 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 48654

 > 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.





^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2021-06-07 13:17 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-05-25 15:24 bug#48654: Overfull hbox, Unicode code points style (display.texi) Sebastian Urban
2021-05-25 17:21 ` Eli Zaretskii
2021-05-26  7:37   ` Sebastian Urban
2021-05-26 12:38     ` Eli Zaretskii
2021-05-26 19:00       ` Sebastian Urban
2021-05-29  8:24         ` Eli Zaretskii
2021-05-29 16:50           ` Sebastian Urban
2021-06-06 10:00             ` Eli Zaretskii
2021-06-07 13:17               ` Sebastian Urban

unofficial mirror of bug-gnu-emacs@gnu.org 

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://yhetil.org/emacs-bugs/0 emacs-bugs/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 emacs-bugs emacs-bugs/ https://yhetil.org/emacs-bugs \
		bug-gnu-emacs@gnu.org
	public-inbox-index emacs-bugs

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.yhetil.org/yhetil.emacs.bugs
	nntp://news.gmane.io/gmane.emacs.bugs


code repositories for project(s) associated with this inbox:

	https://git.savannah.gnu.org/cgit/emacs.git

AGPL code for this site: git clone http://ou63pmih66umazou.onion/public-inbox.git