February 2000 - XEmacs-Beta - XEmacs Mailing List Archives

[PATCH] Recompute glyph metrics when face changes 24 years, 10 months

Kirill 'Big K' Katsnelson

Ever noticed that when there is a glyph with text instance and a face, XEmacs does not recompute the glyph when face changes? When increasing face font size, the text grows and gets clipped by the rectangle which was the glyph instance size at the moment of glyph creation. Reproduction: Copy the following lines after the initial three in *scratch*, and execute the first 3. Then, as you play with font size, glyph size does not change, so there is either a gap or clipping at the right of the glyph. (setq g (make-glyph [string :data "GlYpH!"])) (setq e (make-extent 5 5)) (set-extent-begin-glyph e g) (cons (glyph-width g) (glyph-height g)) (make-face-larger 'default) (make-face-smaller 'default) Unfortunately, it is not quite possible to update more specific glyphs when a face changes. Even if faces tracked glyphs which have this face as their face, it would not be possible to notice glyph change when this face changes through inheritance. So I update a glyph instance in a window when both frame faces marked as changed and glyph instance in the window is text. 2000-01-29 Kirill 'Big K' Katsnelson <kkm(a)dtmx.com> * glyphs.c (image_instance_layout): Mark image instance as clean after layout. (glyph_dirty_p): Removed redundant function. (invalidate_glyph_geometry_maybe): Added. (update_glyph_cachel_data): Call it. * glyphs.h: Prototyped it. * redisplay.c (add_glyph_rune): Call it. (redisplay_window): Reset glyphs cachels when frame faces has changed, thus forcing recomputation of built-in border glyphs. Index: glyphs.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/glyphs.c,v retrieving revision 1.23.2.43 diff -u -r1.23.2.43 glyphs.c --- glyphs.c 2000/01/28 12:41:45 1.23.2.43 +++ glyphs.c 2000/01/30 00:34:27 ＠＠ -1691,8 +1691,42 ＠＠ IIFORMAT_METH (meths, layout, (image_instance, width, height, domain)); } /* else no change to the geometry. */ + + XIMAGE_INSTANCE_DIRTYP (image_instance) = 0; } +/* + * Mark image instance in W as dirty if (a) W's faces have changed and + * (b) GLYPH_OR_II instance in W is a string. + * + * Return non-zero if instance has been marked dirty. + */ +int +invalidate_glyph_geometry_maybe (Lisp_Object glyph_or_ii, struct window* w) +{ + if (XFRAME(WINDOW_FRAME(w))->faces_changed) + { + Lisp_Object image = glyph_or_ii; + + if (GLYPHP (glyph_or_ii)) + { + Lisp_Object window; + XSETWINDOW (window, w); + image = glyph_image_instance (glyph_or_ii, window, ERROR_ME_NOT, 1); + } + + if (TEXT_IMAGE_INSTANCEP (image)) + { + XIMAGE_INSTANCE_DIRTYP (image) = 1; + if (GLYPHP (glyph_or_ii)) + XGLYPH_DIRTYP (glyph_or_ii) = 1; + return 1; + } + } + + return 0; +} + /************************************************************************/ /* error helpers */ ＠＠ -3488,6 +3522,7 ＠＠ Lisp_Object image_instance = specifier_instance (specifier, Qunbound, domain, errb, no_quit, 0, Qzero); + assert (!UNBOUNDP (image_instance)); return image_instance; } ＠＠ -3631,13 +3666,6 ＠＠ return make_int (glyph_height (glyph, window)); } -static unsigned int -glyph_dirty_p (Lisp_Object glyph_or_image, Lisp_Object window) -{ - return XIMAGE_INSTANCE_DIRTYP (glyph_image_instance_maybe - (glyph_or_image, window)); -} - static void set_glyph_dirty_p (Lisp_Object glyph_or_image, Lisp_Object window, int dirty) { ＠＠ -3767,17 +3795,25 ＠＠ struct glyph_cachel *cachel) { if (!cachel->updated || NILP (cachel->glyph) || !EQ (cachel->glyph, glyph) - || XGLYPH_DIRTYP (cachel->glyph)) + || XGLYPH_DIRTYP (cachel->glyph) + || XFRAME(WINDOW_FRAME(w))->faces_changed) { Lisp_Object window, instance; XSETWINDOW (window, w); cachel->glyph = glyph; - /* Speed things up slightly by grabbing the glyph instantiation - and passing it to the size functions. */ + /* Speed things up slightly by grabbing the glyph instantiation + and passing it to the size functions. */ instance = glyph_image_instance (glyph, window, ERROR_ME_NOT, 1); - cachel->dirty = XGLYPH_DIRTYP (glyph) = glyph_dirty_p (glyph, window); + + /* Mark text instance of the glyph dirty if faces have changed, + because its geometry might have changed. */ + invalidate_glyph_geometry_maybe (instance, w); + + /* #### Do the following 2 lines buy us anything? --kkm */ + XGLYPH_DIRTYP (glyph) = XIMAGE_INSTANCE_DIRTYP (instance); + cachel->dirty = XGLYPH_DIRTYP (glyph); cachel->width = glyph_width (instance, window); cachel->ascent = glyph_ascent (instance, window); cachel->descent = glyph_descent (instance, window); Index: glyphs.h =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/glyphs.h,v retrieving revision 1.18.2.28 diff -u -r1.18.2.28 glyphs.h --- glyphs.h 2000/01/25 09:15:43 1.18.2.28 +++ glyphs.h 2000/01/30 00:34:28 ＠＠ -335,6 +335,7 ＠＠ void image_instance_layout (Lisp_Object image_instance, unsigned int width, unsigned int height, Lisp_Object domain); +int invalidate_glyph_geometry_maybe (Lisp_Object glyph_or_ii, struct window* w); DECLARE_DOESNT_RETURN (incompatible_image_types (Lisp_Object instantiator, int given_dest_mask, Index: redisplay.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/redisplay.c,v retrieving revision 1.55.2.36 diff -u -r1.55.2.36 redisplay.c --- redisplay.c 2000/01/26 12:34:04 1.55.2.36 +++ redisplay.c 2000/01/30 00:34:30 ＠＠ -1524,6 +1524,10 ＠＠ { struct window *w = XWINDOW (data->window); + /* If window faces changed, and glyph instance is text, then + glyph sizes might have changed too */ + invalidate_glyph_geometry_maybe (gb->glyph, w); + /* A nil extent indicates a special glyph (ex. truncator). */ if (NILP (gb->extent) || (pos_type == BEGIN_GLYPHS && ＠＠ -5931,7 +5935,7 ＠＠ the cache purely because glyphs have changed - this is now handled by the dirty flag.*/ if ((!echo_active && b != window_display_buffer (w)) - || !Dynarr_length (w->glyph_cachels)) + || !Dynarr_length (w->glyph_cachels) || f->faces_changed) reset_glyph_cachels (w); else mark_glyph_cachels_as_not_updated (w);

3 participants
4 comments

The fate of (memory-limit) 24 years, 10 months

Kirill 'Big K' Katsnelson

Is there any use for this function at all? What is the concept of "last allocated byte", from the lisp point of view? Is the returned value large or small? There is no concept of "total available bytes", for example. (memory-limit) => 33756 33756 peanuts? My xemacs is currently only 8620K private committed. The problem is that I do not know the address of "first allocated byte" :) I propose to delete this function altogether. Big K DEFUN ("memory-limit", Fmemory_limit, 0, 0, "", /* Return the address of the last byte Emacs has allocated, divided by 1024. This may be helpful in debugging Emacs's memory usage. The value is divided by 1024 to make sure it will fit in a lisp integer. */ ()) { return make_int ((EMACS_INT) sbrk (0) / 1024); }

2 participants
1 comments

Re: That gutter again 24 years, 10 months

Jan Vroonhof

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > Because customize reimplements specifier functionality. Then in the > XEmacs version its low-level implementation touches the appropriate > specifier after setting properties on the symbols customize uses. > Customize is totally embarrassed at any explicit mention of specifiers > because customize wants to be cross platform and the FSF doesn't have > specifiers. Note that the idea was for the "customize" variable to be the one that holds the specifier. That was why the :set and :get stuff is there. For some reason there all these blab-bla-p placeholders that shouldn't be there. However I suggest we stop worrying about this until the gutter API is more or less stable. Jan.

5 participants
4 comments

R2L languages, revers-lines and characters > 127 24 years, 10 months

Uwe Brauer

Hi quite a while ago, I asked about the possibility of having TRUE R2L (or BIDI) support for hebrew or any other R2L language with in Mule. However it turned out that, while there will be or is a rewritten display engine for GNU emacs (20.5), to rewrite the display engine for xemacs is far more complicated and will not be done any time soon. Now I have a relatively simple question, which has nothing to do with Mule, the iso-8859-8 is sufficient for my purpose: The basic primitive idea is to write text with iso-885908 characters but L2R. (The idea to have the cursor at the right and putting it to the left visual mode) causes more problem than benefits) However for TeX purpose the text has to be converted. In the following sense: Invert the order of words in a given line and the order of the letter in a given word.: Example Hello word. gives .drow olleH For example the following will do it: (defun ivrit-revers-region (arg) "Does the same as ivrit-revers-buffer but only in marked regions" (interactive "p") (if (or (and (boundp 'zmacs-region-active-p) zmacs-region-active-p) (and (boundp 'transient-mark-mode) transient-mark-mode mark-active)) (save-restriction (save-excursion (narrow-to-region (point) (mark)) ;new finish here1 (goto-char (point-min)) (let ((begl 0)(endl 0)(not-end t)) (while not-end (setq begl (point)) (end-of-line) (setq endl (point)) (if (/= begl endl) (let ((str (buffer-substring begl endl))) (kill-region begl endl) (insert (revers-string str)))) (setq not-end (eq (forward-line 1) 0)))))))) (defun revers-string (str) (interactive) (if (< (length str) 2) str (concat (revers-string (substring str 1)) (substring str 0 1)))) Or another possibility (given to me by Ehud Karni) is (defun invert-line (&optional arg) "Inverse line (right-left) if arg given, inverse arg chars" (interactive "p") (let* ((pos (point)) (eos (progn (if (< arg 2) (end-of-line) (goto-col (1+ arg))) (point))) (str (buffer-substring (progn (beginning-of-line) (point)) eos))) (insert-string (invert-string str)) (delete-char (length str)) (goto-char pos))) (defun invert-all-lines (&optional arg) "Invert (right-left) all the lines in the buffer, if arg given, inverse arg characters in each lines" (interactive "p") (goto-char (point-min)) (let* ((eol 0) (bol 0) (str "")) (while (not (eobp)) (setq bol (point)) (end-of-line) (if arg (goto-col arg) (end-of-line)) (setq eol (point)) (setq str (buffer-substring bol eol)) (delete-region bol eol) (insert-string (invert-string str)) (forward-line 1)))) (defun invert-string (STR) "Invert STRING (right-left) of any length" (invert-sub-string 0 (length STR)) ;invert the whole string STR) Anyhow my question is simple but may be the answer is not so simple. It is possible to modify these functions such that the only applies for strings which have at least 2 characters however all the characters have to be in the octal representation > 127. That would mean that ASCII text remains unchanged but Hebrew text, > 127 will be changed. The function iso-unaccentuate does precisely this, ie changes only characters above 127. I tried to modify the reverse functions mentioned above accordingly, but without success. Does anybody has an idea? Thanks in advance

2 participants
1 comments

vc-hooks bug 24 years, 10 months

Neil.Roeth＠msdw.com

Full_Name: Neil L. Roeth OS: Solaris/SunOS 5.5 Version: 20.4 severity: Serious Submission from: (NULL) (205.228.12.71) Y2K problem in vc-hooks.el I use Tools/Compare/File With Revision... with my currently checked out revision in the current buffer. I choose the defaults, use latest revision and current buffer, and the revision that get checked out is not the latest, it is the last revision in 1999. I isolated the problem to vc-fetch-properties, when it calls vc-parse-buffer. It does not parse the RCS dates correctly; the dates for 1999 have a two digit year (99) and the dates for 2000 have the full four digits. A local elisp expert said the vc code is taking the two date/time strings and doing a lexical compare on them. This bug makes comparing files very confusing, when you think you've changed a few lines, but many show up in the ediff. I have not checked, but I would guess there are other effects, since vc-hooks.el provides general vc functionality, not ediff specific. Thanks. --=-=-=--

1 participants
0 comments

Re: XEmacs <-> comp.emacs.xemacs gateway broken? 24 years, 10 months

Jason R Mastaler

Antonio Freixas <tonyf(a)ims.com> writes: > I used to see a ton of new mail each day in the XEmacs mailing list. > Now, only a few messages show up. I suspect the comp.emacs.xemacs > gateway is broken. > > First of all, is anyone else seeing this same behavior? And secondly, > should I continue to wait patiently for a response from the list > manager address? Patience Antonio. I did get your first message, and the party responsible for the gateway is looking into the problem. I had planned on getting back to you when I had something of substance to report.

1 participants
0 comments

XEmacs <-> comp.emacs.xemacs gateway broken? 24 years, 10 months

Antonio Freixas

This isn't the right place for this e-mail, I know. I sent this question to the XEmacs list manager <list-manager(a)xemacs.org>, but you days ago, but you never know when these things are just black holes. I used to see a ton of new mail each day in the XEmacs mailing list. Now, only a few messages show up. I suspect the comp.emacs.xemacs gateway is broken. First of all, is anyone else seeing this same behavior? And secondly, should I continue to wait patiently for a response from the list manager address? -- Antonio Freixas tonyf(a)ims.com (503) 626-5433

1 participants
0 comments

Re: font-menu-ignore-scaled-fonts in 21.1. and 21.2 24 years, 11 months

Jan Vroonhof

Andreas Jaeger <aj(a)suse.de> writes: > Are you propossing the appended patch for 21.1.9? I'd like to see > this fixed. Yes. It is "obviously correct". It would be nice if somebody who has this problem can confirm it solves it. Otherwise we need to look further. Jan

1 participants
0 comments

Back on the Bus 24 years, 11 months

Vin Shelton

I'm back from my well-deserved vacation and am plowing through my XEmacs email (about 450 unread messages to go). I hope to have a 21.1.9 candidate available for testing by the weekend. In the meantime, has anyone else built with the latest 21.1 CVS version? Please do so, if you can find the time. In particular, I'm interested in Irix testers, now that Martin has applied Max Matveev's patch. - vin

1 participants
0 comments

[PATCH] Use system underline and struke thru fonts 24 years, 11 months

Kirill 'Big K' Katsnelson

I am cleaning up the redisplay code to implement printing in Windows. This patch uses system-provided underline and strike out fonts. Struck out and underlined fonts are now supported on widgets, for no reason, because nobody wants them to look like that anyway! :) The idea is that each font instance has up to four HFONTs associated with it, called variants, for all under/struck combinations. Only one is created initially, with the rest being created and cached in instance data as they are needed, during redisplay. This patch accumulates Windows specific changes, winsys-independent part is under way. An RFC. There are now 2 ways to create an underlined face. One is to specify font modifier 'underline', like "Courier New:Regular:9:underline". The other way is to create a non-underlined font, and set underline-p property of the *face* to t. These faces won't be the same. Even worse, the first face line height will be 1 greater than the second! (Although, with 10pt size, they are same. Thanks Bill!). Should the modifiers 'underline' and 'strikethru' go away from the fonts? Big K 2000-01-17 Kirill 'Big K' Katsnelson <kkm(a)dtmx.com> * faces.h (FACE_STRIKETHRU_P): Added. * glyphs-msw.c (mswindows_widget_hfont): Implemented, to take care of font variants. * redisplay-msw.c (mswindows_apply_face_effects): Deleted. (mswindows_set_dc_font): New function, aware of font variants, separated from mswindows_update_dc. * objects-msw.h (struct mswindows_font_instance_data): Added definition. * objects-msw.c (mswindows_finalize_font_instance): Delete all cached fonts and the data structure. (mswindows_initialize_font_instance): Added creation of font data structure. (mswindows_print_font_instance): Print at least something. (mswindows_create_font_variant): Implemented. (mswindows_get_hfont): Implemented.

6 participants
13 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 February 2000