bug#37774: 27.0.50; new :extend attribute broke visuals of all themes and other packages

classic Classic list List threaded Threaded
149 messages Options
1234 ... 8
Reply | Threaded
Open this post in threaded view
|

bug#37774: 27.0.50; new :extend attribute broke visuals of all themes and other packages

Andrey Orst
From: Andrey Orst <[hidden email]>
To: [hidden email]
Subject: 27.0.50; new :extend attribute broke visuals of all themes and
 other packages
--text follows this line--

Somewhat last checkout from master brought the change of face
attributes, adding new `:extend` attribute, which make all themes, and
packages like Magit display weirdly.  By this I mean that before the
change, some faces were set up to extend highlighting beyond EOL, but
now all of those faces are not doing this.  I've first reported this to
the theme package I'm using:
https://github.com/hlissner/emacs-doom-themes/issues/342 but I think
that this should be handled by emacs itself, because if not it will
result in the duplicated or extra code in themes fro different Emacs
versions.  This reddit post has some screenshots of what I mean:
https://www.reddit.com/r/emacs/comments/diahh1/emacs_27_update_changed_how_highlighted_lines/

In GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.12, cairo version 1.17.3)
 of 2019-10-15 built on v5-572g
Repository revision: 6ac99ebb3f623c64379f5c6811f1cdeb6ecac7da
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12005000
System Description: Arch Linux

Recent messages:
Loading /home/andreyorst/.emacs.d/custom.el (source)...done
Loading /home/andreyorst/.emacs.d/.disabled.el (source)...done
Turning on magit-auto-revert-mode...done
For information about GNU Emacs and the GNU system, type C-h C-a.

Configured using:
 'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
 --localstatedir=/var --mandir=/usr/share/man --with-gameuser=:games
 --with-sound=alsa --with-modules --without-gconf --without-gsettings
 --enable-link-time-optimization --with-x-toolkit=gtk3 --without-xaw3d
 --without-m17n-flt --with-cairo --without-compress-install
 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -flto=jobserver
 -fuse-linker-plugin -fuse-ld=gold' CPPFLAGS=-D_FORTIFY_SOURCE=2
 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'

Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GLIB NOTIFY INOTIFY ACL
GNUTLS LIBXML2 FREETYPE HARFBUZZ LIBOTF ZLIB TOOLKIT_SCROLL_BARS GTK3
X11 XDBE XIM MODULES THREADS LIBSYSTEMD JSON PDUMPER LCMS2 GMP

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Treemacs

Minor modes in effect:
  eldoc-box-hover-at-point-mode: t
  global-tab-line-mode: t
  company-quickhelp-mode: t
  company-quickhelp-local-mode: t
  company-flx-mode: t
  global-company-mode: t
  gcmh-mode: t
  global-undo-tree-mode: t
  undo-tree-mode: t
  ivy-mode: t
  minions-mode: t
  eyebrowse-mode: t
  global-magit-file-mode: t
  magit-auto-revert-mode: t
  global-git-commit-mode: t
  async-bytecomp-package-mode: t
  shell-dirtrack-mode: t
  treemacs-filewatch-mode: t
  treemacs-follow-mode: t
  treemacs-git-mode: deferred
  treemacs-fringe-indicator-mode: t
  hl-line-mode: t
  doom-modeline-mode: t
  solaire-global-mode: t
  override-global-mode: t
  savehist-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  window-divider-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug sendmail counsel xdg swiper vc-git
