GNU bug report logs - #47868
28.0.50; [native-comp] vertico package doesn't work when loading the corresponding eln file

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 47868 in the body.
You can then email your comments to 47868 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Tassilo Horn <tsdh <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org, Daniel Mendler <mail <at> daniel-mendler.de>
Subject: 28.0.50; [native-comp] vertico package doesn't work when loading
 the corresponding eln file
Date: Sun, 18 Apr 2021 13:16:29 +0200

[Message part 1 (text/plain, inline)]

The GNU ELPA package vertico shows possible completion candidates in an
overlay during minibuffer completion.  I've just noticed that this
doesn't work properly when the generated eln file is loaded rather than
the el or elc file.

By "not working properly" I mean that frequently either the minibuffer
prompt is displayed or the overlay showing the candidates but not both.
Sometimes also both, but then the cursor is blinking at the end of the
candidates overlay rather than immediately behind the input.  Also the
candidate count overlay seems to be only shown if the prompt is also
there but not the canditates overlay.  Here's a screenshot:

[Screenshot-2021-04-18_131534.png (image/png, attachment)]

[Message part 3 (text/plain, inline)]

Here's a reproduction recipe:

  0. Build the current native-comp branch, HEAD is
     af0af63742fd2383dae5627d0ce8167517fd4700 right now.
     Install the vertico GNU ELPA package and wait for its async
     native compilation to be finished.
  1. emacs -Q
  2. Load the ELN file (which is the only one I have, so I'm sure it's
     the right one for my current emacs):
     M-x load-file RET
     ~/.emacs.d/eln-cache/28.0.50-bc702aed/vertico-6eb6690f-90eaf131.eln
     RET
  3. M-x vertico-mode RET
  4. Try C-x C-b or C-x C-f to see the problem.


In GNU Emacs 28.0.50 (build 47, x86_64-pc-linux-gnu, GTK+ Version 3.24.28, cairo version 1.17.4)
 of 2021-04-18 built on thinkpad-t440p
Repository revision: 5819f4fb0a9337fab4c32dac557a02ec6497bce5
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101001
System Description: Arch Linux

Configured using:
 'configure --with-nativecomp'

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

Important settings:
  value of $LC_MONETARY: de_DE.utf8
  value of $LC_NUMERIC: de_DE.utf8
  value of $LC_TIME: de_DE.utf8
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: mu4e:main

Minor modes in effect:
  global-aggressive-indent-mode: t
  dynamic-completion-mode: t
  which-key-mode: t
  company-posframe-mode: t
  global-company-mode: t
  yas-global-mode: t
  yas-minor-mode: t
  global-git-commit-mode: t
  magit-auto-revert-mode: t
  override-global-mode: t
  vertico-mode: t
  aggressive-completion-mode: t
  minibuffer-depth-indicate-mode: t
  electric-pair-mode: t
  recentf-mode: t
  pixel-scroll-mode: t
  global-subword-mode: t
  subword-mode: t
  save-place-mode: t
  savehist-mode: t
  show-paren-mode: t
  shell-dirtrack-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t
  overwrite-mode: overwrite-mode-binary

