bug#20871: 25.0.50; fill-single-char-nobreak-p does not recognize a single-letter word when it is preceded by an open paren

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

bug#20871: 25.0.50; fill-single-char-nobreak-p does not recognize a single-letter word when it is preceded by an open paren

Marcin Borkowski-3
Hello,

today I found that fill-single-char-nobreak-p is just a bit too
simplistic.  When point is after e.g. the string " (a", it returns nil
instead of t.  I am not sure which characters should be added to the
regex, but at least the opening paren (and maybe bracket) should be
there, so I'd change the regex into [[:space:]][[(]*[[:alpha:]].  (Two
or more opening parens/brackets are unlikely, but when in doubt, I guess
it's better to return t than nil than the other way round.)

Best regards,

--
Marcin Borkowski               This email was proudly sent
http://mbork.pl                from my Emacs.



Reply | Threaded
Open this post in threaded view
|

bug#20871: 25.0.50; fill-single-char-nobreak-p does not recognize a single-letter word when it is preceded by an open paren

Marcin Borkowski-3

On 2015-06-22, at 12:19, Marcin Borkowski <[hidden email]> wrote:

> Hello,
>
> today I found that fill-single-char-nobreak-p is just a bit too
> simplistic.  When point is after e.g. the string " (a", it returns nil
> instead of t.  I am not sure which characters should be added to the
> regex, but at least the opening paren (and maybe bracket) should be
> there, so I'd change the regex into [[:space:]][[(]*[[:alpha:]].  (Two
> or more opening parens/brackets are unlikely, but when in doubt, I guess
> it's better to return t than nil than the other way round.)
>
> Best regards,

Just noticed that there is a hardcoded (backward-char 2), so it
seems that adding a few characters to the regex is not enough.  Maybe
looking-back is the way to go (though it might slow filling down)?
I don't know.

Best,

--
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University



Reply | Threaded
Open this post in threaded view
|

bug#20871: 25.0.50; fill-single-char-nobreak-p does not recognize a single-letter word when it is preceded by an open paren

Marcin Borkowski-3
On 2015-06-22, at 12:28, Marcin Borkowski <[hidden email]> wrote:

> On 2015-06-22, at 12:19, Marcin Borkowski <[hidden email]> wrote:
>
>> Hello,
>>
>> today I found that fill-single-char-nobreak-p is just a bit too
>> simplistic.  When point is after e.g. the string " (a", it returns nil
>> instead of t.  I am not sure which characters should be added to the
>> regex, but at least the opening paren (and maybe bracket) should be
>> there, so I'd change the regex into [[:space:]][[(]*[[:alpha:]].  (Two
>> or more opening parens/brackets are unlikely, but when in doubt, I guess
>> it's better to return t than nil than the other way round.)
>>
>> Best regards,
>
> Just noticed that there is a hardcoded (backward-char 2), so it
> seems that adding a few characters to the regex is not enough.  Maybe
> looking-back is the way to go (though it might slow filling down)?
> I don't know.
Hi there,

so here's a patch for the bug I reported some time ago.  Please review
both the patch and the commit message (I'm still learning to write
them...).

Best,

--
Marcin

