Using 14pt font for minibuffer causes visual glitch in blink-matching-paren

[gracjan]

A closing paren in emacs tries to show information about matching opening paren. In Aquamacs this causes screen redraw that shows matching paren for a very short time and then does not really go back to old position but somewhere around it.

This is visually annoying. (See note below).

Unwanted effect happens only when inserting a ')' (with a matching '(' off-screen)). So far I know that:

• happens both when (show-paren-mode t) and (show-paren-mode nil)
• does not happen when (blink-matching-paren nil) does happen when (blink-matching-paren t)
• happens when (blink-matching-paren-on-screen nil) and (blink-matching-paren-on-screen t)
• happens only in post-insert-hook, when (blink-matching-open) called interactively then no visual glitch happens
• happens with (blink-matching-paren-distance nil) and (blink-matching-paren-distance some-value) provided that matching paren is found
• does not happen if matching opening paren is not found

Note: blink-matching-paren is supposed to go to matching paren position if it is on-screen and sit there for blink-matching-delay. It does not do this: cursor is not moved when on-screen, sit-for is ignored. Probably some other bug.

post-self-insert-hook has value (blink-paren-post-self-insert-function)

Note: http://emacsformacosx.com does not exhibit this beavior.

I'd love to debug this further. Any ideas how do I proceed?

[gracjan]

More info:

Does still happen even if .emacs file is removed
Does not happen if Aquamacs is stared using open /Applications/Aquamacs.app --args -no-init-file

[gracjan]

Issue is somewhere in this customization:

 '(default-frame-alist
    (quote
   ((cursor-type . box)
  (vertical-scroll-bars . right)
  (internal-border-width . 0)
  (modeline . t)
  (fringe)
  (mouse-color . "black")
  (background-mode . light)
  (tool-bar-lines . 1)
  (menu-bar-lines . 1)
  (right-fringe . 8)
  (left-fringe . 1)
  (cursor-color . "Red")
  (background-color . "White")
  (foreground-color . "Black")
  (font . "-apple-Consolas-medium-normal-normal-*-16-*-*-*-m-0-iso10646-1")
  (fontsize . 0)
  (font-backend ns))))

After removing this part annoyance stopped. although I lost my Consolas setting.

[gracjan]

Then... after clicking "Options | Appearance | Adopt Face and Frame Parameters as Default" a section like the one mentioned above appeared again in my customizations.el file and visual annoyance returned.

[gracjan]

Narrowed down. This line causes this specific issue:

  (font . "-*-Consolas-normal-normal-normal-*-14-*-*-*-m-0-iso10646-1")

Removing it and leaving everything else intact solves the problem.

Why font setting should cause screen repaints when under (save-excursion ...)? Isn't (save-excursion) supposed to prevent any such repaints?

[gracjan]

Workaround:

(custom-set-faces
  '(echo-area ((t (:inherit aquamacs-variable-width)))))

This forces minibuffer to use 12pt font. If minibuffer uses any other font size it will cause unnecessary repaints.

[gracjan]

Interestingly enough mode-line face height does not cause any problems (I've set it to 20pt and no issues).

[gracjan]

Nightly build Aquamacs-2014-May-31-Sat-0108.tar.bz2 still suffers mentioned problem.

[davidswelt]

No. Read the documentation to `save-excursion’. It saves "point, mark, and current buffer”.

On May 31, 2014, at 2:59 AM, gracjan notifications@github.com wrote:

Narrowed down. This line causes this specific issue:

(font . "--Consolas-normal-normal-normal--14---*-m-0-iso10646-1")

Removing it and leaving everything else intact solves the problem.

Why font setting should cause screen repaints when under (save-excursion ...)? Isn't (save-excursion) supposed to prevent any such repaints?

—
Reply to this email directly or view it on GitHub.

[davidswelt]

With this setting, I can see some visual disturbance (echo area temporarily smaller in height by 1 or 2 pixels) when displaying error message “End of buffer” after scrolling down/up with the mouse.

I have not been able to reproduce your original bug. Can you clarify what “ does not really go back to old position but somewhere around it” means? Is it the window scrolling, or does point (text cursor) no go back to where the paren was inserted?

On May 31, 2014, at 4:28 AM, gracjan notifications@github.com wrote:

Nightly build Aquamacs-2014-May-31-Sat-0108.tar.bz2 still suffers mentioned problem.

—
Reply to this email directly or view it on GitHub.

[gracjan]

Athough cursor goes back where it should be, the buffer position does not.

For a split second it shows starting paren, then it cursor goes back, but scroll position does not get back to exact position.

I can see if I'll be able to make a screencast. Such strange effects are hard to explain :)

[davidswelt]

I think you mean window position (in Emacs language), but I understand what is happening.

In order to debug this, it would be good if you could reproduce the problem in plain Emacs.
It is likely to be a matter of font settings.

Aquamacs does provide a specific face for the echo area, and that may make it hard or impossible to reproduce in Emacs.

The source of the problem may be the echo area animation (is there one?).

[gracjan]

Attached screencast about the bug.

2014-06-03 17:25 GMT+02:00 David Reitter notifications@github.com:

I think you mean window position (in Emacs language), but I understand
what is happening.

In order to debug this, it would be good if you could reproduce the
problem in plain Emacs.
It is likely to be a matter of font settings.

Aquamacs does provide a specific face for the echo area, and that may make
it hard or impossible to reproduce in Emacs.

The source of the problem may be the echo area animation (is there one?).

—
Reply to this email directly or view it on GitHub
#97 (comment)
.

[davidswelt]

Any news on reproducing this bug in GNU Emacs?

[treese]

I tried using 14-point Consolas in the minibuffer with Aquamacs 3.5, and I did not see any visual glitches. If you still see the problem with 3.5, please reopen this issue.