January 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Re: various cleanups and patches for 21.2b27 24 years, 3 months

Andy Piper

At 11:08 PM 1/18/00 +0100, Fabrice Popineau wrote: >- Andy stated that making the portable dumper work under win32 would >be more useful than 'upgrading' the unexec mechanism. Does everybody >agree ? If yes, I think that's not very difficult and should be done >quite soon here. Else I have imported the stuff from emacs-20.5 into >xemacs related to undumping if anybody is interested. I must say that >I have no idea of which method (pdump or unexec) is the most >interesting one. There are pros and cons for both of them. Kirill has made this work - his patches are in the latest cvs. >- Does SHLIB works under win32 ? What's the exact purpose ? Something >that would be great : load a dll, and the call its functions from >Lisp. It would be cool if someone could get this working under mswindows. andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd

1 participants
0 comments

Printing in Windows (and not only?) [was Re: Hi, there! :-)] 24 years, 3 months

Kirill 'Big K' Katsnelson

Some time ago, Andy Piper wrote... >I'm guessing this is what Kirill is thinking of. We'll see - Kirill is more >than capable of sorting it out :) Ok, my model is as follows. First, you create a printer *device*, which represents a connection to a printer, CreateDC(). Next, you create a *frame* on that device, which represents a print job, StartDoc(). Frame positioning on device surface determines printing margins, among other factors. The redisplay for the device is not performed automatically, redisplay() just skips redisplay_device() for those devices. It is done rather by (redisplay-frame) only. A frame may contain one buffer, or we can create three horizontally layered windows, for header and footer. It is a lisp code job, I do not care from the C part. If modeline is not disabled from the lisp code, it will be printed. If minibuffer is enabled, it will be printed. Just layout everything from the lisp code, call (redisplay-frame), and one page goes out. You then move the starting position of the window one windowfull down, adjust page number if used, and call (redisplay-frame) again, to get to the next page, all this from lisp. Deleting the frame commits print job. Deleting the device disconnects from the printer. The architecture is not MS-Windows specific. Are there any X libraries which treat paper surface just like window surface, to allow for WYSIWYG printing? Comments? Big K

3 participants
2 comments

[PATCH] Scroll unfixes 24 years, 3 months

Kirill 'Big K' Katsnelson

This is an unfix, because fixing this reveals a bunch of glitches. First of all, I want to point that the change which introduced window-pixel-scroll-increment was *not* a bug, it revealed a bug too. Without this change, the same effects show if the default face font is much shorter than the font used for current display lines. Second of all, printing will require this type of scroll, or at least an ability to position window in such a way that line is clipped. (If a display line is taller than N, it can be split between pages. Second page starts at that line, with its top clipped). So I want to keep this feature - it just has to be finished. Set window-pixel-scroll-increment to 1. When scrolling down using scrollbar arrow, display moves smoothly, jumping over line descents. This jumping is perhaps correct, so window display cannot start in a middle of inter-line spacing. When scrolling up, scroll goes smoothly only before the top of the partially obscured top line hits the window top. Since then, scrolling switches back to per-line scroll. I added code which fixes it, but it loses. It is #if0'ed now, and I would be grateful if someone can suggest me how to fix it. This is a problem #1. The problem #2 manifests itself when a top line is clipped. It remains clipped when a) buffers are switched in a window, b) when window is scrolled by way of regenerating it. I tried to find all places in regenerate where it should be reset, but it appears too deep in regenerate when the decision should be made to reset top clipping, so effectively regenerate should be restarted. As a solution, I want to introduce a window flag which tells regenerate *not* to reset clipping even if buffer has moved in the window vertically. If not set, regenrate_window will reset clipping. I do not feel this being an elegant solution though: regenerate is idempotent, so that it can be applied to a window many times with the same result; it stops being such when it depends on a flag which it resets by itself. I'd appreciate comments on that. Big K 2000-01-18 Kirill 'Big K' Katsnelson <kkm(a)dtmx.com> * window.c (window_scroll): Fixed a typo which caused Vwindow_pixel_scroll_increment to be disregarded. Added bits of #if0'ed code. It should be fixed and uncommented. Index: window.c =================================================================== RCS file: /var/cvsroot/xemacs/src/window.c,v retrieving revision 1.1.1.3 diff --unified=4 -r1.1.1.3 window.c --- src/window.c 2000/01/18 23:27:52 1.1.1.3 +++ src/window.c 2000/01/19 03:38:35 ＠＠ -4050,9 +4050,9 ＠＠ dla = window_display_lines (w, CURRENT_DISP); if (INTP (Vwindow_pixel_scroll_increment)) fheight = XINT (Vwindow_pixel_scroll_increment); - else if (!NILP (Vwindow_pixel_scroll_increment)); + else if (!NILP (Vwindow_pixel_scroll_increment)) default_face_height_and_width (window, &fheight, &fwidth); if (Dynarr_length (dla) >= 1) modeline = Dynarr_atp (dla, 0)->modeline; ＠＠ -4157,8 +4157,25 ＠＠ w->buffer); w->force_start = 1; w->start_at_line_beg = beginning_of_line_p (b, startp); MARK_WINDOWS_CHANGED (w); + +#if 0 + /* #### Scroll back by less than a line. This code loses + when a line being exposed at the top of the window has + different height than the current one. Display lines + array is not regenerated so far, so I see no way to + determine the height of the line which begins at + STARTP. Anyone? -- kkm */ + + if (!NILP (Vwindow_pixel_scroll_increment) + && Dynarr_length (dla) >= (1 + modeline) + && dl->ascent - dl->top_clip + fheight * value > 0) + { + WINDOW_TEXT_TOP_CLIP (w) = (dl->ascent - dl->top_clip + + fheight * value); + } +#endif if (!point_would_be_visible (w, startp, XINT (point))) { Bufpos new_point;