From de6c196235ef8abfff52c9cfc3d97a6350e8a5a7 Mon Sep 17 00:00:00 2001
From: Marcin Borkowski <[hidden email]>
Date: Sun, 17 Apr 2016 08:30:49 +0200
Subject: [PATCH] Fix `fill-single-char-nobreak-p'

* lisp/textmodes/fill.el (fill-single-char-nobreak-p): make space after
        opening paren and a single-letter word unbreakable (Bug#20871)
---
 lisp/textmodes/fill.el | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/lisp/textmodes/fill.el b/lisp/textmodes/fill.el
index 173d1c9..bade8fa 100644
--- a/lisp/textmodes/fill.el
+++ b/lisp/textmodes/fill.el
@@ -337,7 +337,10 @@ fill-single-char-nobreak-p
   (save-excursion
     (skip-chars-backward " \t")
     (backward-char 2)
-    (looking-at "[[:space:]][[:alpha:]]")))
+    (or (looking-at "[[:space:]][[:alpha:]]")
+        (progn
+          (backward-char 1)
+          (looking-at "[[:space:]]([[:alpha:]]")))))
 
 (defcustom fill-nobreak-predicate nil
   "List of predicates for recognizing places not to break a line.
--
2.4.3

Reply | Threaded
Open this post in threaded view
|

bug#20871: 25.0.50; fill-single-char-nobreak-p does not recognize a single-letter word when it is preceded by an open paren

Eli Zaretskii
> From: Marcin Borkowski <[hidden email]>
> Date: Sun, 17 Apr 2016 08:34:30 +0200
>
> >> today I found that fill-single-char-nobreak-p is just a bit too
> >> simplistic.  When point is after e.g. the string " (a", it returns nil
> >> instead of t.  I am not sure which characters should be added to the
> >> regex, but at least the opening paren (and maybe bracket) should be
> >> there, so I'd change the regex into [[:space:]][[(]*[[:alpha:]].  (Two
> >> or more opening parens/brackets are unlikely, but when in doubt, I guess
> >> it's better to return t than nil than the other way round.)
> >>
> >> Best regards,
> >
> > Just noticed that there is a hardcoded (backward-char 2), so it
> > seems that adding a few characters to the regex is not enough.  Maybe
> > looking-back is the way to go (though it might slow filling down)?
> > I don't know.
>
> Hi there,
>
> so here's a patch for the bug I reported some time ago.

Could you please elaborate on the bug itself?

See, the function in question, fill-single-char-nobreak-p, is
documented as a possible value to use in the fill hook, for a very
specific purpose.  If you are saying that it doesn't fulfill that
purpose well enough, please show a use case where it fails to do that.
At least the situation you described, with " (a", doesn't seem to fit
the use cases which this function is supposed to cover, since the
parenthesis makes a 2-character sequence, whereas
fill-single-char-nobreak-p aims to support isolated one-character
words.

I also am not sure I understand what is so special about '(' that it
has to be hard-coded here.  What about '[' or '{' or '<' (or any other
punctuation character, for that matter)?

> Please review both the patch and the commit message (I'm still
> learning to write them...).

The commit message should begin with a capital letter.  Also, I think
this variant is more clear:

 Don't break after a single-character word that follows an opening
 parenthesis.

Thanks.



Reply | Threaded
Open this post in threaded view
|

bug#20871: 25.0.50; fill-single-char-nobreak-p does not recognize a single-letter word when it is preceded by an open paren

Marcin Borkowski-3

On 2016-04-17, at 14:57, Eli Zaretskii <[hidden email]> wrote:

>> From: Marcin Borkowski <[hidden email]>
>> Date: Sun, 17 Apr 2016 08:34:30 +0200
>>
>> >> today I found that fill-single-char-nobreak-p is just a bit too
>> >> simplistic.  When point is after e.g. the string " (a", it returns nil
>> >> instead of t.  I am not sure which characters should be added to the
>> >> regex, but at least the opening paren (and maybe bracket) should be
>> >> there, so I'd change the regex into [[:space:]][[(]*[[:alpha:]].  (Two
>> >> or more opening parens/brackets are unlikely, but when in doubt, I guess
>> >> it's better to return t than nil than the other way round.)
>> >>
>> >> Best regards,
>> >
>> > Just noticed that there is a hardcoded (backward-char 2), so it
>> > seems that adding a few characters to the regex is not enough.  Maybe
>> > looking-back is the way to go (though it might slow filling down)?
>> > I don't know.
>>
>> Hi there,
>>
>> so here's a patch for the bug I reported some time ago.
>
> Could you please elaborate on the bug itself?

In Polish typography, it is customary to foribid line breaks after
one-letter words (and we have quite a few of them: a, i, o, w, z - they
are conjunctions or prepositions).  And it is not uncommon to have
a combination of them with a parenthesized remark or something like
that.  That's why allowing a linebreak after, say "(a" when writing
something in Polish (like an email, for instance) is a bug IMO.

> See, the function in question, fill-single-char-nobreak-p, is
> documented as a possible value to use in the fill hook, for a very
> specific purpose.  If you are saying that it doesn't fulfill that
> purpose well enough, please show a use case where it fails to do that.
> At least the situation you described, with " (a", doesn't seem to fit
> the use cases which this function is supposed to cover, since the
> parenthesis makes a 2-character sequence, whereas
> fill-single-char-nobreak-p aims to support isolated one-character
> words.

I see.  So you suggest that instead of patching
`fill-single-char-nobreak-p' I should have provided another function,
customized for Polish?

