August 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: vc-revert-buffer1 sacrifices fontification preserving minor modes 25 years, 3 months

Adrian Aichner

>>>>> "Raymond" == Raymond Toy <toy(a)rtp.ericsson.se> writes: APA> Which font-locking method do we want to promote? Raymond> But lazy-shot has the same font-locking problem: Raymond> revert-buffer doesn't fontify the buffer. Yep, as I said earlier in this thread, only fast-lock retains fontification for me under 21.1.4. Adrian Raymond> Ray

1 participants
0 comments

Re: vc-revert-buffer1 sacrifices fontification preserving minor modes 25 years, 3 months

Raymond Toy

>>>>> "APA" == Adrian Aichner <aichner(a)ecf.teradyne.com> writes: >>>>> "sb" == SL Baur <steve(a)xemacs.org> writes: >>> Should sample.emacs be changed if lazy-lock-mode is really >>> lazy-good-for-nothing-lock? sb> If we must recommend defaulting to lazy font-locking, then it should sb> probably be the lazy-shot flavor. At least that version works in an sb> XEmacs-y sort of way. APA> Which font-locking method do we want to promote? But lazy-shot has the same font-locking problem: revert-buffer doesn't fontify the buffer. Ray

1 participants
0 comments

Re: vc-revert-buffer1 sacrifices fontification preserving minor modes 25 years, 3 months

Adrian Aichner

>>>>> "APA" == Adrian Aichner <aichner(a)ecf.teradyne.com> writes: APA> Which font-locking method do we want to promote? Just for the record: ;;; This retains fontification across vc-revert-buffer1: (add-hook 'font-lock-mode-hook 'turn-on-fast-lock) ;;; Following lose fontification in 'vc-revert-buffer1 under ;;; ms-windows: ;;; (add-hook 'font-lock-mode-hook 'turn-on-lazy-shot) ;;; (add-hook 'font-lock-mode-hook 'turn-on-lazy-lock) APA> I think we should change sample.emacs accordingly. APA> Adrian

1 participants
0 comments

Re: GNU Emacs' rect.el 25 years, 3 months

Hrvoje Niksic

Yoshiki Hayashi <t90553(a)m.ecc.u-tokyo.ac.jp> writes: > > The question is: which Latin characters? What are "normal > > settings" to you? Does this mean that when I change my font (as I > > do, because the default one is awful), the twice-as-wide > > relationship gets lost? > > Probably Latin-1. I guess Latin-2 is the same. It has nothing to do > with font setting. Japanese characters display twice as wide and it > also takes two columns. Impossible. Whatever Latin fonts I choose, I see the same Japanese characters. So if I choose a wider Latin font (which I do, because the defaults are too small), there is no chance in hell that the Japanese glyphs *still* display exactly twice as wide as the Latin ones. > I mean, if the line is only US-ASCII and what-cursor-position > returns column 40, the line has 40 characters. If there are > Japanese characters and what-cursor-position returns column 40, > there may be only 20 characters. IMO `what-cursor-position' should either count the characters or maybe the pixels. Anything else is bound to be broken in almost every situation. I know the FSF did differently, and I think they made a mistake. > For example, next part contain 11 Japanese > characters. At the end of the line, what-cursor-position > will say column 22. > この行は十一文字です。 This is a "feature" of the `current-column' function, which in turn calls column_at_point(), which contains this: #ifdef MULE col += XCHARSET_COLUMNS (CHAR_CHARSET (c)); #else col ++; #endif /* MULE */ IMO the code above is wrong, and the function should simply return 11, not 22.

5 participants
4 comments

Re: vc-revert-buffer1 sacrifices fontification preserving minor modes 25 years, 3 months

Adrian Aichner

>>>>> "sb" == SL Baur <steve(a)xemacs.org> writes: >> Should sample.emacs be changed if lazy-lock-mode is really >> lazy-good-for-nothing-lock? sb> If we must recommend defaulting to lazy font-locking, then it should sb> probably be the lazy-shot flavor. At least that version works in an sb> XEmacs-y sort of way. Which font-locking method do we want to promote? I think we should change sample.emacs accordingly. Adrian

1 participants
0 comments

Re: vc-revert-buffer1 sacrifices fontification preserving minor modes 25 years, 3 months

SL Baur

Adrian Aichner <aichner(a)ecf.teradyne.com> writes in xemacs-beta(a)xemacs.org: >>>>>> "sb" == SL Baur <steve(a)xemacs.org> writes: ... sb> The remove-hook call should be redundant. Do you have an sb> earlier site*.el file that unconditionally turns on sb> lazy-good-for-nothing-lock? > My site-start.el does > (load-file (locate-file "sample.emacs" (list data-directory))) > so that I find breakage and new features ASAP. O.K. You've written about this before and I forgot, sorry. > sample.emacs does > (add-hook 'font-lock-mode-hook 'turn-on-lazy-lock) > Hence the (remove-hook ...) is required in my site-start.el. Right. > Should sample.emacs be changed if lazy-lock-mode is really > lazy-good-for-nothing-lock? If we must recommend defaulting to lazy font-locking, then it should probably be the lazy-shot flavor. At least that version works in an XEmacs-y sort of way.