eldoc-box face-remap tab-line company-files company-capf
company-quickhelp pos-tip company-flx company init vlf-setup gcmh ediff
ediff-merg ediff-mult ediff-wind ediff-diff ediff-help ediff-init
ediff-util undo-tree ivy flx delsel colir color ivy-overlay flymake-proc
flymake compile warnings minions eyebrowse treemacs-magit
magit-submodule magit-obsolete magit-blame magit-stash magit-reflog
magit-bisect magit-push magit-pull magit-fetch magit-clone magit-remote
magit-commit magit-sequence magit-notes magit-worktree magit-tag
magit-merge magit-branch magit-reset magit-files magit-refs magit-status
magit magit-repos magit-apply magit-wip magit-log which-func magit-diff
smerge-mode diff diff-mode magit-core magit-autorevert autorevert
magit-margin magit-transient magit-process magit-mode transient
git-commit magit-git magit-section magit-utils crm log-edit message rmc
puny format-spec rfc822 mml mml-sec epa derived epg epg-config gnus-util
rmail rmail-loaddefs text-property-search time-date mm-decode mm-bodies
mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums
mail-prsvr mailabbrev mail-utils gmm-utils mailheader pcvs-util add-log
with-editor async-bytecomp async shell pcomplete comint ansi-color
server treemacs treemacs-compatibility treemacs-mode treemacs-interface
treemacs-extensions treemacs-persistence treemacs-mouse-interface
treemacs-tag-follow-mode hydra lv treemacs-filewatch-mode treemacs-tags
imenu xref project filenotify treemacs-follow-mode treemacs-rendering
treemacs-async treemacs-faces treemacs-icons treemacs-workspaces
treemacs-dom treemacs-visuals treemacs-fringe-indicator pulse
treemacs-themes treemacs-core-utils pfuture ace-window avy ring hl-line
treemacs-macros pcase inline ht treemacs-customization doom-modeline
doom-modeline-segments doom-modeline-env doom-modeline-core shrink-path
f s dash solaire-mode disp-table doom-themes-ext-org doom-one-theme
doom-themes doom-themes-base all-the-icons all-the-icons-faces
data-material data-weathericons data-octicons data-fileicons
data-faicons data-alltheicons memoize cmake-mode thingatpt rx toml-mode
conf-mode align display-line-numbers doc-view jka-compr image-mode exif
dired dired-loaddefs cl-extra help-mode use-package use-package-ensure
use-package-delight use-package-diminish use-package-bind-key bind-key
easy-mmode use-package-core finder-inf info package easymenu browse-url
url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json subr-x map url-vars seq byte-opt gv
bytecomp byte-compile cconv savehist advice edmacro kmacro cl-loaddefs
cl-lib tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting font-render-setting cairo move-toolbar gtk
x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 382073 282221)
 (symbols 48 27088 10)
 (strings 32 116208 28128)
 (string-bytes 1 3260176)
 (vectors 16 44709)
 (vector-slots 8 729458 136124)
 (floats 8 818 1234)
 (intervals 56 706 639)
 (buffers 1000 13))
Reply | Threaded
Open this post in threaded view
|

bug#37774: 27.0.50; new :extend attribute broke visuals of all themes and other packages

Eli Zaretskii
> From: Andrey Orst <[hidden email]>
> Date: Wed, 16 Oct 2019 10:00:38 +0300
>
> Somewhat last checkout from master brought the change of face
> attributes, adding new `:extend` attribute, which make all themes, and
> packages like Magit display weirdly.  By this I mean that before the
> change, some faces were set up to extend highlighting beyond EOL, but
> now all of those faces are not doing this.  I've first reported this to
> the theme package I'm using:
> https://github.com/hlissner/emacs-doom-themes/issues/342 but I think
> that this should be handled by emacs itself, because if not it will
> result in the duplicated or extra code in themes fro different Emacs
> versions.  This reddit post has some screenshots of what I mean:
> https://www.reddit.com/r/emacs/comments/diahh1/emacs_27_update_changed_how_highlighted_lines/

The screenshots you posted don't clearly explain the problem.  Some of
them seem actually identical before and after the change, and with
others I don't think I see the problem.

So please explain what exactly is incorrect or "weird" in the visual
appearance after the change.  Specifically, why the faces in question
need to be extended past EOL?

Thanks.



Reply | Threaded
Open this post in threaded view
|

bug#37774: 27.0.50; new :extend attribute broke visuals of all themes and other packages

Andrey Orst
these faces are forming visual interface, e.g. hunks in Magit are rectangular regions with background color for entire width of the window that can be folded. Code blocks in org mode are, ahem, blocks. Now those blocks doesn't have anything like block visually.