Load-path shadows:
~/Repos/el/mu/build/mu4e/mu4e hides ~/Repos/el/mu/mu4e/mu4e
~/Repos/el/mu/build/mu4e/mu4e-main hides ~/Repos/el/mu/mu4e/mu4e-main
~/Repos/el/mu/build/mu4e/mu4e-view hides ~/Repos/el/mu/mu4e/mu4e-view
~/Repos/el/mu/build/mu4e/mu4e-org hides ~/Repos/el/mu/mu4e/mu4e-org
~/Repos/el/mu/build/mu4e/mu4e-lists hides ~/Repos/el/mu/mu4e/mu4e-lists
~/Repos/el/mu/build/mu4e/mu4e-actions hides ~/Repos/el/mu/mu4e/mu4e-actions
~/Repos/el/mu/build/mu4e/mu4e-utils hides ~/Repos/el/mu/mu4e/mu4e-utils
~/Repos/el/mu/build/mu4e/mu4e-context hides ~/Repos/el/mu/mu4e/mu4e-context
~/Repos/el/mu/build/mu4e/mu4e-draft hides ~/Repos/el/mu/mu4e/mu4e-draft
~/Repos/el/mu/build/mu4e/mu4e-message hides ~/Repos/el/mu/mu4e/mu4e-message
~/Repos/el/mu/build/mu4e/mu4e-compose hides ~/Repos/el/mu/mu4e/mu4e-compose
~/Repos/el/mu/build/mu4e/mu4e-view-common hides ~/Repos/el/mu/mu4e/mu4e-view-common
~/Repos/el/mu/build/mu4e/mu4e-view-old hides ~/Repos/el/mu/mu4e/mu4e-view-old
~/Repos/el/mu/build/mu4e/mu4e-view-gnus hides ~/Repos/el/mu/mu4e/mu4e-view-gnus
~/Repos/el/mu/build/mu4e/mu4e-headers hides ~/Repos/el/mu/mu4e/mu4e-headers
~/Repos/el/mu/build/mu4e/mu4e-mark hides ~/Repos/el/mu/mu4e/mu4e-mark
~/Repos/el/mu/build/mu4e/mu4e-icalendar hides ~/Repos/el/mu/mu4e/mu4e-icalendar
~/Repos/el/mu/build/mu4e/mu4e-speedbar hides ~/Repos/el/mu/mu4e/mu4e-speedbar
~/Repos/el/mu/build/mu4e/mu4e-contrib hides ~/Repos/el/mu/mu4e/mu4e-contrib
~/Repos/el/mu/build/mu4e/mu4e-proc hides ~/Repos/el/mu/mu4e/mu4e-proc
~/Repos/el/mu/build/mu4e/mu4e-meta hides ~/Repos/el/mu/mu4e/mu4e-meta
~/Repos/el/mu/build/mu4e/mu4e-vars hides ~/Repos/el/mu/mu4e/mu4e-vars

