September 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Huge auto-fill-mode bug intro'd in 20.0 still not fixed in 21.2.19 24 years, 7 months

Dan Harkless

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > >>>>> "Dan" == Dan Harkless <dan-xemacs(a)dilvish.speed.net> writes: > > Dan> What is not appropriate is breaking auto-fill for all Western > Dan> languages just because one's XEmacs was built with Mule > Dan> (which, for instance, a sysadmin wanting to make the > Dan> installation useful for as many users as possible might do, > Dan> even if nobody at the site was ever destined to use > Dan> Japanese). > > This isn't at issue, since the bug in question is in the layer below > Mule. Yes, but the fix might not necessarily be. The "bug" is simply the inclusion of Japanese-specific processing in code that gets executed for everyone. I'm just saying that wrapping that code in an "(if (featurep 'mule)...)" is not an acceptable solution. It sort of sounded like you were advocating that, since you specifically noted that it was unacceptable for the kinsoku processing to be happening in a non-MULE XEmacs (with the implication that it would be OK for it to happen in a MULE XEmacs, even if one wasn't using Japanese). ----------------------------------------------------------------------- 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.

1 participants
0 comments

Re: Huge auto-fill-mode bug intro'd in 20.0 still not fixed in 21.2.19 24 years, 7 months

Dan Harkless

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > For non-Mule XEmacs, I agree with you and Hrvoje: it must be the > traditional "fill column is a hard limit and trailing whitespace is > always trimmed". Old-timers are used to it, newbies learn it very > fast, and it is compatible with typical coding standards. > > For Japanese, it must be kinsoku. What to do with space is > problematic; since removing embedded spaces is destroying > intentionally introduced textual data, we should default to leaving > them in. I have no problem with that if, as was suggested before, character set checks (or even manual variable settings) are employed to determine whether kinsoku is appropriate. What is not appropriate is breaking auto-fill for all Western languages just because one's XEmacs was built with Mule (which, for instance, a sysadmin wanting to make the installation useful for as many users as possible might do, even if nobody at the site was ever destined to use Japanese). ----------------------------------------------------------------------- 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.

2 participants
1 comments

Re: Huge auto-fill-mode bug intro'd in 20.0 still not fixed in 21.2.19 24 years, 7 months

Hrvoje Niksic

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > For non-Mule XEmacs, I agree with you and Hrvoje: it must be the > traditional "fill column is a hard limit and trailing whitespace is > always trimmed". Old-timers are used to it, newbies learn it very > fast, and it is compatible with typical coding standards. > > For Japanese, it must be kinsoku. Oh no! Please tell me that you are not confronting "non-Mule XEmacs" with "Japanese"! I am using a Mule XEmacs in Croatian environment and I have *nothing* to do with the Japanese language. Mule is not Japanese-only. Or should not be. > What to do with space is problematic; since removing embedded spaces > is destroying intentionally introduced textual data, we should > default to leaving them in. If the Japanese want them in, they'll can have them. But please don't break the rest of the world. Besides, I'm no longer even convinced that the Japanese want them. A Japanese correspondent (I think it was OISHI Kazuo) made it clear that he didn't care about the issue either way.

2 participants
1 comments

linux-alpha xemacs-21.2 I give up 24 years, 7 months

Neal D. Becker

I have tried to build xemacs-21.2 on linux-alpha RH6.0 using every version of gcc/egcs I can find on my system, but I can't find one that works. This is the same problem I saw back about 1 year ago. After dumping, xemacs says: Dumping under the name xemacs Testing for Lisp shadows ... temacs can only be run in -batch mode. This tells me that unexec is not working - I think the variables aren't initialized properly. Back 1 year ago, the solution was to use an old egcs. I guess maybe it was removed by the upgrade from RH5.1 to RH6.0. What about the rest of you? What egcs/gcc version did you use to build xemacs-21.2 on alpha/linux?

1 participants
0 comments

Re: latest CVS and tabs 24 years, 7 months

Jan Vroonhof