On Wed, Oct 16, 2019, 10:53 Eli Zaretskii <[hidden email]> wrote:
> From: Andrey Orst <[hidden email]>
> Date: Wed, 16 Oct 2019 10:00:38 +0300
>
> Somewhat last checkout from master brought the change of face
> attributes, adding new `:extend` attribute, which make all themes, and
> packages like Magit display weirdly.  By this I mean that before the
> change, some faces were set up to extend highlighting beyond EOL, but
> now all of those faces are not doing this.  I've first reported this to
> the theme package I'm using:
> https://github.com/hlissner/emacs-doom-themes/issues/342 but I think
> that this should be handled by emacs itself, because if not it will
> result in the duplicated or extra code in themes fro different Emacs
> versions.  This reddit post has some screenshots of what I mean:
> https://www.reddit.com/r/emacs/comments/diahh1/emacs_27_update_changed_how_highlighted_lines/

The screenshots you posted don't clearly explain the problem.  Some of
them seem actually identical before and after the change, and with
others I don't think I see the problem.

So please explain what exactly is incorrect or "weird" in the visual
appearance after the change.  Specifically, why the faces in question
need to be extended past EOL?

Thanks.
Reply | Threaded
Open this post in threaded view
|

bug#37774: 27.0.50; new :extend attribute broke visuals of all themes and other packages

Michael Heerdegen
In reply to this post by Eli Zaretskii
Eli Zaretskii <[hidden email]> writes:

> So please explain what exactly is incorrect or "weird" in the visual
> appearance after the change.  Specifically, why the faces in question
> need to be extended past EOL?

At least with Helm, Magit and Ediff higlighting often looks very
unfamiliar.  I guess very often the original purpose had been to
highlight full visible lines.  Was it intentional to change all of that,
or only a side effect?


Michael.



Reply | Threaded
Open this post in threaded view
|

bug#37774: 27.0.50; new :extend attribute broke visuals of all themes and other packages

martin rudalics
 > At least with Helm, Magit and Ediff higlighting often looks very
 > unfamiliar.  I guess very often the original purpose had been to
 > highlight full visible lines.  Was it intentional to change all of that,
 > or only a side effect?

A side-effect.

martin



Reply | Threaded
Open this post in threaded view
|

bug#37774: 27.0.50; new :extend attribute broke visuals of all themes and other packages

Eli Zaretskii
In reply to this post by Andrey Orst
> From: Andrey Orst <[hidden email]>
> Date: Wed, 16 Oct 2019 11:12:44 +0300
> Cc: [hidden email], Ergus <[hidden email]>
>
> these faces are forming visual interface, e.g. hunks in Magit are rectangular regions with background color for
> entire width of the window that can be folded. Code blocks in org mode are, ahem, blocks. Now those blocks
> doesn't have anything like block visually.

So you are saying that you don't like the new appearance?  The Subject
says "broke visuals", which sounds like a much more serious problem.



Reply | Threaded
Open this post in threaded view
|

bug#37774: 27.0.50; new :extend attribute broke visuals of all themes and other packages

Emacs - Bugs mailing list
In reply to this post by Eli Zaretskii
Hi Eli and Martin:

I have seen these reports and also the ones in reddit. Do you think that
we should/must/can do anything about?



On Wed, Oct 16, 2019 at 10:53:21AM +0300, Eli Zaretskii wrote:

>> From: Andrey Orst <[hidden email]>
>> Date: Wed, 16 Oct 2019 10:00:38 +0300
>>
>> Somewhat last checkout from master brought the change of face
>> attributes, adding new `:extend` attribute, which make all themes, and
>> packages like Magit display weirdly.  By this I mean that before the
>> change, some faces were set up to extend highlighting beyond EOL, but
>> now all of those faces are not doing this.  I've first reported this to
>> the theme package I'm using:
>> https://github.com/hlissner/emacs-doom-themes/issues/342 but I think
>> that this should be handled by emacs itself, because if not it will
>> result in the duplicated or extra code in themes fro different Emacs
>> versions.  This reddit post has some screenshots of what I mean:
>> https://www.reddit.com/r/emacs/comments/diahh1/emacs_27_update_changed_how_highlighted_lines/
>
>The screenshots you posted don't clearly explain the problem.  Some of
>them seem actually identical before and after the change, and with
>others I don't think I see the problem.
>
>So please explain what exactly is incorrect or "weird" in the visual
>appearance after the change.  Specifically, why the faces in question
>need to be extended past EOL?
>
>Thanks.