Features:
(shadow face-remap emacsbug company-oddmuse company-keywords
company-etags etags fileloop generator xref project company-gtags
company-dabbrev-code company-dabbrev company-files company-clang
company-capf company-cmake company-semantic company-template
company-bbdb paredit vc-mtn vc-hg vc-bzr vc-src vc-sccs vc-svn vc-cvs
vc-rcs display-fill-column-indicator auto-package-update finder-inf
generic yaml-mode fish-mode cargo cargo-process compile rust-mode
web-mode disp-table preview-latex auto-loads tex-site deadgrep spinner s
hl-todo aggressive-indent rainbow-mode vc-git vc-dir ewoc vc
vc-dispatcher epa-file dired-x mu4e mu4e-org mu4e-main mu4e-view
mu4e-view-gnus mu4e-view-common mu4e-headers mu4e-compose mu4e-context
mu4e-draft mu4e-actions ido rfc2368 mu4e-mark mu4e-proc mu4e-utils
doc-view jka-compr image-mode exif mu4e-lists mu4e-message flow-fill org
ob ob-tangle ob-ref ob-lob ob-table ob-exp org-macro org-footnote
org-src ob-comint org-pcomplete org-list org-faces org-entities
org-version ob-emacs-lisp ob-core ob-eval org-table ol org-keys
org-compat org-macs org-loaddefs find-func cal-menu calendar
cal-loaddefs mule-util hl-line mu4e-vars mu4e-meta smtpmail-multi
smtpmail sendmail ecomplete completion auto-dictionary flyspell ispell
tramp-smb which-key highlight-parentheses company-restclient
know-your-http-well http-status-codes http-relations http-methods
http-headers restclient company-posframe posframe company pcase
yasnippet forge-list forge-commands forge-semi forge-bitbucket buck
forge-gogs gogs forge-gitea gtea forge-gitlab glab forge-github
ghub-graphql treepy gsexp ghub let-alist gnutls forge-notify
forge-revnote forge-pullreq forge-issue forge-topic forge-post
markdown-mode color thingatpt noutline outline forge-repo forge
forge-core forge-db closql emacsql-sqlite advice emacsql
emacsql-compiler 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 imenu magit-diff smerge-mode diff diff-mode git-commit
log-edit pcvs-util add-log magit-core magit-autorevert autorevert
filenotify magit-margin magit-transient magit-process with-editor server
magit-mode transient magit-git magit-section magit-utils crm dash
visual-filename-abbrev debbugs soap-client url-http url-auth url-gw nsm
warnings rng-xsd rng-dt rng-util xsd-regexp bug-reference
use-package-bind-key bind-key easy-mmode vertico aggressive-completion
icomplete mb-depth use-package-diminish windmove elec-pair rx
tramp-cache tramp-sh recentf tree-widget pixel-scroll cap-words
superword subword saveplace savehist paren smiley gnus-art mm-uu mml2015
mm-view mml-smime smime dig gnus-sum shr kinsoku svg dom gnus-group
gnus-undo gnus-start gnus-dbus dbus xml gnus-cloud nnimap nnmail
mail-source utf7 netrc nnoo gnus-spec gnus-int gnus-range message rmc
puny dired dired-loaddefs rfc822 mml mml-sec epa derived epg epg-config
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader gnus-win gnus wid-edit nnheader gnus-util rmail
rmail-loaddefs rfc2047 rfc2045 ietf-drums text-property-search mm-util
mail-prsvr mail-utils edmacro kmacro dracula-theme diminish cl-extra
help-mode use-package-ensure use-package-core tramp tramp-loaddefs
trampver tramp-integration files-x tramp-compat shell pcomplete comint
ansi-color ring parse-time iso8601 time-date ls-lisp format-spec info
package browse-url url url-proxy url-privacy url-expand url-methods
url-history url-cookie url-domsuf url-util mailcap 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 cl-loaddefs cl-lib iso-transl 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 easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer 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 cl-preloaded nadvice button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 518704 83112)
 (symbols 48 42109 5)
 (strings 32 190891 6393)
 (string-bytes 1 5742383)
 (vectors 16 73612)
 (vector-slots 8 872832 27435)
 (floats 8 516 131)
 (intervals 56 763 27)
 (buffers 992 12))

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Tassilo Horn <tsdh <at> gnu.org>, bug-gnu-emacs <at> gnu.org
Subject: Re: 28.0.50; [native-comp] vertico package doesn't work when loading
 the corresponding eln file
Date: Sun, 18 Apr 2021 13:38:04 +0200

This issue has been reported before on github:

https://github.com/minad/vertico/issues/13
https://github.com/minad/vertico/issues/15 (duplicate)

As Tassilo observed, the bug seems to occur only on native, but I have 
not investigated this myself yet.

Message #11 received at 47868 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Tassilo Horn <tsdh <at> gnu.org>
Cc: 47868 <at> debbugs.gnu.org, mail <at> daniel-mendler.de
Subject: Re: bug#47868: 28.0.50;
 [native-comp] vertico package doesn't work when loading the
 corresponding eln file
Date: Sun, 18 Apr 2021 15:10:00 +0300

> From: Tassilo Horn <tsdh <at> gnu.org>
> Date: Sun, 18 Apr 2021 13:16:29 +0200
> 
>      M-x load-file RET
>      ~/.emacs.d/eln-cache/28.0.50-bc702aed/vertico-6eb6690f-90eaf131.eln

Btw, the hashes in this file name are entirely system-dependent, so
people should not try looking for a file under that specific name,
just the newest file that matches vertico-*.eln in some subdirectory
of eln-cache.

Message #14 received at 47868 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: Tassilo Horn <tsdh <at> gnu.org>
Cc: 47868 <at> debbugs.gnu.org, mail <at> daniel-mendler.de
Subject: Re: bug#47868: 28.0.50; [native-comp] vertico package doesn't work
 when loading the corresponding eln file
Date: Sun, 18 Apr 2021 18:32:26 +0000

Tassilo Horn <tsdh <at> gnu.org> writes:

> The GNU ELPA package vertico shows possible completion candidates in an
> overlay during minibuffer completion.  I've just noticed that this
> doesn't work properly when the generated eln file is loaded rather than
> the el or elc file.
>
> By "not working properly" I mean that frequently either the minibuffer
> prompt is displayed or the overlay showing the candidates but not both.
> Sometimes also both, but then the cursor is blinking at the end of the
> candidates overlay rather than immediately behind the input.  Also the
> candidate count overlay seems to be only shown if the prompt is also
> there but not the canditates overlay.  Here's a screenshot:
>
>
>
> Here's a reproduction recipe:
>
>   0. Build the current native-comp branch, HEAD is
>      af0af63742fd2383dae5627d0ce8167517fd4700 right now.
>      Install the vertico GNU ELPA package and wait for its async
>      native compilation to be finished.
>   1. emacs -Q
>   2. Load the ELN file (which is the only one I have, so I'm sure it's
>      the right one for my current emacs):
>      M-x load-file RET
>      ~/.emacs.d/eln-cache/28.0.50-bc702aed/vertico-6eb6690f-90eaf131.eln
>      RET
>   3. M-x vertico-mode RET
>   4. Try C-x C-b or C-x C-f to see the problem.

Hi Tassilo,

thanks for reporting this.

I think it would be very helpful to know which one is the Emacs function
that once gets called misbehaves.

Thanks

  Andrea

PS one should just load the .elc file to obtain the corresponding .eln
loaded.

Message #17 received at 47868 <at> debbugs.gnu.org (full text, mbox):

From: Tassilo Horn <tsdh <at> gnu.org>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: 47868 <at> debbugs.gnu.org, mail <at> daniel-mendler.de
Subject: Re: bug#47868: 28.0.50; [native-comp] vertico package doesn't work
 when loading the corresponding eln file
Date: Sun, 18 Apr 2021 20:49:13 +0200

Andrea Corallo <akrl <at> sdf.org> writes:

Hi Andrea,

> I think it would be very helpful to know which one is the Emacs
> function that once gets called misbehaves.