In fact, I'm not so sure about it.  The whole point of such functions
(as I see it) is help write texts in natural langauges.  It seems
unnatural to treat words preceded by a space and by a parenthesis *in
a natural language* differently, no?

> I also am not sure I understand what is so special about '(' that it
> has to be hard-coded here.  What about '[' or '{' or '<' (or any other
> punctuation character, for that matter)?

The special thing about `(' is that (unlike other characters you
mentioned) is that it is actually used in a text in a natural language
(though one could make a case for `[', too).

>> Please review both the patch and the commit message (I'm still
>> learning to write them...).
>
> The commit message should begin with a capital letter.  Also, I think
> this variant is more clear:
>
>  Don't break after a single-character word that follows an opening
>  parenthesis.
>
> Thanks.

Thanks and best regards,

--
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University



Reply | Threaded
Open this post in threaded view
|

bug#20871: 25.0.50; fill-single-char-nobreak-p does not recognize a single-letter word when it is preceded by an open paren

Eli Zaretskii
> From: Marcin Borkowski <[hidden email]>
> Cc: [hidden email]
> Date: Sun, 17 Apr 2016 17:34:04 +0200
>
> In Polish typography, it is customary to foribid line breaks after
> one-letter words (and we have quite a few of them: a, i, o, w, z - they
> are conjunctions or prepositions).  And it is not uncommon to have
> a combination of them with a parenthesized remark or something like
> that.  That's why allowing a linebreak after, say "(a" when writing
> something in Polish (like an email, for instance) is a bug IMO.
>
> > See, the function in question, fill-single-char-nobreak-p, is
> > documented as a possible value to use in the fill hook, for a very
> > specific purpose.  If you are saying that it doesn't fulfill that
> > purpose well enough, please show a use case where it fails to do that.
> > At least the situation you described, with " (a", doesn't seem to fit
> > the use cases which this function is supposed to cover, since the
> > parenthesis makes a 2-character sequence, whereas
> > fill-single-char-nobreak-p aims to support isolated one-character
> > words.
>
> I see.  So you suggest that instead of patching
> `fill-single-char-nobreak-p' I should have provided another function,
> customized for Polish?

Yes, I think so.  There's already fill-french-nobreak-p, why shouldn't
there be a Polish predicate?

> In fact, I'm not so sure about it.  The whole point of such functions
> (as I see it) is help write texts in natural langauges.  It seems
> unnatural to treat words preceded by a space and by a parenthesis *in
> a natural language* differently, no?

Not necessarily: that space that precedes the word is by itself a
line-breaking opportunity.  IOW, Emacs will break before 'a' in " a",
and the penalty will be only 1 character.  By contrast, breaking
before the parenthesis in your case will yield a penalty of 2
characters, which is a different tradeoff, worthy of asking the user
explicitly to agree to.

The default value of fill-nobreak-predicate is nil for a reason.

Thanks.



Reply | Threaded
Open this post in threaded view
|

bug#20871: 25.0.50; fill-single-char-nobreak-p does not recognize a single-letter word when it is preceded by an open paren

Marcin Borkowski-3

On 2016-04-17, at 16:49, Eli Zaretskii <[hidden email]> wrote:

>> I see.  So you suggest that instead of patching
>> `fill-single-char-nobreak-p' I should have provided another function,
>> customized for Polish?
>
> Yes, I think so.  There's already fill-french-nobreak-p, why shouldn't
> there be a Polish predicate?
>
>> [...]
>
> Not necessarily: that space that precedes the word is by itself a
> line-breaking opportunity.  IOW, Emacs will break before 'a' in " a",
> and the penalty will be only 1 character.  By contrast, breaking
> before the parenthesis in your case will yield a penalty of 2
> characters, which is a different tradeoff, worthy of asking the user
> explicitly to agree to.
>
> The default value of fill-nobreak-predicate is nil for a reason.

I see.  So I'm going to prepare a patch where a new function is
introduced for Polish typography, and once it is accepted (which I hope
will happen:-)) I'm going to close this bug.