Stef Epardaud <stef(a)lunatech.com> writes: > as of latest CVS on Wed Sep 22 19:07:47 CEST 1999 > the "C-x f C-o" thing doesn't happen anymore, the tabs stay in place and > behave, however this one is still there and it just makes xemacs crash > every time i press any key when the mouse is over the tabs. Where? This is the xic crash again probably. I am betting (didn't look) that Andy didn't update x_any_window_to_frame to work with the new Xt widgets. x_window_to_any_frame should really be made to look like x_any_widget_or_parent_to_frame(XtWindowToWidget(..)) (modulo changing to true function names). Jan

2 participants
2 comments

Re: Huge auto-fill-mode bug intro'd in 20.0 still not fixed in 21.2.19 24 years, 7 months

Jan Vroonhof

Olivier Galibert <galibert(a)pobox.com> writes: > [1] Which, IMHO, was a mistake. Please keep x-r for patchs ack's and > use x-b and x-m for discussions. This is a very open development, > let's keep it that way and not close ourselves by getting bad habits > :-) It was supposed to go to xemacs-patches (because it contained a patch). But as everybody knows by now, I screwed up. Jan

1 participants
0 comments

Re: Huge auto-fill-mode bug intro'd in 20.0 still not fixed in 21.2.19 24 years, 7 months

