* Re: bug#129: Mouse highlighting fails for font sizes. [not found] <87lk3lh1de.fsf@stupidchicken.com> @ 2008-04-11 1:51 ` Chong Yidong 2008-04-11 2:28 ` Stefan Monnier 2008-04-11 4:05 ` Kenichi Handa 0 siblings, 2 replies; 4+ messages in thread From: Chong Yidong @ 2008-04-11 1:51 UTC (permalink / raw) To: emacs-devel; +Cc: 129 Chong Yidong <cyd@stupidchicken.com> writes: > At some point, the Unicode-2 branch redisplay was changed to allow > mouse-highlighted text to have a different font size from the > unhighlighted characters. Unfortunately, this doesn't mesh well with > the existing code in note_mouse_highlight, which assumes the highlighted > glyphs overlap exactly with unhighlighted glyphs. > > (defface foo-face > '((t :height 1.5)) > "Face") > > (defface bar-face > '((t :height 1.0)) > "Face") > > (defun foo-test () > (interactive) > (switch-to-buffer "*Test*") > (erase-buffer) > (insert "Copying Conditions") > (put-text-property (point-min) (point-max) 'face 'foo-face) > (put-text-property (point-min) (point-max) 'mouse-face '(bar-face highlight))) After thinking some more, I think it's problematic to let mouse-highlighted text differ in size from the unhighlighted characters. Even if we fix the redisplay engine to correctly update the glyph row in such situations, there's the problem of how to decide when to perform highlighting. Consider a buffer containing the letters "A B" in a big font, which I schematically depict as -A- -B- Suppose the letter A has a mouse highlight face that contains a small font. So if we put the cursor over it, in the position marked ^, we see A -B- ^ Now, move the cursor slightly to the right, so that it moves off the highlighted A: A -B- ^ The highlighting disappears, and we see -A- -B- ^ But the mouse is now again on the letter A, which means we need to highlight! Is the benefit of allowing a different-sized mouse-face significant? If not, I propose imposing (or restoring) the restricting that only the foreground-color and background-color of the mouse-face takes effect; all other properties are ignored, and taken from the underlying face. What do you think? ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: bug#129: Mouse highlighting fails for font sizes. 2008-04-11 1:51 ` bug#129: Mouse highlighting fails for font sizes Chong Yidong @ 2008-04-11 2:28 ` Stefan Monnier 2008-04-11 2:59 ` Chong Yidong 2008-04-11 4:05 ` Kenichi Handa 1 sibling, 1 reply; 4+ messages in thread From: Stefan Monnier @ 2008-04-11 2:28 UTC (permalink / raw) To: Chong Yidong; +Cc: 129, emacs-devel >> At some point, the Unicode-2 branch redisplay was changed to allow >> mouse-highlighted text to have a different font size from the >> unhighlighted characters. Unfortunately, this doesn't mesh well with >> the existing code in note_mouse_highlight, which assumes the highlighted >> glyphs overlap exactly with unhighlighted glyphs. >> >> (defface foo-face >> '((t :height 1.5)) >> "Face") >> >> (defface bar-face >> '((t :height 1.0)) >> "Face") >> >> (defun foo-test () >> (interactive) >> (switch-to-buffer "*Test*") >> (erase-buffer) >> (insert "Copying Conditions") >> (put-text-property (point-min) (point-max) 'face 'foo-face) >> (put-text-property (point-min) (point-max) 'mouse-face '(bar-face highlight))) > After thinking some more, I think it's problematic to let > mouse-highlighted text differ in size from the unhighlighted characters. > Even if we fix the redisplay engine to correctly update the glyph row in > such situations, there's the problem of how to decide when to perform > highlighting. > Consider a buffer containing the letters "A B" in a big font, which I > schematically depict as > -A- -B- > Suppose the letter A has a mouse highlight face that contains a small > font. So if we put the cursor over it, in the position marked ^, we see > A -B- > ^ > Now, move the cursor slightly to the right, so that it moves off the > highlighted A: > A -B- > ^ > The highlighting disappears, and we see > -A- -B- > ^ > But the mouse is now again on the letter A, which means we need to > highlight! > Is the benefit of allowing a different-sized mouse-face significant? If > not, I propose imposing (or restoring) the restricting that only the > foreground-color and background-color of the mouse-face takes effect; > all other properties are ignored, and taken from the underlying face. > What do you think? I think resizing on mouse-movement is a bad idea indeed (for the meta-stable problem you mention above, for other technical reasons, as well as for purely aesthetic reasons). But restricting "same size properties" for mouse-face is problematic as well: we may want to use boldness for highlighting but it's not guaranteed to preserve the size. It's more restrictive than necessary. So the best idea I can come up with is: don't restrict the face, but when highlighting, don't change the size of the box in which the text is drawn. This works perfectly for changes that preserve the size, it works fine for changes that reduce the size (the reduced-size text is just surrounded with more whitespace than necessary, but the user won't be surprised). It doesn't work well if the size is increased (you get clipping), but there's not much we can do in that case anyway, so it's probably OK. Of course, I have no idea how easy it'd be to implement that. So maybe in the short term it's best to simply rule out size-changes. Another problem with the mouse-highlighting is the flickering we get whenever we redisplay: because the mouse-highlighting is done outside of the main redisplay, it needs to be undone before redisplay and re-applied afterwards. This is problematic when you have a timer changing the display every second. Stefan ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: bug#129: Mouse highlighting fails for font sizes. 2008-04-11 2:28 ` Stefan Monnier @ 2008-04-11 2:59 ` Chong Yidong 0 siblings, 0 replies; 4+ messages in thread From: Chong Yidong @ 2008-04-11 2:59 UTC (permalink / raw) To: Stefan Monnier; +Cc: 129, emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: > I think resizing on mouse-movement is a bad idea indeed (for the > meta-stable problem you mention above, for other technical reasons, as > well as for purely aesthetic reasons). > But restricting "same size properties" for mouse-face is problematic as > well: we may want to use boldness for highlighting but it's not > guaranteed to preserve the size. It's more restrictive than necessary. > > So the best idea I can come up with is: don't restrict the face, but > when highlighting, don't change the size of the box in which the text > is drawn. This works perfectly for changes that preserve the size, it > works fine for changes that reduce the size (the reduced-size text is > just surrounded with more whitespace than necessary, but the user won't > be surprised). It doesn't work well if the size is increased (you get > clipping), but there's not much we can do in that case anyway, so it's > probably OK. This might be doable by fixing the glyph size to its original (unhighlighted) value. I don't know if that violates assumptions made in the redisplay code, which might be difficult to work out. The trouble is that the result might end up looking hideous, and there's no guarantee that it won't; that would be font-dependent. While restricting mouse-highlight to coloring is a little less flexible, we know the result will look OK. I think a size restriction is regrettable but unimportant. Since mouse highlighting takes place on graphical displays, colors can do the job of "lighting up" the text, which is what mouse-face is for. > Another problem with the mouse-highlighting is the flickering we get > whenever we redisplay: because the mouse-highlighting is done outside of > the main redisplay, it needs to be undone before redisplay and > re-applied afterwards. This is problematic when you have a timer > changing the display every second. I've noticed flickering of this sort with the new font backend: M-x info moving the mouse through the info links causes the text to flicker. It doesn't happen when a non-fontconfig font is used, so maybe the new code is doing something silly. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: bug#129: Mouse highlighting fails for font sizes. 2008-04-11 1:51 ` bug#129: Mouse highlighting fails for font sizes Chong Yidong 2008-04-11 2:28 ` Stefan Monnier @ 2008-04-11 4:05 ` Kenichi Handa 1 sibling, 0 replies; 4+ messages in thread From: Kenichi Handa @ 2008-04-11 4:05 UTC (permalink / raw) To: Chong Yidong; +Cc: 129, emacs-devel In article <871w5dw445.fsf@stupidchicken.com>, Chong Yidong <cyd@stupidchicken.com> writes: > Chong Yidong <cyd@stupidchicken.com> writes: > > At some point, the Unicode-2 branch redisplay was changed to allow > > mouse-highlighted text to have a different font size from the > > unhighlighted characters. That is just a bug, and I've already fixed it in my working version. --- Kenichi Handa handa@ni.aist.go.jp ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2008-04-11 4:05 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <87lk3lh1de.fsf@stupidchicken.com> 2008-04-11 1:51 ` bug#129: Mouse highlighting fails for font sizes Chong Yidong 2008-04-11 2:28 ` Stefan Monnier 2008-04-11 2:59 ` Chong Yidong 2008-04-11 4:05 ` Kenichi Handa
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.