Reply | Threaded
Open this post in threaded view
|

bug#37774: 27.0.50; new :extend attribute broke visuals of all themes and other packages

Andrey Orst
> So you are saying that you don't like the new appearance?  The Subject
> says "broke visuals", which sounds like a much more serious problem.

Well, "broke" may be wrong term, here, but lot of themes and packages crafted
in a way to display things like that, and now all of those things displayed accordingly
to a new setting, which in turn means that:

a) package maintainers should update *all* their packages to look like before the change, and
b) maybe Emacs could treat `nil` here as "do not affect", and specify symbols to set this to different
   settings, like `:extend t` or `:extend 'EOL`, and `:extend 'noextend` to disable. Though, I do not
   know how code was changed, so maybe there's no way to treat `nil` as "do not affect".

On Wed, Oct 16, 2019 at 2:10 PM Ergus <[hidden email]> wrote:
Hi Eli and Martin:

I have seen these reports and also the ones in reddit. Do you think that
we should/must/can do anything about?



On Wed, Oct 16, 2019 at 10:53:21AM +0300, Eli Zaretskii wrote:
>> From: Andrey Orst <[hidden email]>
>> Date: Wed, 16 Oct 2019 10:00:38 +0300
>>
>> Somewhat last checkout from master brought the change of face
>> attributes, adding new `:extend` attribute, which make all themes, and
>> packages like Magit display weirdly.  By this I mean that before the
>> change, some faces were set up to extend highlighting beyond EOL, but
>> now all of those faces are not doing this.  I've first reported this to
>> the theme package I'm using:
>> https://github.com/hlissner/emacs-doom-themes/issues/342 but I think
>> that this should be handled by emacs itself, because if not it will
>> result in the duplicated or extra code in themes fro different Emacs
>> versions.  This reddit post has some screenshots of what I mean:
>> https://www.reddit.com/r/emacs/comments/diahh1/emacs_27_update_changed_how_highlighted_lines/
>
>The screenshots you posted don't clearly explain the problem.  Some of
>them seem actually identical before and after the change, and with
>others I don't think I see the problem.
>
>So please explain what exactly is incorrect or "weird" in the visual
>appearance after the change.  Specifically, why the faces in question
>need to be extended past EOL?
>
>Thanks.


--
Best regards,
Andrey Listopadov
Reply | Threaded
Open this post in threaded view
|

bug#37774: 27.0.50; new :extend attribute broke visuals of all themes and other packages

Eli Zaretskii
In reply to this post by Michael Heerdegen
> From: Michael Heerdegen <[hidden email]>
> Cc: Andrey Orst <[hidden email]>,  Ergus <[hidden email]>,
>   [hidden email]
> Date: Wed, 16 Oct 2019 10:59:51 +0200
>
> At least with Helm, Magit and Ediff higlighting often looks very
> unfamiliar.  I guess very often the original purpose had been to
> highlight full visible lines.  Was it intentional to change all of that,
> or only a side effect?

It was intentional, meaning the assumption was that extending the face
past the last character on the line makes little sense in general.
IOW, preventing the extension for most faces was the main point of the
change.



Reply | Threaded
Open this post in threaded view
|

bug#37774: 27.0.50; new :extend attribute broke visuals of all themes and other packages

Andrey Orst
In reply to this post by Andrey Orst
Sorry anyone if I disturbed your personal email addresses, I didn't understand
how to reply there and thought that cc to [hidden email] would do
the trick. I see that my messages don't appear at the bug report page, so I'll
send those back as a single e-mail. Still don't understand where I should properly
reply.

> So please explain what exactly is incorrect or "weird" in the visual
> appearance after the change.  Specifically, why the faces in question
> need to be extended past EOL?

These faces are forming visual interface, e.g. hunks in Magit are rectangular
regions with background color for entire width of the window that can be folded.
Code blocks in org mode are, ahem, blocks. Now those blocks doesn't have
anything like block visually.