Dan Harkless

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > Not really relevant to the list anymore. It seems like very relevant info to me, especially the discussion of the right-justification issue below. Pardon me if I send this to the lists. > >>>>> "Dan" == Dan Harkless <dan-xemacs(a)dilvish.speed.net> writes: > > Dan> "Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> MIS-attributes! > > Dan> Uh, no, I did not write the above. That was Hrvoje as well. > > Very sorry. My bad. > > >> OK. Since Dan has provided an algorithm to replicate the > >> problem, it should get fixed soon enough. > > Dan> Actually, I provided an algorithm to replicate the problem > Dan> back in April of '98, but I guess my bug just got recorded > Dan> then forgotten about, rather than becoming a topic of > Dan> discussion on xemacs-beta. > > I didn't see it, or didn't notice it (I'm mostly interested in Mule). I just posted my bug to comp.emacs.xemacs. Steven Baur then replied that he had recorded it. > I'm not referring to your usage, anyway. I don't like it when threads > get introduced into xemacs-beta in the middle just so that people can > bitch about Mule. xemacs-beta or xemacs-mule? > (That probably wasn't the intent, but since whoever > diverted the thread - Hrvoje, Jan - didn't explain anything about the > mechanics of the bug, that was the effect.) My recent comp.emacs.xemacs post (which was apparently what was forwarded) explained it in brief and included a URL to my original comp.emacs.xemacs bug report, which explained it in more detail. > >> This would not be acceptable in Japanese. > > Dan> Why not? If a space is so important, wouldn't it be better > Dan> to _not_ have it at the end of a line, where it's invisible? > > Because you want it to reappear when refilling takes place. Using ^ > and $ to mark line beginning and end of lines: > > ^NormalJapaneseTextLooksLikeThisAllRunTog$ > ^etherWithNotEnoughPunctuationAndLinesAre$ > ^BrokenWillyNillyExceptThatALineShouldNot$ > ^StartWithPunctuationIncludingExplicitWhi$ > ^teSpace.$ > > Using spaces for emphasis: > > ^NormalJapaneseTextLooksLikeThisAllRunTog$ > ^etherWithNotEnoughPunctuationAndLinesAre$ > ^BrokenWillyNillyExceptThatALineShouldNot$ > ^StartWithPunctuation, Including Explicit $ > ^WhiteSpace.$ > > Inserting, > > ^NormalJapaneseTextUSUALLYLooksLikeThisAl$ > ^lRunTogetherWithNotEnoughPunctuationAndL$ > ^inesAreBrokenWillyNillyExceptThatALineSh$ > ^ouldNotStartWithPunctuation, Including E$ > ^xplicit WhiteSpace.$ > > See how the space between "explicit" and "whitespace" comes back? I'm not advocating removing it. I was suggesting: ^NormalJapaneseTextLooksLikeThisAllRunTog$ ^etherWithNotEnoughPunctuationAndLinesAre$ ^BrokenWillyNillyExceptThatALineShouldNot$ ^StartWithPunctuation, Including $ ^Explicit WhiteSpace.$ And if "Including Explicit WhiteSpace" is in romaaji, which I take it is the most common usage of explicit whitespace in Japanese writing, you can't always avoid that ragged right side (in fixed-width text), so the above should be acceptable. If "Including Explicit WhiteSpace" is Japanese, however, I finally see why one might want to put the space past fill-column. Nobody had brought up this right-justification issue until now (or if they did, I missed it). However, if you're using explicit white space in Japanese, you can't have a clean right side in all cases -- what about: ^NormalJapaneseTextLooksLikeThisAllRunTog$ ^etherWithNotEnoughPunctuationAndLinesAre$ ^BrokenWillyNillyExceptThatALineShouldNot$ ^StartWithPunctuation Including Explicit $ ^WhiteSpace.BlahBlahBlahBlahBlahBlahBlah.$ > >> 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). > > Dan> Yeah, I know some people would find it unacceptable -- > Dan> that's why I was proposing it be controlled by a variable > Dan> that you can set either way. But I think you may be > Dan> overestimating the number of people who'd find it > Dan> unaccepable anyway -- look how long this extra space bug has > Dan> persisted... > > I think you're underestimating the number of people who can visually > estimate the length of the word "the" but can't see empty space. In all my non-email, non-newsgroup-post buffers, I set the fill-column to 80 (and have my XEmacs window 81 columns wide -- an annoying necessity), so anytime there's an extra space at the end of the line, I see the line-wrap "curly arrow", not just "empty space". I'd think most people would want to use all of the columns they're entitled to... > Only people who are writing to strict coding standards with automatic > checking software are likely to find the bug "highly" annoying. (A > few people will naturally find it a pain in the neck, of course, but > they will be few.) No, like I say, anyone who has fill-column set to the width of the window minus 1. > Dan> That's a fundamental failure in what auto-fill > Dan> claims to do, and it's been broken ever since 20.0. > > Documentation? Info says "break at appropriate places". > "Appropriate" is culturally determined, eg, by company coding > standards. Okay, you got me there. I didn't re-read the documentation before saying that, and I was remembering it as being defined mechanically in terms of fill-column. > >> Unfortunately, people who write in Japanese often need both > >> behaviors in the same buffer (as Hrvoje points out). > > Dan> Hmmm. Do they *need* both behaviors? I still fail to see > Dan> what's so bad about breaking at the previous boundary if > Dan> you've specifically told xemacs you want to preserve spaces. > > Yes. The above text is how many Japanese write English embedded in > Japanese (except that they wouldn't use capitals to indicate word > breaks as I did). Such authors don't need both. That is not > acceptable in most academic writing, however; the English should look > like English. Such embedding is an everyday occurance, the need is > real. With the right-justification issue in play, I now understand how this could be the case. > Dan> So what'll happen? In Asian languages, auto-fill will fail > Dan> to perform as advertised, allowing you to get lines of > Dan> (fill-column + 1) columns, whereas in Western languages, that > Dan> won't be the case? > > Yes. It's not just the magic space, it's all punctuation. Lines may > not start with punctuation. There are two styles. In one, > punctuation at the end of the line is retained, resulting is lines > going past the fill column. Most Japanese texts seem to do this. (In > fact, I have seen proportionally filled text with exdented > punctuation.) Wow. Sounds pretty ugly. If that's common usage, however, especially in printed material, that really changes things. I thought we were just talking about two different views of "getting all the columns one is entitled to" in XEmacs. > This style is often seen in programming (the exdented > "*/" terminator, right?) by Westerners, too. But the "*/" doesn't go past fill-column. > I believe that some old style manuals recommend this style for English, > too. The alternative style is to have some short lines, as in English. > This is pretty ugly, IMHO, and evidently most Japanese agree. Or to have variable-width spaces (or multiple spaces in series in a fixed-width environment). > Dan> Seems pretty hokey to me > > Please. If you don't understand the language, don't go there. Shall > we start on English spelling? I didn't mean the Japanese usage seemed hokey, I meant XEmacs' definition of fill-column and auto-fill seemed hokey, if it was only trying to artifically gain Japanese users 1 extra column in certain situations. Again, the right-justification bit definitely changes my understanding of the issue. > Dan> I know it'd bug the heck out of me if I had fill-column set > Dan> to 80 and was working on a buffer of C code with Japanese > Dan> comments (I had to do this frequently at my previous job), > Dan> and the C code would auto-fill properly, but the Japanese > Dan> comment lines would occasionally be 81 columns, breaking my > Dan> company's coding style policy, and me with no way to stop > Dan> that from happening. > > Well, your company's coding style policy conflicts with the relevant > national standard, then. (AFAIK it is in fact a Japanese national > standard that specifies the two styles of line breaking.) I believe > both are supported by Mule.... > > ...Yes. (setq kinsoku-extend-limit 0) does what you want. > > Except that it probably doesn't in the pre-Hrvoje-reversion-code, as > that variable only exists in Mule. So obviously the behavior you > reported is a bug. (Please note that nobody bothered to say that this > behavior introduced to support Asian languages was occurring in > non-Mule XEmacsen, either; even you only noted it as a "by-the-way"!) Well, that was discussed, but yes, perhaps could have been stressed more. However, I wouldn't want the spaces past fill-column just because I had built my XEmacs with MULE support (but wasn't actively using it). ----------------------------------------------------------------------- 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.