That's a bit hard to pinpoint.  It happens during `completing-read'
where the two vertico functions below are called from a
`post-command-hook' in order to display vertico's two overlays, the
"count overlay" before the minibuffer prompt, and the "candidates
overlay" starting after the input string.  Here's a "screenshot" of how
it is supposed to look like, | representing the usual position of point.

[1/3]   Find file: input|
input-candidate1
input-candidate2
input-candidate3

And here are the functions:

--8<---------------cut here---------------start------------->8---
(defun vertico--display-candidates (lines)
  "Update candidates overlay `vertico--candidates-ov' with LINES."
  (move-overlay vertico--candidates-ov (point-max) (point-max))
  (overlay-put vertico--candidates-ov 'after-string
               (apply #'concat #(" " 0 1 (cursor t)) (and lines "\n") lines))
  (let* ((lh (default-line-height))
         (resize (default-value 'resize-mini-windows))
         (dp (- (max (cdr (window-text-pixel-size))
                     (* lh (1+ (if resize (length lines) vertico-count))))
                (window-pixel-height)))
         (dl (ceiling dp lh)))
    (when (or (> dl 0) (eq resize t)) (window-resize nil dl))))

(defun vertico--display-count ()
  "Update count overlay `vertico--count-ov'."
  (when vertico-count-format
    (move-overlay vertico--count-ov (point-min) (point-min))
    (overlay-put vertico--count-ov 'before-string
                 (format (car vertico-count-format)
                         (format (cdr vertico-count-format)
                                 (cond ((>= vertico--index 0) (1+ vertico--index))
                                       ((vertico--allow-prompt-selection-p) "*")
                                       (t "!"))
                                 vertico--total)))))
--8<---------------cut here---------------end--------------->8---

> PS one should just load the .elc file to obtain the corresponding .eln
> loaded.

Ah, ok.

Bye,
Tassilo

Message #20 received at 47868 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: Tassilo Horn <tsdh <at> gnu.org>
Cc: 47868 <at> debbugs.gnu.org, mail <at> daniel-mendler.de
Subject: Re: bug#47868: 28.0.50; [native-comp] vertico package doesn't work
 when loading the corresponding eln file
Date: Mon, 19 Apr 2021 19:28:36 +0000

Tassilo Horn <tsdh <at> gnu.org> writes:

>> PS one should just load the .elc file to obtain the corresponding .eln
>> loaded.
>
> Ah, ok.
>
> Bye,
> Tassilo

Sorry I was imprecise on this, if one explicitly request the .elc via
`load' this will be loaded, if `load' can chose the extension the .eln
will be preferred.

  Andrea

PS I'm starting to look into this issue.

Message #23 received at 47868 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: Tassilo Horn <tsdh <at> gnu.org>
Cc: 47868 <at> debbugs.gnu.org, mail <at> daniel-mendler.de
Subject: Re: bug#47868: 28.0.50; [native-comp] vertico package doesn't work
 when loading the corresponding eln file
Date: Tue, 20 Apr 2021 20:13:57 +0000

Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs <at> gnu.org> writes:

[...]

> PS I'm starting to look into this issue.

Just a small update, yesterday I had a look and I think I've a grasp of
what's going on but today I had no time to progress on this.  I think
I'll come-up with a patch this week.

Thanks!

  Andrea

Message #26 received at 47868 <at> debbugs.gnu.org (full text, mbox):

From: jakanakaevangeli <at> chiru.no
To: Andrea Corallo <akrl <at> sdf.org>
Cc: 47868 <at> debbugs.gnu.org, mail <at> daniel-mendler.de, tsdh <at> gnu.org
Subject: Re: bug#47868: 28.0.50; [native-comp] vertico package doesn't work
 when loading the corresponding eln file
Date: Wed, 21 Apr 2021 00:19:14 +0200

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=47922
is very likely related.

Best.

Message #29 received at 47868 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: jakanakaevangeli <at> chiru.no
Cc: 47868 <at> debbugs.gnu.org, mail <at> daniel-mendler.de, tsdh <at> gnu.org
Subject: Re: bug#47868: 28.0.50; [native-comp] vertico package doesn't work
 when loading the corresponding eln file
Date: Wed, 21 Apr 2021 07:58:41 +0000

jakanakaevangeli <at> chiru.no writes:

> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=47922
> is very likely related.
>

Yes, the reason is that we hash cons all immediates using equal has test
function, but this does not distinguish string with different
properties.  I'm working on the best fix here.

I'll merge 47922 with this bug.

Thanks

  Andrea

Message #34 received at 47868 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Andrea Corallo <akrl <at> sdf.org>, jakanakaevangeli <at> chiru.no
Cc: 47868 <at> debbugs.gnu.org, tsdh <at> gnu.org
Subject: Re: bug#47868: 28.0.50; [native-comp] vertico package doesn't work
 when loading the corresponding eln file
Date: Wed, 21 Apr 2021 10:05:21 +0200

On 4/21/21 9:58 AM, Andrea Corallo wrote:
> Yes, the reason is that we hash cons all immediates using equal has test
> function, but this does not distinguish string with different
> properties.  I'm working on the best fix here.
> 
> I'll merge 47922 with this bug.

Is it uncommon to use propertized string literals, since these were the 
ones which introduced the issue here? (No coincidence that two packages 
of mine were affected by this)

Daniel

Message #37 received at 47868 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 47868 <at> debbugs.gnu.org, jakanakaevangeli <at> chiru.no, tsdh <at> gnu.org
Subject: Re: bug#47868: 28.0.50; [native-comp] vertico package doesn't work
 when loading the corresponding eln file
Date: Wed, 21 Apr 2021 08:31:55 +0000

Daniel Mendler <mail <at> daniel-mendler.de> writes:

> On 4/21/21 9:58 AM, Andrea Corallo wrote:
>> Yes, the reason is that we hash cons all immediates using equal has test
>> function, but this does not distinguish string with different
>> properties.  I'm working on the best fix here.
>> I'll merge 47922 with this bug.
>
> Is it uncommon to use propertized string literals, since these were
> the ones which introduced the issue here? (No coincidence that two
> packages of mine were affected by this)

Yes it is uncommon but still this is a native compiler bug as the byte
compiler hash cons string correctly.

  Andrea

Message #40 received at 47868 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 47868 <at> debbugs.gnu.org, tsdh <at> gnu.org, jakanakaevangeli <at> chiru.no,
 akrl <at> sdf.org
Subject: Re: bug#47868: 28.0.50;
 [native-comp] vertico package doesn't work when loading the
 corresponding eln file
Date: Wed, 21 Apr 2021 12:17:56 +0300

> From: Daniel Mendler <mail <at> daniel-mendler.de>
> Date: Wed, 21 Apr 2021 10:05:21 +0200
> Cc: 47868 <at> debbugs.gnu.org, tsdh <at> gnu.org
> 
> Is it uncommon to use propertized string literals

Not sure if it's common, but IMNSHO it's somewhat ugly and hard to
read (and easy to make mistakes).  So my recommendation is not to use
that; use propertize instead.

Message #43 received at 47868 <at> debbugs.gnu.org (full text, mbox):

From: Tassilo Horn <tsdh <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 47868 <at> debbugs.gnu.org, Daniel Mendler <mail <at> daniel-mendler.de>,
 jakanakaevangeli <at> chiru.no, akrl <at> sdf.org
Subject: Re: bug#47868: 28.0.50; [native-comp] vertico package doesn't work
 when loading the corresponding eln file
Date: Wed, 21 Apr 2021 12:11:00 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Daniel Mendler <mail <at> daniel-mendler.de>
>> Date: Wed, 21 Apr 2021 10:05:21 +0200
>> Cc: 47868 <at> debbugs.gnu.org, tsdh <at> gnu.org
>> 
>> Is it uncommon to use propertized string literals
>
> Not sure if it's common, but IMNSHO it's somewhat ugly and hard to
> read (and easy to make mistakes).  So my recommendation is not to use
> that; use propertize instead.

In the concrete example at hand, which is "add properties to a specific
substring of the string", I think it is not more ugly and hard to read
than having to split the string and propertize the individual parts and
then concatenate it back again.

Well, maybe it's on par here but I cannot even imagine how to use
`propertize' to create a string where properties overlap without jumping
through hoops.

Hm, when I do

  #("foo" 0 3 (bar t) 1 2 (foo 1))

I get

  #("foo" 0 1 (bar t) 1 2 (foo 1) 2 3 (bar t))

which I did not expect.  I'd rather expect

  #("foo" 0 1 (bar t) 1 2 (foo 1 bar t) 2 3 (bar t))

so it seems like the propertized string literals also have some
gotchas...

Bye,
Tassilo

Message #46 received at 47868 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: 47868 <at> debbugs.gnu.org, jakanakaevangeli <at> chiru.no, tsdh <at> gnu.org
Subject: Re: bug#47868: 28.0.50; [native-comp] vertico package doesn't work
 when loading the corresponding eln file
Date: Wed, 21 Apr 2021 13:32:51 +0200

On 4/21/21 10:31 AM, Andrea Corallo wrote:
> Daniel Mendler <mail <at> daniel-mendler.de> writes:
>> Is it uncommon to use propertized string literals, since these were
>> the ones which introduced the issue here? (No coincidence that two
>> packages of mine were affected by this)
> 
> Yes it is uncommon but still this is a native compiler bug as the byte
> compiler hash cons string correctly.

No doubt it is is a bug. I was just wondering that two of my recent 
packages triggered a bug given that many people already happily use 
native. Thank you for fixing this and for all the efforts with native 
compilation. I am looking very much forward to using it.

Daniel

Message #49 received at 47868 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 47868 <at> debbugs.gnu.org, jakanakaevangeli <at> chiru.no, tsdh <at> gnu.org
Subject: Re: bug#47868: 28.0.50; [native-comp] vertico package doesn't work
 when loading the corresponding eln file
Date: Wed, 21 Apr 2021 15:42:38 +0000

Daniel Mendler <mail <at> daniel-mendler.de> writes:

> On 4/21/21 10:31 AM, Andrea Corallo wrote:
>> Daniel Mendler <mail <at> daniel-mendler.de> writes:
>>> Is it uncommon to use propertized string literals, since these were
>>> the ones which introduced the issue here? (No coincidence that two
>>> packages of mine were affected by this)
>> Yes it is uncommon but still this is a native compiler bug as the
>> byte
>> compiler hash cons string correctly.
>
> No doubt it is is a bug. I was just wondering that two of my recent
> packages triggered a bug given that many people already happily use
> native. Thank you for fixing this and for all the efforts with native
> compilation. I am looking very much forward to using it.
>
> Daniel

Yes, indeed your packages did a very good work at unveiling this bug :)

As of f842816125 it should work (haven't tried again with vertigo tho),
some testing appreciated as usual.

Thanks!

  Andrea

Message #52 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Doug Davis <ddavis <at> ddavis.io>
To: Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of
 text editors" <bug-gnu-emacs <at> gnu.org>
Cc: 47868 <at> debbugs.gnu.org, Daniel Mendler <mail <at> daniel-mendler.de>,
 tsdh <at> gnu.org, jakanakaevangeli <at> chiru.no, Andrea Corallo <akrl <at> sdf.org>
Subject: Re: bug#47868: 28.0.50; [native-comp] vertico package doesn't work
 when loading the corresponding eln file
Date: Wed, 21 Apr 2021 12:11:26 -0400

Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs <at> gnu.org> writes:

> Daniel Mendler <mail <at> daniel-mendler.de> writes:
>
>> On 4/21/21 10:31 AM, Andrea Corallo wrote:
>>> Daniel Mendler <mail <at> daniel-mendler.de> writes:
>>>> Is it uncommon to use propertized string literals, since these were
>>>> the ones which introduced the issue here? (No coincidence that two
>>>> packages of mine were affected by this)
>>> Yes it is uncommon but still this is a native compiler bug as the
>>> byte
>>> compiler hash cons string correctly.
>>
>> No doubt it is is a bug. I was just wondering that two of my recent
>> packages triggered a bug given that many people already happily use
>> native. Thank you for fixing this and for all the efforts with native
>> compilation. I am looking very much forward to using it.
>>
>> Daniel
>
> Yes, indeed your packages did a very good work at unveiling this bug :)
>
> As of f842816125 it should work (haven't tried again with vertigo tho),
> some testing appreciated as usual.

I just recompiled my local native-comp branch and vertico is behaving as
it does with my package-manager-provided Emacs 27.2 installation. thanks
Daniel and Andrea :)

Message #60 received at 47868-done <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: Doug Davis <ddavis <at> ddavis.io>
Cc: 47868-done <at> debbugs.gnu.org, mail <at> daniel-mendler.de,
 jakanakaevangeli <at> chiru.no, tsdh <at> gnu.org
Subject: Re: bug#47868: 28.0.50; [native-comp] vertico package doesn't work
 when loading the corresponding eln file
Date: Thu, 22 Apr 2021 07:47:20 +0000

Doug Davis <ddavis <at> ddavis.io> writes:

> Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of
> text editors" <bug-gnu-emacs <at> gnu.org> writes:
>
>> Daniel Mendler <mail <at> daniel-mendler.de> writes:
>>
>>> On 4/21/21 10:31 AM, Andrea Corallo wrote:
>>>> Daniel Mendler <mail <at> daniel-mendler.de> writes:
>>>>> Is it uncommon to use propertized string literals, since these were
>>>>> the ones which introduced the issue here? (No coincidence that two
>>>>> packages of mine were affected by this)
>>>> Yes it is uncommon but still this is a native compiler bug as the
>>>> byte
>>>> compiler hash cons string correctly.
>>>
>>> No doubt it is is a bug. I was just wondering that two of my recent
>>> packages triggered a bug given that many people already happily use
>>> native. Thank you for fixing this and for all the efforts with native
>>> compilation. I am looking very much forward to using it.
>>>
>>> Daniel
>>
>> Yes, indeed your packages did a very good work at unveiling this bug :)
>>
>> As of f842816125 it should work (haven't tried again with vertigo tho),
>> some testing appreciated as usual.
>
> I just recompiled my local native-comp branch and vertico is behaving as
> it does with my package-manager-provided Emacs 27.2 installation. thanks
> Daniel and Andrea :)

Very nice thanks you for testing :)

Closing this then, happy to reopen if necessary.

Thanks

  Andrea

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.