> So you are saying that you don't like the new appearance?  The Subject
> says "broke visuals", which sounds like a much more serious problem.

Well, "broke" may be wrong term, here, but lot of themes and packages crafted
in a way to display things like that, and now all of those things displayed accordingly
to a new setting, which in turn means that:

a) package maintainers should update *all* their packages to look like before the change, and
b) maybe Emacs could treat `nil` here as "do not affect", and specify symbols to set this to different
   settings, like `:extend t` or `:extend 'EOL`, and `:extend 'noextend` to disable. Though, I do not
   know how code was changed, so maybe there's no way to treat `nil` as "do not affect".

--
Best regards,
Andrey Orst
Reply | Threaded
Open this post in threaded view
|

bug#37774: 27.0.50; new :extend attribute broke visuals of all themes and other packages

Michael Heerdegen
In reply to this post by Eli Zaretskii
Eli Zaretskii <[hidden email]> writes:

> It was intentional, meaning the assumption was that extending the face
> past the last character on the line makes little sense in general.
> IOW, preventing the extension for most faces was the main point of the
> change.

Ok.  But it obviously created a lot of fallout to fix.

Michael.



Reply | Threaded
Open this post in threaded view
|

bug#37774: 27.0.50; new :extend attribute broke visuals of all themes and other packages

Eli Zaretskii
In reply to this post by Andrey Orst
> From: Andrey Orst <[hidden email]>
> Date: Wed, 16 Oct 2019 14:17:27 +0300
> Cc: Eli Zaretskii <[hidden email]>, [hidden email]
>
> > So you are saying that you don't like the new appearance?  The Subject
> > says "broke visuals", which sounds like a much more serious problem.
>
> Well, "broke" may be wrong term, here, but lot of themes and packages crafted
> in a way to display things like that, and now all of those things displayed accordingly
> to a new setting, which in turn means that:
>
> a) package maintainers should update *all* their packages to look like before the change, and

Are you saying that _all_ the faces will have to be modified to make
them extended?  IOW, are you saying that this feature is wrong with
most or all of the faces?

The assumption behind this feature was that the absolute majority of
faces don't need to be extended.  If you say this is wrong, can you
show enough examples to back up that?

> b) maybe Emacs could treat `nil` here as "do not affect", and specify symbols to set this to different
>    settings, like `:extend t` or `:extend 'EOL`, and `:extend 'noextend` to disable. Though, I do not
>    know how code was changed, so maybe there's no way to treat `nil` as "do not affect".

Let's first find out how many faces would need to be modified to adapt
to this feature, and only after that discuss the details of the
solution(s).



Reply | Threaded
Open this post in threaded view
|

bug#37774: 27.0.50; new :extend attribute broke visuals of all themes and other packages

Eli Zaretskii
In reply to this post by Emacs - Bugs mailing list
> Date: Wed, 16 Oct 2019 13:10:04 +0200
> From: Ergus <[hidden email]>
> Cc: Andrey Orst <[hidden email]>, [hidden email]
>
> I have seen these reports and also the ones in reddit. Do you think that
> we should/must/can do anything about?

Maybe, I'm not yet sure I understand the magnitude of the problem.
Let's see where this discussion leads us.



Reply | Threaded
Open this post in threaded view
|

bug#37774: 27.0.50; new :extend attribute broke visuals of all themes and other packages

Andrey Orst
In reply to this post by Eli Zaretskii
> Are you saying that _all_ the faces will have to be modified to make
> them extended?  IOW, are you saying that this feature is wrong with
> most or all of the faces?

I don't know about /all/ faces, but I have experienced a lot of visual changes
when using `doom-one' theme provided by `doom-themes' package paired
with at least these packages: magit, ediff, solaire-mode, org-mode.

> The assumption behind this feature was that the absolute majority of
> faces don't need to be extended.  If you say this is wrong, can you
> show enough examples to back up that?

I understand this, and maybe package maintainers should adopt the change
but since Emacs doesn't ignore unknown attributes, this may result in a lot of
extra code in order to support both pre-27 Emacs, and 27+ Emacs to make
different versions look consistently.

