Re: Huge auto-fill-mode bug intro'd in 20.0 still not fixed in 21.2.19

Monday, 20 September 1999

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp&gt; writes:
...
 >>>>> "Hrvoje" == Hrvoje Niksic
<hniksic(a)srce.hr&gt; writes:

     Hrvoje> "Dan Harkless" <dan-xemacs(a)dilvish.speed.net&gt; writes:
     >> People working in Japanese would just need to be sure to set
     >> that variable (if there weren't some automatic way of turning
     >> it on while working in Japanese buffers).

     Hrvoje> At least part of the problem is that there is (or should
     Hrvoje> be) no such thing as a "Japanese buffer".  Any buffer can
     Hrvoje> contain any character.  XEmacs does not yet know anything
     Hrvoje> about specific languages, either.

 No, but obviously modes that do text-filling should know about them.

     Dan> We'll revert to the state of affairs when things worked for
     Dan> European languages, and then we'll accept correct fixes for
     Dan> Japanese.       ^^^
Uh, no, I did not write the above.  That was Hrvoje as well.

...
 OK.  Since Dan has provided an algorithm to replicate the problem,
it
 should get fixed soon enough. 
Actually, I provided an algorithm to replicate the problem back in April of
'98, but I guess my bug just got recorded then forgotten about, rather than
becoming a topic of discussion on xemacs-beta.

...
 Don't forget put "there are changes in this version of
XEmacs that
 cause potential data loss for Japanese (at least) using kinsoku
 processing" in the ChangeLog entry, NEWS, and PROBLEMS.

 >>>>> "Dan" == Dan Harkless <dan-xemacs(a)dilvish.speed.net&gt;
writes:

     Dan> I don't have an xemacs built with mule, so I can't try it,
     Dan> but do you get lines of (fill-column + 1) columns if you type
     Dan> a space at fill-column in Japanese too?

 OK, I see this.  So it's not the `(if (featurep 'mule) (kinsoku-nantoka))'
 calls.  Pity.

     Dan> If so, it seems like the current code is wrong for all
     Dan> languages -- what about my previous suggestion that the right
     Dan> thing to do if you need to preserve spaces is to have
     Dan> auto-fill actually go back and break at the _previous_ legal
     Dan> fill boundary?  Then the unbreakable text at the end of the
     Dan> line and the space after it would go down to the beginning of
     Dan> the next line.

 This would not be acceptable in Japanese.   
Why not?  If a space is so important, wouldn't it be better to _not_ have it
at the end of a line, where it's invisible?

...
 I think it would be pretty unacceptable in English too (people will
go
 nuts with three-letter words that don't fit into four letter spaces at the
 end of the line). 
Yeah, I know some people would find it unacceptable -- that's why I was
proposing it be controlled by a variable that you can set either way.  But I
think you may be overestimating the number of people who'd find it
unaccepable anyway -- look how long this extra space bug has persisted...
That's a fundamental failure in what auto-fill claims to do, and it's been
broken ever since 20.0.

...
     Dan> There could even be a variable like
     Dan> [auto-?]fill-preserve-spaces or something like that that you
     Dan> could set in any language that would cause that behavior.  If
     Dan> it wasn't set, the old correct (Western language) behavior of
     Dan> changing the space to a newline would apply.

 Unfortunately, people who write in Japanese often need both behaviors
 in the same buffer (as Hrvoje points out). 
Hmmm.  Do they *need* both behaviors?  I still fail to see what's so bad
about breaking at the previous boundary if you've specifically told xemacs
you want to preserve spaces.

...
 Steve Baur suggested that we could do a charset test on the
character
 at a candidate point; I think that's good enough in general. 
So what'll happen?  In Asian languages, auto-fill will fail to perform as
advertised, allowing you to get lines of (fill-column + 1) columns, whereas
in Western languages, that won't be the case?

Seems pretty hokey to me, but if that's the way it's implemented, I hope the
documentation for auto-fill-mode and/or fill-column explains that it will
fail to break the line at fill-column in that one specific case (and
hopefully there'll be at least a phrase saying why the heck that is -- I
still don't understand, myself).

I know it'd bug the heck out of me if I had fill-column set to 80 and was
working on a buffer of C code with Japanese comments (I had to do this
frequently at my previous job), and the C code would auto-fill properly, but
the Japanese comment lines would occasionally be 81 columns, breaking my
company's coding style policy, and me with no way to stop that from
happening.

-----------------------------------------------------------------------
Dan Harkless                   | To prevent SPAM contamination, please 
dan-xemacs(a)dilvish.speed.net   | do not post this private email address
SpeedGate Communications, Inc. | to the USENET or WWW.  Thank you.     

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998