Best,

--
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University



Reply | Threaded
Open this post in threaded view
|

bug#20871: 25.0.50; fill-single-char-nobreak-p does not recognize a single-letter word when it is preceded by an open paren

Marcin Borkowski-3
In reply to this post by Eli Zaretskii

On 2016-04-17, at 16:49, Eli Zaretskii <[hidden email]> wrote:

>> From: Marcin Borkowski <[hidden email]>
>> Cc: [hidden email]
>> Date: Sun, 17 Apr 2016 17:34:04 +0200
>>
>> In Polish typography, it is customary to foribid line breaks after
>> one-letter words (and we have quite a few of them: a, i, o, w, z - they
>> are conjunctions or prepositions).  And it is not uncommon to have
>> a combination of them with a parenthesized remark or something like
>> that.  That's why allowing a linebreak after, say "(a" when writing
>> something in Polish (like an email, for instance) is a bug IMO.
>>
>> > See, the function in question, fill-single-char-nobreak-p, is
>> > documented as a possible value to use in the fill hook, for a very
>> > specific purpose.  If you are saying that it doesn't fulfill that
>> > purpose well enough, please show a use case where it fails to do that.
>> > At least the situation you described, with " (a", doesn't seem to fit
>> > the use cases which this function is supposed to cover, since the
>> > parenthesis makes a 2-character sequence, whereas
>> > fill-single-char-nobreak-p aims to support isolated one-character
>> > words.
>>
>> I see.  So you suggest that instead of patching
>> `fill-single-char-nobreak-p' I should have provided another function,
>> customized for Polish?
>
> Yes, I think so.  There's already fill-french-nobreak-p, why shouldn't
> there be a Polish predicate?
I attach a new patch. Is it better now?

Best,

--
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

0002-Add-the-function-fill-polish-nobreak-p.patch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

bug#20871: 25.0.50; fill-single-char-nobreak-p does not recognize a single-letter word when it is preceded by an open paren

Eli Zaretskii
> From: Marcin Borkowski <[hidden email]>
> Cc: [hidden email]
> Date: Wed, 27 Apr 2016 09:02:36 +0200
>
> >> I see.  So you suggest that instead of patching
> >> `fill-single-char-nobreak-p' I should have provided another function,
> >> customized for Polish?
> >
> > Yes, I think so.  There's already fill-french-nobreak-p, why shouldn't
> > there be a Polish predicate?
>
> I attach a new patch. Is it better now?

Yes, thanks.

Just one comment, for your consideration:

> +    (looking-at "[^[:alpha:]][[:alpha:]]")))

You should be aware that starting with Emacs 25.1 [:alpha:] matches a
very large class of characters, some of them having nothing in common
with those used in Polish.  So perhaps it is better to use '\cl'
instead, which will only capture Latin characters?  Just a thought --
your call.



Reply | Threaded
Open this post in threaded view
|

bug#20871: 25.0.50; fill-single-char-nobreak-p does not recognize a single-letter word when it is preceded by an open paren

Marcin Borkowski-3
On 2016-04-27, at 10:20, Eli Zaretskii <[hidden email]> wrote:

>> From: Marcin Borkowski <[hidden email]>
>> Cc: [hidden email]
>> Date: Wed, 27 Apr 2016 09:02:36 +0200
>>
>> >> I see.  So you suggest that instead of patching
>> >> `fill-single-char-nobreak-p' I should have provided another function,
>> >> customized for Polish?
>> >
>> > Yes, I think so.  There's already fill-french-nobreak-p, why shouldn't
>> > there be a Polish predicate?
>>
>> I attach a new patch. Is it better now?
>
> Yes, thanks.
>
> Just one comment, for your consideration:
>
>> +    (looking-at "[^[:alpha:]][[:alpha:]]")))
>
> You should be aware that starting with Emacs 25.1 [:alpha:] matches a
> very large class of characters, some of them having nothing in common
> with those used in Polish.  So perhaps it is better to use '\cl'
> instead, which will only capture Latin characters?  Just a thought --
> your call.
I guess you are right, Eli - in fact, all one-letter words in Polish are
matched by [aiouwz].  I decided to go with \cl, as you suggested,
though - this way, the function could be (probably) useful also for
Slovaks, for instance.  I attach the corrected patch.

Just to be sure: in my Emacs, \cl matches also ą, ę, ż, ź, á, ö etc.  Is
it intentional?  Is it documented somewhere?

Thanks and best regards,

--
Marcin

0003-Add-the-function-fill-polish-nobreak-p.patch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

bug#20871: 25.0.50; fill-single-char-nobreak-p does not recognize a single-letter word when it is preceded by an open paren

Eli Zaretskii
> From: Marcin Borkowski <[hidden email]>
> Cc: [hidden email]
> Date: Fri, 29 Apr 2016 14:18:34 +0200
>
> >> +    (looking-at "[^[:alpha:]][[:alpha:]]")))
> >
> > You should be aware that starting with Emacs 25.1 [:alpha:] matches a
> > very large class of characters, some of them having nothing in common
> > with those used in Polish.  So perhaps it is better to use '\cl'
> > instead, which will only capture Latin characters?  Just a thought --
> > your call.
>
> I guess you are right, Eli - in fact, all one-letter words in Polish are
> matched by [aiouwz].  I decided to go with \cl, as you suggested,
> though - this way, the function could be (probably) useful also for
> Slovaks, for instance.  I attach the corrected patch.

LGTM, thanks.

> Just to be sure: in my Emacs, \cl matches also ą, ę, ż, ź, á, ö etc.  Is
> it intentional?

Yes.  \cl matches any character that belongs to any of the Latin
blocks.

> Is it documented somewhere?

Not sure what needs to be documented, please elaborate.



Reply | Threaded
Open this post in threaded view
|

bug#20871: 25.0.50; fill-single-char-nobreak-p does not recognize a single-letter word when it is preceded by an open paren

Marcin Borkowski-3

On 2016-04-30, at 13:21, Eli Zaretskii <[hidden email]> wrote:

>> From: Marcin Borkowski <[hidden email]>
>> Cc: [hidden email]
>> Date: Fri, 29 Apr 2016 14:18:34 +0200
>>
>> >> +    (looking-at "[^[:alpha:]][[:alpha:]]")))
>> >
>> > You should be aware that starting with Emacs 25.1 [:alpha:] matches a
>> > very large class of characters, some of them having nothing in common
>> > with those used in Polish.  So perhaps it is better to use '\cl'
>> > instead, which will only capture Latin characters?  Just a thought --
>> > your call.
>>
>> I guess you are right, Eli - in fact, all one-letter words in Polish are
>> matched by [aiouwz].  I decided to go with \cl, as you suggested,
>> though - this way, the function could be (probably) useful also for
>> Slovaks, for instance.  I attach the corrected patch.
>
> LGTM, thanks.

Thanks!

>> Just to be sure: in my Emacs, \cl matches also ą, ę, ż, ź, á, ö etc.  Is
>> it intentional?
>
> Yes.  \cl matches any character that belongs to any of the Latin
> blocks.
>
>> Is it documented somewhere?
>
> Not sure what needs to be documented, please elaborate.

Well, at first I thought that "Latin" means "matching [a-z]".  Finding
out that accented letter qualify, too, was a (pleasant) surprise.
Finding that out using `describe-categories' is a bit tricky, since its
output contains ranges, and I don't know which of them does e.g. "ą"
belong to.  The output of `describe-categories' says "Legend of category
mnemonics (see the tail for the longer description)"; I guess the
"longer" description might say something more.  For instance, this line:

(define-category ?l "Latin")

in characters.el

could be replaced by

(define-category ?l "Latin
Latin letters (including those with diacritics)")

This way, there would be at least a hint at the bottom of the *Help*
buffer displayed by `describe-categories'.

WDYT?  Would you like me to prepare a patch?

Best,

--
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University



Reply | Threaded
Open this post in threaded view
|

bug#20871: 25.0.50; fill-single-char-nobreak-p does not recognize a single-letter word when it is preceded by an open paren