On Wed, Oct 16, 2019 at 2:41 PM Eli Zaretskii <[hidden email]> wrote:
> From: Andrey Orst <[hidden email]>
> Date: Wed, 16 Oct 2019 14:17:27 +0300
> Cc: Eli Zaretskii <[hidden email]>, [hidden email]
>
> > So you are saying that you don't like the new appearance?  The Subject
> > says "broke visuals", which sounds like a much more serious problem.
>
> Well, "broke" may be wrong term, here, but lot of themes and packages crafted
> in a way to display things like that, and now all of those things displayed accordingly
> to a new setting, which in turn means that:
>
> a) package maintainers should update *all* their packages to look like before the change, and

Are you saying that _all_ the faces will have to be modified to make
them extended?  IOW, are you saying that this feature is wrong with
most or all of the faces?

The assumption behind this feature was that the absolute majority of
faces don't need to be extended.  If you say this is wrong, can you
show enough examples to back up that?

> b) maybe Emacs could treat `nil` here as "do not affect", and specify symbols to set this to different
>    settings, like `:extend t` or `:extend 'EOL`, and `:extend 'noextend` to disable. Though, I do not
>    know how code was changed, so maybe there's no way to treat `nil` as "do not affect".

Let's first find out how many faces would need to be modified to adapt
to this feature, and only after that discuss the details of the
solution(s).


--
Best regards,
Andrey Orst
Reply | Threaded
Open this post in threaded view
|

bug#37774: 27.0.50; new :extend attribute broke visuals of all themes and other packages

Eli Zaretskii
In reply to this post by Michael Heerdegen
> From: Michael Heerdegen <[hidden email]>
> Cc: [hidden email],  [hidden email],  [hidden email]
> Date: Wed, 16 Oct 2019 13:38:43 +0200
>
> Eli Zaretskii <[hidden email]> writes:
>
> > It was intentional, meaning the assumption was that extending the face
> > past the last character on the line makes little sense in general.
> > IOW, preventing the extension for most faces was the main point of the
> > change.
>
> Ok.  But it obviously created a lot of fallout to fix.

Not clear yet, at least not to me.  But it's possible.



Reply | Threaded
Open this post in threaded view
|

bug#37774: 27.0.50; new :extend attribute broke visuals of all themes and other packages

Eli Zaretskii
In reply to this post by Andrey Orst
> From: Andrey Orst <[hidden email]>
> Date: Wed, 16 Oct 2019 15:08:53 +0300
> Cc: [hidden email]
>
> > The assumption behind this feature was that the absolute majority of
> > faces don't need to be extended.  If you say this is wrong, can you
> > show enough examples to back up that?
>
> I understand this, and maybe package maintainers should adopt the change

The assumption was that they won't need to adapt, because users will
want most faces should not to be extended.  If indeed many faces need
adaptation, then I do see a problem of backward compatibility; but
that wasn't the assumption.



Reply | Threaded
Open this post in threaded view
|

bug#37774: 27.0.50; new :extend attribute broke visuals of all themes and other packages

Emacs - Bugs mailing list
In reply to this post by Eli Zaretskii
Yes, internally it won't produce any issue (I am using it since I
implemented it the first time), but some external packages will need to
update some of their faces...; and others could remove some of the hacks
they implemented to emulate the functionality this change provides.

Do we have something in defface that we can "recommend" to conditionally
specify this attribute when version >= 27 only (maybe a syntax sugar)?

In any case maybe we need to add a recommendation in NEWS about how to
update.

On Wed, Oct 16, 2019 at 02:42:09PM +0300, Eli Zaretskii wrote:
>> Date: Wed, 16 Oct 2019 13:10:04 +0200
>> From: Ergus <[hidden email]>
>> Cc: Andrey Orst <[hidden email]>, [hidden email]
>>
>> I have seen these reports and also the ones in reddit. Do you think that
>> we should/must/can do anything about?
>
>Maybe, I'm not yet sure I understand the magnitude of the problem.
>Let's see where this discussion leads us.



Reply | Threaded
Open this post in threaded view
|