2 participants
1 comments

Re: [PATCH] Use system underline and struck thru fonts 24 years, 3 months

Hrvoje Niksic

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > >>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)iskon.hr> writes: > > Hrvoje> I liked the new FSF model a lot. > > Where can I read about this? On xemacs-beta. :-) Seriously, my source of information regarding Emacs 21 has been Bill Perry. Bill, can you point us to a design document describing the new FSF face model? > Surely you're not referring to Emacs 20.x. I'm not. The new stuff will be in Emacs 21, but it's already there and usable (according to reports I've seen.)

1 participants
0 comments

Re: LD_LIBRARY_PATH and --rpath ***please read*** 24 years, 3 months

Jan Vroonhof

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > "We" ain't the problem. If you'll recall, this thread restarted > because Debian tries to pretend that Xaw3d's lies are truth. So did somebody file that release critical bug with Debian? Jan

2 participants
1 comments

Re: [PATCH] bookmark.el of edit-utils 1.43 (completing-read usage error) 24 years, 3 months

Hrvoje Niksic

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > Hrvoje Niksic <hniksic(a)iskon.hr> writes: > > > I dislike the idea of our packages avoiding using our new features > > because of compatibility with old XEmacsen that need to be run with > > these very same packages. > > Note that "old" here means "the latest released version". Yes. But likewise the package concept should be expanded that "new" can mean "newer than the latest released version". > The packages need to target at the latest released, IMO. I see no reason why that would be the case for development packages. Many crucial things have been moved to the packages. There *has* to be a way to update those things when core XEmacs changes without breaking the world. > Not without including a special "packages-for-beta" directory. That > would in itself be a good thing. Agreed... > > then the package system needs fixing. > > How true. The package system needs dependencies so one can have a > "depends on XEmacs 21.2.26 and up". ...and agreed.

1 participants
0 comments

Re: [PATCH] bookmark.el of edit-utils 1.43 (completing-read usage error) 24 years, 3 months

Vin Shelton

As the maintainer of the stable release series, I'll just say that Hrvoje's value of 'old' is quite different from what I'd expect. The package system should support the dependencies suggested by Jan. - vin >>>>> On 19 Jan 2000, Jan Vroonhof <vroonhof(a)math.ethz.ch> said: Jan> Hrvoje Niksic <hniksic(a)iskon.hr> writes: >> I dislike the idea of our packages avoiding using our new features >> because of compatibility with old XEmacsen that need to be run with >> these very same packages. Jan> Note that "old" here means "the latest released version". The packages Jan> need to target at the latest released, IMO. >> If the package system can't new packages >> requiring new features, Jan> Not without including a special "packages-for-beta" directory. That Jan> would in itself be a good thing. However it would require more Jan> management manpower to do that and we are critically short on that. >> then the package system needs fixing. Jan> How true. The package system needs dependencies so one can have a Jan> "depends on XEmacs 21.2.26 and up".

1 participants
0 comments

Re: XEmacs 21.2.27 is released. 24 years, 3 months

Jan Vroonhof

john s jacobs anderson <jacobs(a)xemacs.org> writes: > I confess to not completely following all the discussion WRT the > package updates; are those to be considered 'stable' and/or should > those releases also be being announced on the web site? They should be announced (they are announced on xemacs-announce). Jan

1 participants
0 comments

Re: edit-utils 1.44 released 24 years, 3 months

Jan Vroonhof

[It is very difficult to resist answering this so I will not] Martin Buchholz <martin(a)xemacs.org> writes: > The current situation with our stable/unstable branches is > problematic. Agreed. This a problem, a big one in fact. > In particular, this is a strong argument in favor of at moving at > least the core packages currently maintained by the XEmacs development > team back into the XEmacs tree, or some other measure to ensure true > stability of future stable releases. I agree with this sentence because of the 'or'. I do not agree with the first half. > For large external packages like JDE, I agree the picture is > different. The problem is where to draw the line. I like the fact that stable users will get the new reftex, auctex, JDE etc... (note that all these packages have in common that they have their own test cycle). However if you move something like 'prog-modes' you get problems. I want people to have the new python-mode.el Maybe the "has its own testcycle" criterion is a good one, but I don't think wholesale moving back into the core is going to magically solve things. This is a hard problem and requires some real thinking [including defining what we actually want from the packages]. Jan

1 participants
0 comments

Re: [PATCH] bookmark.el of edit-utils 1.43 (completing-read usage error) 24 years, 3 months

Hrvoje Niksic

Adrian Aichner <aichner(a)ecf.teradyne.com> writes: > Doing it right (following Kyle's suggestion) would in this > particular case lead to awkward code bloat compared to the version > before Yoshiki's patch. The new feature of `completing-read', the > DEFAULT argument, cannot be relied upon (because XEmacs-21.1.8 does > not have it). Sorry, I don't agree with "cannot be relied upon" part. Backward compatibility is a nice thing, but can't we just have the new version of the package support the new XEmacs? I dislike the idea of our packages avoiding using our new features because of compatibility with old XEmacsen that need to be run with these very same packages. If the package system can't new packages requiring new features, then the package system needs fixing.

2 participants
1 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 January 2000