Eli Zaretskii
> From: Marcin Borkowski <[hidden email]>
> Cc: [hidden email]
> Date: Sat, 30 Apr 2016 14:26:28 +0200
>
> (define-category ?l "Latin")
>
> in characters.el
>
> could be replaced by
>
> (define-category ?l "Latin
> Latin letters (including those with diacritics)")

That doesn't sound right: why single out diacritics?  And why only for
Latin?

If we want to enhance those doc strings, each one of them should state
what Unicode blocks are covered.  (It would be okay to say something
like "all Latin blocks", instead of enumerating them all, and
similarly for the other categories.)

Thanks.



Reply | Threaded
Open this post in threaded view
|

bug#20871: 25.0.50; fill-single-char-nobreak-p does not recognize a single-letter word when it is preceded by an open paren

Marcin Borkowski-3

On 2016-04-30, at 14:38, Eli Zaretskii <[hidden email]> wrote:

>> From: Marcin Borkowski <[hidden email]>
>> Cc: [hidden email]
>> Date: Sat, 30 Apr 2016 14:26:28 +0200
>>
>> (define-category ?l "Latin")
>>
>> in characters.el
>>
>> could be replaced by
>>
>> (define-category ?l "Latin
>> Latin letters (including those with diacritics)")
>
> That doesn't sound right: why single out diacritics?  And why only for
> Latin?

Because I don't really know what this category is about?

I think that my confusion is a sufficient proof that more precise
documentation is needed.

> If we want to enhance those doc strings, each one of them should state
> what Unicode blocks are covered.  (It would be okay to say something
> like "all Latin blocks", instead of enumerating them all, and
> similarly for the other categories.)

A user might not know what exactly a "Unicode block" is.  (I don't.)
I think a pointer to some sources or a few words of explanation are
really needed.  (I won't make a patch, though, since I clearly know too
little about it to do it correctly.)

> Thanks.

Best,

--
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University



Reply | Threaded
Open this post in threaded view
|

bug#20871: 25.0.50; fill-single-char-nobreak-p does not recognize a single-letter word when it is preceded by an open paren

Eli Zaretskii
> From: Marcin Borkowski <[hidden email]>
> Cc: [hidden email]
> Date: Sat, 30 Apr 2016 18:41:32 +0200
>
> >> (define-category ?l "Latin
> >> Latin letters (including those with diacritics)")
> >
> > That doesn't sound right: why single out diacritics?  And why only for
> > Latin?
>
> Because I don't really know what this category is about?
>
> I think that my confusion is a sufficient proof that more precise
> documentation is needed.

I didn't object to expanding the doc string, I only suggested that we
do it right.

> > If we want to enhance those doc strings, each one of them should state
> > what Unicode blocks are covered.  (It would be okay to say something
> > like "all Latin blocks", instead of enumerating them all, and
> > similarly for the other categories.)
>
> A user might not know what exactly a "Unicode block" is.  (I don't.)
> I think a pointer to some sources or a few words of explanation are
> really needed.

A reference to the ELisp manual should do (the explanation should be
added to the manual first, of course).

> (I won't make a patch, though, since I clearly know too little about
> it to do it correctly.)

An opportunity to learn, I'd say.  You could start with
admin/unidata/Blocks.txt, for example.  We use it to generate
charscript.el (and categories are a semi-obsolete facility that
predates char-script-table).



Reply | Threaded
Open this post in threaded view
|

bug#20871: 25.0.50; fill-single-char-nobreak-p does not recognize a single-letter word when it is preceded by an open paren

Drew Adams
In reply to this post by Marcin Borkowski-3
> I think that my confusion is a sufficient proof that more precise
> documentation is needed.

+1.  Maybe not "more precise" (I cannot judge whether what is
there is precise), but more user-friendly.  It is fine (great)
to use the precise Unicode terminology and to point to the
Unicode standard for more information.  But it also helpful
to provide a little coaching in the Emacs doc, for us users
who are not Unicode pros.  It probably would not take much
additional explanation.

> > If we want to enhance those doc strings, each one of them should state
> > what Unicode blocks are covered.  (It would be okay to say something
> > like "all Latin blocks", instead of enumerating them all, and
> > similarly for the other categories.)
>
> A user might not know what exactly a "Unicode block" is.  (I don't.)
> I think a pointer to some sources or a few words of explanation are
> really needed.  (I won't make a patch, though, since I clearly know too
> little about it to do it correctly.)

+1

This kind of user feedback is helpful.  It should not be
ignored, IMO, especially if the reason for ignoring is just
that the doc is accurate and precise.  It's also about
being amenable (dare I say even "inviting") to an average
Emacs user.



Reply | Threaded
Open this post in threaded view
|

bug#20871: 25.0.50; fill-single-char-nobreak-p does not recognize a single-letter word when it is preceded by an open paren

Eli Zaretskii
> Date: Sat, 30 Apr 2016 09:42:28 -0800 (GMT-08:00)
> From: Drew Adams <[hidden email]>
> Cc: [hidden email]
>
> This kind of user feedback is helpful.  It should not be
> ignored

Did I ignore it?



Reply | Threaded
Open this post in threaded view
|

bug#20871: 25.0.50; fill-single-char-nobreak-p does not recognize a single-letter word when it is preceded by an open paren

Marcin Borkowski-3

On 2016-04-30, at 20:24, Eli Zaretskii <[hidden email]> wrote:

>> Date: Sat, 30 Apr 2016 09:42:28 -0800 (GMT-08:00)
>> From: Drew Adams <[hidden email]>
>> Cc: [hidden email]
>>
>> This kind of user feedback is helpful.  It should not be
>> ignored
>
> Did I ignore it?

I don't think so.

Best,

--
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University



Reply | Threaded
Open this post in threaded view
|

bug#20871: 25.0.50; fill-single-char-nobreak-p does not recognize a single-letter word when it is preceded by an open paren

Marcin Borkowski-3
In reply to this post by Eli Zaretskii

On 2016-04-30, at 19:01, Eli Zaretskii <[hidden email]> wrote:

>> From: Marcin Borkowski <[hidden email]>
>> Cc: [hidden email]
>> Date: Sat, 30 Apr 2016 18:41:32 +0200
>>
>> >> (define-category ?l "Latin
>> >> Latin letters (including those with diacritics)")
>> >
>> > That doesn't sound right: why single out diacritics?  And why only for
>> > Latin?
>>
>> Because I don't really know what this category is about?
>>
>> I think that my confusion is a sufficient proof that more precise
>> documentation is needed.
>
> I didn't object to expanding the doc string, I only suggested that we
> do it right.

I didn't claim you objected.

>> > If we want to enhance those doc strings, each one of them should state
>> > what Unicode blocks are covered.  (It would be okay to say something
>> > like "all Latin blocks", instead of enumerating them all, and
>> > similarly for the other categories.)
>>
>> A user might not know what exactly a "Unicode block" is.  (I don't.)
>> I think a pointer to some sources or a few words of explanation are
>> really needed.
>
> A reference to the ELisp manual should do (the explanation should be
> added to the manual first, of course).
>
>> (I won't make a patch, though, since I clearly know too little about
>> it to do it correctly.)
>
> An opportunity to learn, I'd say.  You could start with
> admin/unidata/Blocks.txt, for example.  We use it to generate
> charscript.el (and categories are a semi-obsolete facility that
> predates char-script-table).

You got me here.  The problem is, I'm not going to have a lot of free
time in the next few weeks/months.  (I'll also probably have to stop any
work on Emacs bugs for some time, for instance.)  But I'll try to look
into this one.

Best,

--
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University



Reply | Threaded
Open this post in threaded view
|

bug#20871: 25.0.50; fill-single-char-nobreak-p does not recognize a single-letter word when it is preceded by an open paren

Eli Zaretskii
> From: Marcin Borkowski <[hidden email]>
> Cc: [hidden email]
> Date: Sat, 30 Apr 2016 20:42:43 +0200
>
> > An opportunity to learn, I'd say.  You could start with
> > admin/unidata/Blocks.txt, for example.  We use it to generate
> > charscript.el (and categories are a semi-obsolete facility that
> > predates char-script-table).
>
> You got me here.  The problem is, I'm not going to have a lot of free
> time in the next few weeks/months.

There's no rush.  You shouldn't feel hard-pressed for a quick job.

> But I'll try to look into this one.

Great, thanks.



12