3 participants
2 comments

Re: Xaw3d struct size bogosity [was: Subwindow clipping] 24 years, 7 months

SL Baur

[In a build from yesterday's CVS, I have again an unexpected blank gutter in this message-mode buffer. I'm not sure how it happened, but this is not the first time. ... More info. ... When I switch virtual consoles (in WindowMaker) and return to the XEmacs virtual console, the buttons reappear. After hitting C-l (sometimes it is taking multiple presses), they promptly disappeared again, see attached screen dumps. This is at best intermittent because most of the time it does not happen.] Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes in xemacs-beta(a)xemacs.org: >>>>>> "Glynn" == Glynn Clements <glynn(a)sensei.co.uk> writes: ... Glynn> This indicates that the Xaw headers used for compilation Glynn> don't match the libXaw.so which is being used at run-time Glynn> (e.g. compiling with vanilla Xaw headers but using the Glynn> libXaw.so from Xaw3d). > This is still happening to me ... I've confirmed (using CPPFLAGS=-H) > that I'm getting the right headers ... ldd src/xemacs tells me I'm > getting the right library ... but bogosity rules!! > Aha! > Debian (unstable == potato, current as of a couple days ago) supplies > both the standard libXaw.so and a libXaw3d.so, by those names, in > /usr/X11R6/lib. This is unlikely to go away since there are several > programs that don't seem to coexist with Athena 3D for some reason. > `ln -sf libXaw3d.so.6.1 libXaw.so' and bingo! no errors. But I don't > think I want to do this permanently. > Or do I? (Advice, please.) > If not, Would it be reasonable for ./configure (once it has decided > to use Xaw3d) to test for the existence of libXaw3d.so (and maybe > libXaw3d.a, but maybe not) and do `-lXaw3d' instead of `-lXaw' in > that case? That might be reasonable now. Does Debian also include fuckage[1] in the form of having Xaw3d includes in <X11/Xaw3d>? [Gutter bogosity snapshots] Footnotes: [1] Like, for example, TurboLinux does.

3 participants
2 comments

Error in `pre-command-hook' (tabs problem) 24 years, 7 months

Stef Epardaud

i just thought i'd click on the tab to change buffer and i got that: (1) (error/warning) Error in `pre-command-hook' (setting hook to nil): (wrong-type-argument unable to bind this type of event #<misc-user-event (eval (buffers-tab-switch-to-buffer "EXSL.java"))>) i have not the faintest clue what it all means, because it actually did change buffer... and i cannot seem to be able to reproduce it either... just thought you might want to know... for the record... -- # Stef Epardaud, # There is no limit to the power of computing ... # Java Defeater # ... except men maybe ? # Earth # Lunatech Research, # Solar System # soon we will quit researching and start finding...

1 participants
0 comments

Re: merge describe-variable and customize-variable? 24 years, 7 months

Jan Vroonhof

Gunnar Evermann <ge204(a)eng.cam.ac.uk> writes: > I think it would be nice if there were a single command which acted > like customize-variable if the variable were customizable and like > describe-variable otherwise. (In fact, maybe this command should be > bound to C-h v by default.) Doesn't customize variable already work for all variables? The FSF has keybinding that allows you to jump from C-h v to the customize buffer. That is a good idea again. Similarly one could have a [Change] button. Jan

1 participants
0 comments

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

XEmacs-Beta September 1999