bug#37774: 27.0.50; new :extend attribute broke visuals of all themes and other packages

Andrey Orst
> In any case maybe we need to add a recommendation in NEWS about how to
> update.

This would be nice to have, because some old packages may not receive updates
and users would have to deal with it.

On Wed, Oct 16, 2019 at 4:18 PM Ergus <[hidden email]> wrote:

>
> Yes, internally it won't produce any issue (I am using it since I
> implemented it the first time), but some external packages will need to
> update some of their faces...; and others could remove some of the hacks
> they implemented to emulate the functionality this change provides.
>
> Do we have something in defface that we can "recommend" to conditionally
> specify this attribute when version >= 27 only (maybe a syntax sugar)?
>
> In any case maybe we need to add a recommendation in NEWS about how to
> update.
>
> On Wed, Oct 16, 2019 at 02:42:09PM +0300, Eli Zaretskii wrote:
> >> Date: Wed, 16 Oct 2019 13:10:04 +0200
> >> From: Ergus <[hidden email]>
> >> Cc: Andrey Orst <[hidden email]>, [hidden email]
> >>
> >> I have seen these reports and also the ones in reddit. Do you think that
> >> we should/must/can do anything about?
> >
> >Maybe, I'm not yet sure I understand the magnitude of the problem.
> >Let's see where this discussion leads us.



--
Best regards,
Andrey Orst
Reply | Threaded
Open this post in threaded view
|

bug#37774: 27.0.50; new :extend attribute broke visuals of all themes and other packages

Stefan Kangas
In reply to this post by Eli Zaretskii
Eli Zaretskii <[hidden email]> writes:

> So you are saying that you don't like the new appearance?  The Subject
> says "broke visuals", which sounds like a much more serious problem.

It's not a question of aesthetics, but of usability.  For example, the
third party magit gets harder to use if the faces aren't adapted to
use the new extend property.

I don't know if there is any benefit to the new behaviour.  Is it just
stylistic?

Best regards,
Stefan Kangas



Reply | Threaded
Open this post in threaded view
|

bug#37774: 27.0.50; new :extend attribute broke visuals of all themes and other packages

Emacs - Bugs mailing list
In reply to this post by Andrey Orst
On Wed, Oct 16, 2019 at 04:33:08PM +0300, Andrey Orst wrote:
>> In any case maybe we need to add a recommendation in NEWS about how to
>> update.
>
>This would be nice to have, because some old packages may not receive
>updates
>and users would have to deal with it.
>

In any case I have been looking around and this is not really critical
cause only few active/extended packages will be directly affected for
this now. If there are some inactive-old-unmaintained package you know
will be affected and it is probably unmaintained, then probably we can
contact the author, make a pull request or in the best case, recommend
other with same functionality, but more active-maintained-supported.

Magit counsel-swiper and Helm, for example, I am pretty sure they will
receive the update immediately once we publish the recommended way to do
so without breaking backward compatibility.



>On Wed, Oct 16, 2019 at 4:18 PM Ergus <[hidden email]> wrote:
>>
>> Yes, internally it won't produce any issue (I am using it since I
>> implemented it the first time), but some external packages will need to
>> update some of their faces...; and others could remove some of the hacks
>> they implemented to emulate the functionality this change provides.
>>
>> Do we have something in defface that we can "recommend" to conditionally
>> specify this attribute when version >= 27 only (maybe a syntax sugar)?
>>
>> In any case maybe we need to add a recommendation in NEWS about how to
>> update.
>>
>> On Wed, Oct 16, 2019 at 02:42:09PM +0300, Eli Zaretskii wrote:
>> >> Date: Wed, 16 Oct 2019 13:10:04 +0200
>> >> From: Ergus <[hidden email]>
>> >> Cc: Andrey Orst <[hidden email]>, [hidden email]
>> >>
>> >> I have seen these reports and also the ones in reddit. Do you think
>that
>> >> we should/must/can do anything about?
>> >
>> >Maybe, I'm not yet sure I understand the magnitude of the problem.
>> >Let's see where this discussion leads us.
>
>
>
>--
>Best regards,
>Andrey Orst



1234 ... 8