1 participants
0 comments

Re: vc-revert-buffer1 sacrifices fontification preserving minor modes 25 years, 3 months

Adrian Aichner

>>>>> "sb" == SL Baur <steve(a)xemacs.org> writes: sb> Adrian Aichner <aichner(a)ecf.teradyne.com> writes in sb> xemacs-beta(a)xemacs.org: >> When I add this to site-start.el: >> (remove-hook 'font-lock-mode-hook 'turn-on-lazy-lock) >> (add-hook 'font-lock-mode-hook 'turn-on-fast-lock) >> vc-revert-buffer1 retains the fontification! sb> The remove-hook call should be redundant. Do you have an sb> earlier site*.el file that unconditionally turns on sb> lazy-good-for-nothing-lock? My site-start.el does (load-file (locate-file "sample.emacs" (list data-directory))) so that I find breakage and new features ASAP. sample.emacs does (add-hook 'font-lock-mode-hook 'turn-on-lazy-lock) Hence the (remove-hook ...) is required in my site-start.el. Should sample.emacs be changed if lazy-lock-mode is really lazy-good-for-nothing-lock? Adrian

1 participants
0 comments

Re: E-mail abuse report (was: Stuff Your Mailbox With $600 Checks...) 25 years, 3 months

SL Baur

With the exception of xemacs-announce, all other XEmacs mailing lists are open to submissions from non-subscribers. Occasionally, an idiot will send SPAM to them. Please check the headers very carefully before complaining to tux.org. I would strongly suggest using a procmail recipe along the lines of (using xemacs-beta as an example). :0 w: * ^Return-Path:.*xemacs-beta(-request)?＠ * ^TOxemacs-(announce|beta)＠ xemacs-beta.spool This has all filtered all SPAM sent to xemacs-beta for me. It drops Bcc'ed mail, but it is very rude to send Bcc'ed mail to mailing lists anyway. Followups to me or Jason or xemacs-beta, please. TUX ORG Abuse Tracing <abuse(a)tux.org> writes: > This message was sent via an open relay in Korea by its original sender, > whose traces do not remain in this message. It is unlikely that zzn.com > had anything to do with this message. TUX.ORG's only involvement is that > we host the xemacs-beta mailing list, which was spammed, and to which you > were presumably a subscriber. We have anti-spam countermeasures in place, > but there is no reliable defense against spams that are sent via > third-party relays. > I would suggest you complain to the operator of the Korean host about their > open relay, and see if they can find out from their logs who actually sent > the message: > ns.hanyon.co.kr [203.231.147.1] > Jason and Steve, could you send out another reminder to your subscribers > that they have subscribed to open-post mailing lists and that they should > not blame TUX.ORG when these lists get spammed? > Thanks, > David C Niemi > abuse(a)tux.org

1 participants
0 comments

Re: XEmacs 21.2 release checklist (was Re: GNU Emacs new isearch feature) 25 years, 3 months

SL Baur

Jeff Miller <jmiller(a)smart.net> writes in xemacs-beta(a)xemacs.org: >>>>>> "sb" == SL Baur <steve(a)xemacs.org> writes: sb> 1. Fix new build problems ie. with X, without menubars, etc. > I've added several new configuration tests to my mega build script, > it's now up to 21 tests. Very nice. Thanks.

1 participants
0 comments

Re: Merging with GNU Emacs 25 years, 3 months

SL Baur

Antonio Freixas <tonyf(a)ims.com> writes in xemacs-beta(a)xemacs.org: >> Hrvoje Niksic <hniksic(a)srce.hr> writes in xemacs-beta(a)xemacs.org: >> >> > Pixel-based scrolling, which would require clipping the top-most line >> > in addition to the bottom-most one, would be really cool. >> >> And pixel-based filling, so auto-filling works properly with variable >> width fonts. > Won't it take more than that to make auto-filling work properly? In the common usage of reading mail/news with a variable width font it will be fine. > Since face information is not saved with a text file, the next person > that views the variable-width auto-filled file won't necessarily get > the same nice filling. Right. > It seems that to make this work, you have to define a word-processor > mode. Several people over the years have stated their intentions to hack on something like this, but nothing has ever come out of it. Probably due to the lack of pixel-based operations. I would very much like to have a word-processor mode.

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 August 1999