From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pedro Andres Aranda Gutierrez Newsgroups: gmane.emacs.devel Subject: Re: Emacs-devel Digest, Vol 207, Issue 32 Date: Wed, 2 Jun 2021 11:25:26 +0200 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000861e9605c3c50b1a" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14429"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jun 02 11:27:59 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1loNAM-0003UQ-Q2 for ged-emacs-devel@m.gmane-mx.org; Wed, 02 Jun 2021 11:27:59 +0200 Original-Received: from localhost ([::1]:37020 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1loNAL-0005mv-RN for ged-emacs-devel@m.gmane-mx.org; Wed, 02 Jun 2021 05:27:57 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59022) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1loN8Z-0003kW-Jc for emacs-devel@gnu.org; Wed, 02 Jun 2021 05:26:07 -0400 Original-Received: from mail-lj1-x22c.google.com ([2a00:1450:4864:20::22c]:33630) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1loN8P-0008H2-Ib for emacs-devel@gnu.org; Wed, 02 Jun 2021 05:26:07 -0400 Original-Received: by mail-lj1-x22c.google.com with SMTP id o8so1804725ljp.0 for ; Wed, 02 Jun 2021 02:25:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=an/hA0ezA2Pwh+Tpzz4eFHX7EKwv22jmDW3ct1UBoQI=; b=Zt/b1QVTQnBKPBuxz+MT4noLxArYhPqCUtg9z38lV0Mm5BASJIfVz/H2HqaidPGgHP cfrGhL73tAtffJLhL83tgXWWGtFBvlapYJvKxPMnuh2Ja1AfgrJv6Zy/2xzHHE9KjnMp g28MFMfmH9hE+oZsofHfcU4KEu7dnUvJTcILt9kteD3AdFq8HmjC9mSYcuWN6JhxGeK2 MtBN4WIyh+8RACnNveVpGxxtauF7aV644ZrmaHWRMH/1Nal4Hm2PVwdd3WFxkS0wvu2V xchfkLOQvhTcw5SjjKfRfcsTJLDlEzbT/R4AzcJSEZpg1nBBAg9Et3XVtxtQhMJXLcZf /cug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=an/hA0ezA2Pwh+Tpzz4eFHX7EKwv22jmDW3ct1UBoQI=; b=Uq/i//7R7MAqFncYNqM6tXFkeTlizWc8yu7ns5YFCzR2ezNJlWGk6lVcI7ZKqfg08M KazgfBojnjQ40JkyJ/OVeO3WnhT6wTsXX9TlYQAhN30puYeToqPH5is0+RwsKgTx3orM erNEuAkUk9t8eOi359Zu07m4VnMrZmKPjNtV+ZOk9PWEQu3njfUInXlDxAN5IhTDNVMN AC1SZaPn6Gpipz/M6+1hI0v54cH2MHNiLqIcQpxWSOErAvXJVxLd3HQohujKDqc2S+MW zHQ1el6w1ocdc7Qos0jO6ZutRiOlHL6dX6w6NW7Lr4lJ1rwNkgIsHM8KFY2fdLeh2x/8 T6bA== X-Gm-Message-State: AOAM532HYLJDMMop1CSacdc842EIuCQ8WasbAi9dJKCva6kBHfUA9VgV F2w4SRHJ4U9EG9wR60ye50EgXBX0aqsJiowY9JtajQNyQ7QfXg== X-Google-Smtp-Source: ABdhPJwbo40nfat+QxLkldnLQwcgMsriHwv8vnVc9HyyMbN5V85SlHAQgaQD4kIhq7itHArzUhexBxA+ygzKR9iNYiA= X-Received: by 2002:a2e:8759:: with SMTP id q25mr24192135ljj.435.1622625952864; Wed, 02 Jun 2021 02:25:52 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2a00:1450:4864:20::22c; envelope-from=paaguti@gmail.com; helo=mail-lj1-x22c.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_MIME_MALF=0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:270273 Archived-At: --000000000000861e9605c3c50b1a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Message: 50 > Date: Wed, 26 May 2021 15:19:22 +0300 > From: Eli Zaretskii > To: Peter Oliver > Cc: emacs-devel@gnu.org > Subject: Re: GUI X-FreeDesktop integration > Message-ID: <8335u9bsc5.fsf@gnu.org> >> Date: Tue, 25 May 2021 22:34:18 +0100 (BST) >> From: Peter Oliver >> >> > In fact, the _least_ surprising from >> > an XDG/FDO perspective would actually be to _only_ expose >> > a "client+autolaunch" desktop entry and just call that the >> > point of integration for Emacs. >> >> Agreed. Attached is a patch which achieves this. >This is a backward-incompatible change, so why should it be the >default, and not the alternative action via right-click? And anyway, >wouldn't some people be surprised to see emacsclient frame when they >expected a new instance of Emacs, without their say-so? I was ;-) /Pedro A. On Wed, 26 May 2021 at 18:05, wrote: > Send Emacs-devel mailing list submissions to > emacs-devel@gnu.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.gnu.org/mailman/listinfo/emacs-devel > or, via email, send a message with subject or body 'help' to > emacs-devel-request@gnu.org > > You can reach the person managing the list at > emacs-devel-owner@gnu.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Emacs-devel digest..." > > > Today's Topics: > > 1. Re: macOS metal rendering engine in mac port (Aaron Jensen) > 2. Re: [PATCH] (icomplete-vertical-mode): Add support for > affixations and, annotations (Juri Linkov) > 3. Re: [PATCH] (icomplete-vertical-mode): Add support for > affixations and, annotations (Juri Linkov) > 4. Re: Unicode combining characters (Stefan Monnier) > 5. Re: Unicode combining characters (Eli Zaretskii) > 6. Re: [PATCH] (icomplete-vertical-mode): Add support for > affixations and, annotations (Stefan Monnier) > 7. Re: macOS metal rendering engine in mac port (Eli Zaretskii) > 8. Re: [PATCH] (icomplete-vertical-mode): Add support for > affixations and, annotations (Jo=C3=A3o T=C3=A1vora) > 9. Re: Emacs is not reproducible (Stefan Monnier) > 10. Cycling first N heading levels in outline (Christopher Dimech) > 11. Re: [PATCH] (icomplete-vertical-mode): Add support for > affixations and, annotations (Jo=C3=A3o T=C3=A1vora) > 12. Re: macOS metal rendering engine in mac port (Aaron Jensen) > 13. Re: [PATCH] lisp/files.el: Add `file-name-set-extension` > (Andreas Schwab) > 14. Re: Emacs is not reproducible (T.V Raman) > 15. Re: [PATCH] lisp/files.el: Add `file-name-set-extension` > (Basil L. Contovounesios) > 16. Re: Emacs is not reproducible (Glenn Morris) > 17. Re: Unicode combining characters (Cl=C3=A9ment Pit-Claudel) > 18. Re: Emacs is not reproducible (Basil L. Contovounesios) > 19. Re: Unicode combining characters (Eli Zaretskii) > 20. Re: Unicode combining characters (Cl=C3=A9ment Pit-Claudel) > 21. Re: master eaf224f: Repad the Face header in Gnus > (Lars Ingebrigtsen) > 22. Re: [PATCH] lisp/files.el: Add `file-name-set-extension` > (Colin Woodbury) > 23. Re: Unicode combining characters (Eli Zaretskii) > 24. Re: [PATCH] lisp/files.el: Add `file-name-set-extension` > (Colin Woodbury) > 25. Re: macOS metal rendering engine in mac port (Alan Third) > 26. Re: [PATCH] (icomplete-vertical-mode): Add support for > affixations and, annotations (Stefan Monnier) > 27. Re: [External] : Re: [PATCH] When deleting in bookmark menu, > prompt for confirmation. (Karl Fogel) > 28. Re: [PATCH] lisp/files.el: Add `file-name-set-extension` > (Stefan Monnier) > 29. Re: [PATCH] (icomplete-vertical-mode): Add support for > affixations and, annotations (Dmitry Gutov) > 30. Re: [PATCH] (icomplete-vertical-mode): Add support for > affixations and, annotations (Juri Linkov) > 31. Re: [PATCH] (icomplete-vertical-mode): Add support for > affixations and, annotations (Jo=C3=A3o T=C3=A1vora) > 32. Re: [ELPA?] Controlling Isearch from the minibuffer (Juri Linkov) > 33. Re: [PATCH] lisp/files.el: Add `file-name-set-extension` > (Colin Woodbury) > 34. Re: [PATCH] lisp/files.el: Add `file-name-set-extension` > (Stefan Monnier) > 35. Re: GUI X-FreeDesktop integration (Peter Oliver) > 36. Re: [PATCH] lisp/files.el: Add `file-name-set-extension` > (Colin Woodbury) > 37. Re: master eaf224f: Repad the Face header in Gnus (Alex Bochannek) > 38. Re: master eaf224f: Repad the Face header in Gnus (Alex Bochannek) > 39. Re: [PATCH] (icomplete-vertical-mode): Add support for > affixations and, annotations (Jo=C3=A3o T=C3=A1vora) > 40. Re: macOS metal rendering engine in mac port (Aaron Jensen) > 41. Re: macOS metal rendering engine in mac port (Alan Third) > 42. Re: macOS metal rendering engine in mac port (Aaron Jensen) > 43. Re: [PATCH] lisp/files.el: Add `file-name-set-extension` > (Andreas Schwab) > 44. Re: macOS metal rendering engine in mac port (Aaron Jensen) > 45. Re: GUI X-FreeDesktop integration (Robert Pluim) > 46. Re: Unicode combining characters (Anand Tamariya) > 47. Re: Unicode combining characters (Joost Kremers) > 48. Re: [External] : Re: [PATCH] When deleting in bookmark menu, > prompt for confirmation. (Eli Zaretskii) > 49. Re: GUI X-FreeDesktop integration (Peter Oliver) > 50. Re: GUI X-FreeDesktop integration (Eli Zaretskii) > 51. Re: Unicode combining characters (Eli Zaretskii) > 52. Re: Cycling first N heading levels in outline (Ihor Radchenko) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 25 May 2021 09:31:16 -0700 > From: Aaron Jensen > To: Alan Third , Aaron Jensen > , emacs-devel@gnu.org, YAMAMOTO Mitsuharu > > Subject: Re: macOS metal rendering engine in mac port > Message-ID: > < > CAHyO48y-Ve+gjPxdt+hbPcXwFLA5LFvuccah_-SaPa6dvk67Bw@mail.gmail.com> > Content-Type: text/plain; charset=3D"UTF-8" > > On Mon, May 24, 2021 at 2:01 AM Alan Third wrote: > > > > I think so. A lot of what people like (smooth scrolling, etc.) would > > have to be removed. > > Weird, this has never worked for me, but maybe I've had it misconfigured > > > One more thing to try... > > > > modified src/nsterm.m > > @@ -8376,7 +8376,13 @@ - (void)unfocusDrawingBuffer > > NSTRACE ("[EmacsView unfocusDrawingBuffer]"); > > > > [NSGraphicsContext setCurrentContext:nil]; > > - [self setNeedsDisplay:YES]; > > + [surface releaseContext]; > > + [[self layer] setContents:(id)[surface getSurface]]; > > + [surface performSelectorOnMainThread:@selector (getContext) > > + withObject:nil > > + waitUntilDone:NO]; > > + > > + //[self setNeedsDisplay:YES]; > > } > > > > > > @@ -8513,11 +8519,11 @@ - (void)updateLayer > > There's a private method, -[CALayer setContentsChanged], that we > > could use to force it, but we shouldn't often get the same > > surface twice in a row. */ > > - [surface releaseContext]; > > - [[self layer] setContents:(id)[surface getSurface]]; > > - [surface performSelectorOnMainThread:@selector (getContext) > > - withObject:nil > > - waitUntilDone:NO]; > > + // [surface releaseContext]; > > + // [[self layer] setContents:(id)[surface getSurface]]; > > + // [surface performSelectorOnMainThread:@selector (getContext) > > + // withObject:nil > > + // waitUntilDone:NO]; > > } > > #endif > > > > > > All this does is reduce the time between us deciding we're done with > > drawing and sending it off to VRAM (although it might not, I'm not > > entirely sure when updateLayer gets called). > > > > I expect this to reduce frame rate, but perhaps it will improve input > > lag a little. > > I don't know if it's something funky with my machine or not but I've > noticed some stutters with this patch. As in, it appears to miss > paints. I'll type a character and won't see it until I type something > else. Is it possible that this patch could cause that? > > Thanks, > > Aaron > > > > ------------------------------ > > Message: 2 > Date: Tue, 25 May 2021 19:53:00 +0300 > From: Juri Linkov > To: Jo=C3=A3o T=C3=A1vora > Cc: Daniel Mendler , emacs-devel@gnu.org, > monnier@iro.umontreal.ca > Subject: Re: [PATCH] (icomplete-vertical-mode): Add support for > affixations and, annotations > Message-ID: <87mtsibwjz.fsf@mail.linkov.net> > Content-Type: text/plain > > > I've seen this in read-extended-command--affixation.el indeed. I don't > > understand: > > > > - the need for this window switch, but I might be missing something; > > - if the need is to process in the same buffer, why one switches > > windows; > > It can switch buffers instead of selecting windows. > > > - why it can't and shouldn't be done in the funcall locus by the fronte= nd > > (in this case minibuffer-completion-help) > > Because this requirement is specific only to > read-extended-command--affixation, > other uses might require other buffers to be current, so this doesn't > remove > the argument for having the affixation-function. > > > But if they exercise this freedom fully they're going to break the > > layout of the frontend, like icomplete.el, which potentially does layou= t > > calculations. Probably company.el or any other frontend is the same. > > So not so much holding hands, more like saving feet from being shot :-)= . > > For many years we allowed the users to shoot themselves in the foot, > and yet nobody did it :-) > > With the existing function 'display-sort-function' you can easily > add new elements to the list of completions or remove the existing > candidates. And that is not a problem in practice. > > > > ------------------------------ > > Message: 3 > Date: Tue, 25 May 2021 19:59:25 +0300 > From: Juri Linkov > To: Jo=C3=A3o T=C3=A1vora > Cc: Daniel Mendler , "emacs-devel@gnu.org" > , monnier@iro.umontreal.ca, Dmitry Gutov > > Subject: Re: [PATCH] (icomplete-vertical-mode): Add support for > affixations and, annotations > Message-ID: <87tumq92pe.fsf@mail.linkov.net> > Content-Type: text/plain > > > I have no strong feelings on plist, versus alist, versus propertized > > string, versus object, versus whatever. Just slightly strong feelings > > as to the fundamental mission of this function which is to do > > annotation/affixation/whatchacallit, not filtering or reordering. > > > > For reasons of "forward compatibility", as you called them, which is th= e > > ability for newer backends to work on older Emacs that don't understand > > these new things, if that work is done in `annotation-function` then it > > needs to use propertized strings. But if it's done in a new thing, say > > called decoration-function, it doesn't. > > As I said a month ago, while affixation-function was an improvement over > annotation-function, it's still not perfect. I welcome a better API > function, > but OTOH adding prefix/suffix text properties on the annotation strings > is not an improvement. > > > To clarify, the analog in some markup format is specifying something as > > "emphasis" and then the renderer usually decides that bold if it can, o= r > > surround it in asterisks. But the markup format doesn't usually say > > "bold". For the same reasons, what you're now calling "columns" should > > probably be referred to as "fields" or something equivalently agnostic > > as to the format in which they are display. > > While looking for an analog, a better analogy would be the classic > MVC architecture: > > - M: data comes from the list of completion strings; > - V: render functions like completion--insert-* or icomplete-completions; > - C: API callers that provide metadata functions that specify > how to process data for displaying, e.g. they define > display-sort-function > where the prefix 'display-' hints that it affects the view, > so the frontend has no own choice how to sort completions. > > Following such pattern, affixation-function could return more fields > (e.g. when completions-format is customized to the value 'multi-column') > in the same format as tabulated-list (and an indication in which column > there are completion candidates) for the frontend to display in columns. > > > > ------------------------------ > > Message: 4 > Date: Tue, 25 May 2021 13:22:25 -0400 > From: Stefan Monnier > To: Anand Tamariya > Cc: emacs-devel@gnu.org > Subject: Re: Unicode combining characters > Message-ID: > Content-Type: text/plain > > > Hindi Devanagari script has lot of unicode combining characters which > > results in misalignment in a rectangular overlay for constant number of > > characters (screenshot ) > > < > https://1.bp.blogspot.com/-P2ZnFePOpOo/YK0cNJ4B5II/AAAAAAAAJJs/t-MADtxUep= s3S_WXZ_rFWjf9daH49sr9QCLcBGAsYHQ/s421/combining.png > > > > What would be a recommended way to tackle this in Emacs? > > In a GUI session, the usual answer is to use posframe, AFAIK. > > > Stefan > > > > > ------------------------------ > > Message: 5 > Date: Tue, 25 May 2021 20:24:15 +0300 > From: Eli Zaretskii > To: Anand Tamariya > Cc: emacs-devel@gnu.org > Subject: Re: Unicode combining characters > Message-ID: <83k0nmbubk.fsf@gnu.org> > > > From: Anand Tamariya > > Date: Tue, 25 May 2021 21:26:44 +0530 > > > > Hindi Devanagari script has lot of unicode combining characters which > results in misalignment in a > > rectangular overlay for constant number of characters (screenshot ) > > What would be a recommended way to tackle this in Emacs? > > Use align-to 'space' display spec and/or the window-text-pixel-size > function, which will account for the actual size of the text on > display. string-width can also be used, but it only gives an > approximation, as it is oblivious of the actual size of the font > glyphs. > > > > ------------------------------ > > Message: 6 > Date: Tue, 25 May 2021 13:24:42 -0400 > From: Stefan Monnier > To: Juri Linkov > Cc: Jo=C3=A3o T=C3=A1vora , Daniel Mendler > , emacs-devel@gnu.org > Subject: Re: [PATCH] (icomplete-vertical-mode): Add support for > affixations and, annotations > Message-ID: > Content-Type: text/plain > > > With the existing function 'display-sort-function' you can easily > > add new elements to the list of completions or remove the existing > > candidates. And that is not a problem in practice. > > Indeed. I think we should aim for an API that's easy to use correctly. > If it makes incorrect uses difficult, that's good, but that shouldn't be > the driving goal. > > If you want to make incorrect uses hard or even impossible, there are > dependently typed programming languages for that ;-) > > > Stefan > > > > > ------------------------------ > > Message: 7 > Date: Tue, 25 May 2021 20:34:19 +0300 > From: Eli Zaretskii > To: Aaron Jensen > Cc: emacs-devel@gnu.org, alan@idiocy.org, > mituharu@math.s.chiba-u.ac.jp > Subject: Re: macOS metal rendering engine in mac port > Message-ID: <83h7iqbtus.fsf@gnu.org> > > > From: Aaron Jensen > > Date: Tue, 25 May 2021 08:35:42 -0700 > > Cc: emacs-devel@gnu.org, Alan Third , > > YAMAMOTO Mitsuharu > > > > > The 17% is about twice what I'd expect, since adding 3 characters to > > > each line of xdisp.c enlarges its text by only 9.3%. > > > > Pure guess here, but it's also making a lot of empty lines non-empty > > (14% more). Perhaps that has an added cost somehow? > > Not AFAIU, but I had so many surprises in this investigation that I no > longer believe in my intuition. So who knows, maybe you are right. > > > > How did you compile Emacs? which compiler and what compiler and linke= r > > > switches? And what kind of CPU do you have there? I'm looking for > > > something that could explain why parts of code that should take like > > > 20% of the total redisplay time are so dominant in your case. > > > > clang, with -O2. Specifically these configure flags: > > > > CFLAGS=3D"-g3 -O2" \ > > --disable-silent-rules \ > > --with-xml2 \ > > --with-gnutls \ > > --without-dbus \ > > --with-imagemagick \ > > --with-modules \ > > --with-rsvg \ > > --with-ns \ > > --disable-ns-self-contained > > > > > > This CPU: Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz > > So you have 16 execution units, but a relatively slow clock. Hmm... > > > > Alan, do you see similar numbers (in percents) to what Aaron reports? > > > Or is that something peculiar to his system? > > > > What I get depends on frame size and whether or not I'm using > > nativecomp or Alan's branch or master. I just a test with a smaller > > frame size (on Alan's branch this time, just happens to be what I have > > built) and saw 5.58 vs 6.8s: 22%. But then I ran the bench again w/ > > line numbers and couldn't get it below 7.2s, so there's quite a bit of > > variability in the test runs. > > FWIW, in my case, the default frame size (~37 lines) and a maximized > frame produce the same timings here. > > > > ------------------------------ > > Message: 8 > Date: Tue, 25 May 2021 18:40:45 +0100 > From: Jo=C3=A3o T=C3=A1vora > To: Stefan Monnier > Cc: Juri Linkov , Daniel Mendler > , emacs-devel@gnu.org > Subject: Re: [PATCH] (icomplete-vertical-mode): Add support for > affixations and, annotations > Message-ID: <87pmxeg19e.fsf@gmail.com> > Content-Type: text/plain; charset=3Dutf-8 > > Stefan Monnier writes: > > >> With the existing function 'display-sort-function' you can easily > >> add new elements to the list of completions or remove the existing > >> candidates. And that is not a problem in practice. > > Indeed. I think we should aim for an API that's easy to use correctly. > > If it makes incorrect uses difficult, that's good, but that shouldn't b= e > > the driving goal. > > I see, broken windows. You keep asking for good API's but when things > are proposed in that direction "that's good" but doesn't matter. > > I'm not exactly a fan of d-s-f, but likelyhood that it messes up is less > since it's likely called unconditionally on all returned completions by > the frontend. Indeed I wonder why d-s-f exists at all. > > As to the current shape affixation-function, I'm not mortally against it > just that its misdesign is a bit jarring, but so are so many other parts > of the completion system, so I guess, broken windows. It's just that > this is supposed to be a new part. > > Jo=C3=A3o > > > > > > ------------------------------ > > Message: 9 > Date: Tue, 25 May 2021 13:41:17 -0400 > From: Stefan Monnier > To: Glenn Morris > Cc: emacs-devel@gnu.org > Subject: Re: Emacs is not reproducible > Message-ID: > Content-Type: text/plain > > Glenn Morris [2021-05-23 19:52:08] wrote: > > Stefan Monnier wrote: > >>> There has been changes made in the past to fix some problems. > >>> I have a pending patch in bug#46502 (see below) which aims to fix som= e > >>> more of those problems, but still haven't heard confirmation that it > >>> helps. > > I did 10 builds with -j8; 5 without your patch and 5 with. > > The builds without your patch had changes in 12, 10, 9, 11 elc files. > > The builds with your patch had changes in 4, 4, 7, 4 elc files. > > Thanks for confirming what I was seeing. I pushed the patch to `master`. > > > Mostly tramp.elc, ox-odt.elc, ox.elc, cc-mode.elc; sometimes in > > eieio files. At least some of these seem to be > https://debbugs.gnu.org/34322 > > The mystery for those remains, > > > So it seems better in terms of less elc variation. > > It causes all tests in test/lisp/cedet/semantic-utest-ia.el to fail. > > I'm indeed looking at it, > > > Stefan > > > > > ------------------------------ > > Message: 10 > Date: Tue, 25 May 2021 19:41:12 +0200 > From: Christopher Dimech > To: K=C3=A9vin Le Gouguec > Cc: Stefan Monnier , Ihor Radchenko > , Jean Louis , > emacs-devel@gnu.org > Subject: Cycling first N heading levels in outline > Message-ID: > > > > > Content-Type: text/plain; charset=3DUTF-8 > > I need some help on how to use "outline-minor-mode-highlight" option to > customize > the colours for headings because they are showing up as normal comments. > > I am in emacs-lisp-mode. > > > > Sent: Monday, May 24, 2021 at 10:57 PM > > From: "K=C3=A9vin Le Gouguec" > > To: "Christopher Dimech" > > Cc: "Stefan Monnier" , "Ihor Radchenko" < > yantar92@gmail.com>, "Jean Louis" , emacs-devel@gnu.org > > Subject: Re: Cycling first N heading levels in outline > > > > Christopher Dimech writes: > > > > >> The convention used in ELisp is: > > >> > > >> ;;; Section > > >> ;;;; Subsection > > >> ;;;;; Subsubsection > > >> ;;;;;; Subsubsubsection > > >> ;;;;;;; Subsubsubsubsection > > >> [...] > > > > > > The headings still look like comments, whereas they are supposed to > get highlighted > > > according to the heading level. > > > > > > Could we get that to work in said way? > > > > On Emacs master, the outline-minor-mode-highlight option allows you to > > customize how headings are fontified: > > > > > When t, it puts outline faces only if there are no major mode=E2=80= =99s faces > > > on headings. When =E2=80=98override=E2=80=99, it completely overwrit= es major mode=E2=80=99s > > > faces with outline faces. When =E2=80=98append=E2=80=99, it tries to= append outline > > > faces to major mode=E2=80=99s faces. > > > > > > ------------------------------ > > Message: 11 > Date: Tue, 25 May 2021 18:46:07 +0100 > From: Jo=C3=A3o T=C3=A1vora > To: Juri Linkov > Cc: Daniel Mendler , "emacs-devel@gnu.org" > , monnier@iro.umontreal.ca, Dmitry Gutov > > Subject: Re: [PATCH] (icomplete-vertical-mode): Add support for > affixations and, annotations > Message-ID: <87lf82g10g.fsf@gmail.com> > Content-Type: text/plain; charset=3Dutf-8 > > Juri Linkov writes: > > > As I said a month ago, while affixation-function was an improvement ove= r > > annotation-function, it's still not perfect. I welcome a better API > function, > > but OTOH adding prefix/suffix text properties on the annotation strings > > is not an improvement. > > Sure it's not beautiful, but it's an improvement to annotation-function. > If affixation-function were a function of a single completion, it would > be fine. For a hint at a good design, look at the language server > protocol. It returns a large list of completions, and then you can > "resolve" a completion to get many more of its properties. So > resolution-function is an option. > > > Following such pattern, affixation-function could return more fields > > (e.g. when completions-format is customized to the value 'multi-column'= ) > > in the same format as tabulated-list (and an indication in which column > > there are completion candidates) for the frontend to display in > > columns. > > If you prefer to see it that way, I have no objection, though I prefer > to think of backend and frontend simply (i.e. your C doesn't match > anything here very accurately). > > Jo=C3=A3o > > > > > > ------------------------------ > > Message: 12 > Date: Tue, 25 May 2021 10:48:09 -0700 > From: Aaron Jensen > To: Eli Zaretskii > Cc: emacs-devel@gnu.org, Alan Third , YAMAMOTO > Mitsuharu > Subject: Re: macOS metal rendering engine in mac port > Message-ID: > < > CAHyO48xPo2TwFixRCwsmonzMk03TZZYRT9WRX+BVQS6Dpkx6rg@mail.gmail.com> > Content-Type: text/plain; charset=3D"UTF-8" > > On Tue, May 25, 2021 at 10:34 AM Eli Zaretskii wrote: > > > > > > This CPU: Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz > > > > So you have 16 execution units, but a relatively slow clock. Hmm... > > It's a laptop, so the low clock is power saving. It has turbo boost to > 5GHz, though thermally I don't think I can actually hit that for very > long, if at all. But at least 4.3GHz or so. > > > > ------------------------------ > > Message: 13 > Date: Tue, 25 May 2021 19:48:25 +0200 > From: Andreas Schwab > To: "Colin Woodbury" > Cc: emacs-devel@gnu.org > Subject: Re: [PATCH] lisp/files.el: Add `file-name-set-extension` > Message-ID: <87r1hu3dsm.fsf@igel.home> > Content-Type: text/plain > > On Mai 25 2021, Colin Woodbury wrote: > > > diff --git a/lisp/files.el b/lisp/files.el > > index 62e1702fdf..f8aefa7930 100644 > > --- a/lisp/files.el > > +++ b/lisp/files.el > > @@ -4889,6 +4889,20 @@ extension, the value is \"\"." > > (if period > > ""))))) > > > > +(defun file-name-set-extension (filename extension) > > + "Change the extension of a FILENAME to EXTENSION. > > +Sanitizes the input to consolidate leading/trailing dots. > > + > > +Returns `nil' if either of the FILENAME or EXTENSION are `nil' > > +before sanitizing, or empty afterwards." > > + (when (and filename extension) > > What is the use-case for nil? > > Andreas. > > -- > Andreas Schwab, schwab@linux-m68k.org > GPG Key fingerprint =3D 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC= 1 > "And now for something completely different." > > > > ------------------------------ > > Message: 14 > Date: Tue, 25 May 2021 10:52:35 -0700 > From: "T.V Raman" > To: Stefan Monnier > Cc: Glenn Morris , emacs-devel@gnu.org > Subject: Re: Emacs is not reproducible > Message-ID: > Content-Type: text/plain; charset=3Dgb18030 > > Stefan Monnier writes: > > > This may or may not be related --- but I reported a few months ago that > compiling emacspeak with make -j 4 resulted in unpredictable behavior -- > I got rid of the parallel build and problems went away. > > 1. There were no warnings during the parallel build. > > 2. Things were "weird" in that some advice definitions were not active, > reloading files fixed it. > > I decided to keep life simple at that point and got rid of the parallel > build. > > Glenn Morris [2021-05-23 19:52:08] wrote: > >> Stefan Monnier wrote: > >>>> There has been changes made in the past to fix some problems. > >>>> I have a pending patch in bug#46502 (see below) which aims to fix so= me > >>>> more of those problems, but still haven't heard confirmation that it > >>>> helps. > >> I did 10 builds with -j8; 5 without your patch and 5 with. > >> The builds without your patch had changes in 12, 10, 9, 11 elc files. > >> The builds with your patch had changes in 4, 4, 7, 4 elc files. > > > > Thanks for confirming what I was seeing. I pushed the patch to `master= `. > > > >> Mostly tramp.elc, ox-odt.elc, ox.elc, cc-mode.elc; sometimes in > >> eieio files. At least some of these seem to be > https://debbugs.gnu.org/34322 > > > > The mystery for those remains, > > > >> So it seems better in terms of less elc variation. > >> It causes all tests in test/lisp/cedet/semantic-utest-ia.el to fail. > > > > I'm indeed looking at it, > > > > > > Stefan > > > > > > -- > > Thanks, > > --Raman(I Search, I Find, I Misplace, I Research) > =E2=99=88 Id: kg:/m/0285kf1 =F0=9F=A6=AE > > > > ------------------------------ > > Message: 15 > Date: Tue, 25 May 2021 19:00:44 +0100 > From: "Basil L. Contovounesios" > To: "Colin Woodbury" > Cc: emacs-devel@gnu.org > Subject: Re: [PATCH] lisp/files.el: Add `file-name-set-extension` > Message-ID: <87lf82y9pv.fsf@tcd.ie> > Content-Type: text/plain > > "Colin Woodbury" writes: > > > + (let* ((patt "[ \\t\\n\\r.]+") ; Borrowed from `string-trim'. > > Those backslashes need escaping only in string-trim's docstring, not in > the literal regexp string. > > Thanks, > > -- > Basil > > > > ------------------------------ > > Message: 16 > Date: Tue, 25 May 2021 14:03:52 -0400 > From: Glenn Morris > To: Stefan Monnier > Cc: emacs-devel@gnu.org > Subject: Re: Emacs is not reproducible > Message-ID: > Content-Type: text/plain > > > >> It causes all tests in test/lisp/cedet/semantic-utest-ia.el to fail. > > FTR, I should have said "four", not "all". > > > > ------------------------------ > > Message: 17 > Date: Tue, 25 May 2021 14:15:33 -0400 > From: Cl=C3=A9ment Pit-Claudel > To: emacs-devel@gnu.org > Subject: Re: Unicode combining characters > Message-ID: <2437db42-62fc-ea3c-279b-170152defc62@gmail.com> > Content-Type: text/plain; charset=3Dutf-8 > > On 5/25/21 1:24 PM, Eli Zaretskii wrote: > >> From: Anand Tamariya > >> Date: Tue, 25 May 2021 21:26:44 +0530 > >> > >> Hindi Devanagari script has lot of unicode combining characters which > results in misalignment in a > >> rectangular overlay for constant number of characters (screenshot ) > >> What would be a recommended way to tackle this in Emacs? > > > > Use align-to 'space' display spec and/or the window-text-pixel-size > > function, which will account for the actual size of the text on > > display. > > Will this work? The misaligned specs are already part of a replacing > dipsplay spec, so the additional align-to would be ignored, no? > > (IIRC, there is no way to say "replace this text by this string followed > by this specified space; it's one or the other, right?) > > > > ------------------------------ > > Message: 18 > Date: Tue, 25 May 2021 19:27:24 +0100 > From: "Basil L. Contovounesios" > To: Stefan Monnier > Cc: Glenn Morris , emacs-devel@gnu.org > Subject: Re: Emacs is not reproducible > Message-ID: <87r1huwtwz.fsf@tcd.ie> > Content-Type: text/plain; charset=3Dutf-8 > > Stefan Monnier writes: > > > Glenn Morris [2021-05-23 19:52:08] wrote: > >> Stefan Monnier wrote: > >>>> There has been changes made in the past to fix some problems. > >>>> I have a pending patch in bug#46502 (see below) which aims to fix so= me > >>>> more of those problems, but still haven't heard confirmation that it > >>>> helps. > >> I did 10 builds with -j8; 5 without your patch and 5 with. > >> The builds without your patch had changes in 12, 10, 9, 11 elc files. > >> The builds with your patch had changes in 4, 4, 7, 4 elc files. > > > > Thanks for confirming what I was seeing. I pushed the patch to `master= `. > > > >> So it seems better in terms of less elc variation. > >> It causes all tests in test/lisp/cedet/semantic-utest-ia.el to fail. > > > > I'm indeed looking at it, > > FYI if those test failures prove too boring there are some new and > exciting bootstrap warnings to play with too :). > > In end of data: > calc/calc.el:3126:27: Warning: the function =E2=80=98math-compare=E2=80= =99 is not known to > be > defined. > calc/calc.el:2805:27: Warning: the function =E2=80=98math-zerop=E2=80=99 = is not known to be > defined. > In tramp-handle-access-file: > net/tramp.el:3238:43: Warning: attempt to inline =E2=80=98tramp-error=E2= =80=99 before it > was > defined > net/tramp.el:3238:43: Warning: attempt to inline =E2=80=98tramp-error=E2= =80=99 before it > was > defined > > Thanks, > > -- > Basil > > > > ------------------------------ > > Message: 19 > Date: Tue, 25 May 2021 21:39:50 +0300 > From: Eli Zaretskii > To: Cl=C3=A9ment Pit-Claudel > Cc: emacs-devel@gnu.org > Subject: Re: Unicode combining characters > Message-ID: <83cztebqtl.fsf@gnu.org> > Content-Type: text/plain; charset=3Dutf-8 > > > From: Cl=C3=A9ment Pit-Claudel > > Date: Tue, 25 May 2021 14:15:33 -0400 > > > > On 5/25/21 1:24 PM, Eli Zaretskii wrote: > > >> From: Anand Tamariya > > >> Date: Tue, 25 May 2021 21:26:44 +0530 > > >> > > >> Hindi Devanagari script has lot of unicode combining characters whic= h > results in misalignment in a > > >> rectangular overlay for constant number of characters (screenshot ) > > >> What would be a recommended way to tackle this in Emacs? > > > > > > Use align-to 'space' display spec and/or the window-text-pixel-size > > > function, which will account for the actual size of the text on > > > display. > > > > Will this work? The misaligned specs are already part of a replacing > dipsplay spec, so the additional align-to would be ignored, no? > > I don't understand, but maybe you know about the particular use case > more than I do. I just mentioned two devices that can be accurate to > 1 pixel wrt to the X coordinate. > > > (IIRC, there is no way to say "replace this text by this string followe= d > by this specified space; it's one or the other, right?) > > Again, I don't think I follow. If you have "this text", you can > calculate its width on display, and then know how many pixels of white > space you will need after "this string" replaces that text. So, > unless I'm missing something, specifying the space width is redundant, > and actually makes a solvable problem unsolvable. > > But I might be talking nonsense because I don't understand what > problem the OP wants to solve. > > > > ------------------------------ > > Message: 20 > Date: Tue, 25 May 2021 15:30:21 -0400 > From: Cl=C3=A9ment Pit-Claudel > To: Eli Zaretskii > Cc: emacs-devel@gnu.org > Subject: Re: Unicode combining characters > Message-ID: <3e40bcd1-3d04-23c0-37a7-6a283ca4e3e4@gmail.com> > Content-Type: text/plain; charset=3Dutf-8 > > On 5/25/21 2:39 PM, Eli Zaretskii wrote: > >> From: Cl=C3=A9ment Pit-Claudel > >> Date: Tue, 25 May 2021 14:15:33 -0400 > >> > >> On 5/25/21 1:24 PM, Eli Zaretskii wrote: > >>>> From: Anand Tamariya > >>>> Date: Tue, 25 May 2021 21:26:44 +0530 > >>>> > >>>> Hindi Devanagari script has lot of unicode combining characters whic= h > results in misalignment in a > >>>> rectangular overlay for constant number of characters (screenshot ) > >>>> What would be a recommended way to tackle this in Emacs? > >>> > >>> Use align-to 'space' display spec and/or the window-text-pixel-size > >>> function, which will account for the actual size of the text on > >>> display. > >> > >> Will this work? The misaligned specs are already part of a replacing > dipsplay spec, so the additional align-to would be ignored, no? > > > > I don't understand, but maybe you know about the particular use case > > more than I do. I just mentioned two devices that can be accurate to > > 1 pixel wrt to the X coordinate. > > > >> (IIRC, there is no way to say "replace this text by this string > followed by this specified space; it's one or the other, right?) > > > > Again, I don't think I follow. If you have "this text", you can > > calculate its width on display, and then know how many pixels of white > > space you will need after "this string" replaces that text. So, > > unless I'm missing something, specifying the space width is redundant, > > and actually makes a solvable problem unsolvable. > > Based on the screenshot this is an issue with Company. Company displays > its "pop-ups" by putting a replacing 'display property on the text > following the point (and on the next few lines). So if the buffer contai= ns > > ABC XYZ DEF GHI > JKL MNO PQR STU > > and the point is after XYZ, then company puts a replacing display spec > from " DEF" to "STU". > To display completions "XYZ1233" and "XYZ456", the replacing display spec > contains "123| GHI\nJKL XYZ456| STU", so the final display is > > ABC XYZ123| GHI > JKL XYZ456| STU > > The OP's issue is that "123" and "456" don't have the same length. As fa= r > as I know, there is no way to add extra space after 123 or 456 so that th= ey > reach the same X coordinate, given that they are already part of a displa= y > spec. > > Cl=C3=A9ment. > > > > ------------------------------ > > Message: 21 > Date: Tue, 25 May 2021 21:31:58 +0200 > From: Lars Ingebrigtsen > To: Alex Bochannek > Cc: emacs-devel@gnu.org > Subject: Re: master eaf224f: Repad the Face header in Gnus > Message-ID: <871r9upq35.fsf@gnus.org> > Content-Type: text/plain > > Alex Bochannek writes: > > > OK, agreed. Do you want me to submit a patch to revert that code and th= e > > tests? > > I think that might make sense, but I have no strong feelings about the > matter. > > -- > (domestic pets only, the antidote for overdose, milk.) > bloggy blog: http://lars.ingebrigtsen.no > > > > ------------------------------ > > Message: 22 > Date: Tue, 25 May 2021 12:42:05 -0700 > From: "Colin Woodbury" > To: "Andreas Schwab" > Cc: emacs-devel@gnu.org > Subject: Re: [PATCH] lisp/files.el: Add `file-name-set-extension` > Message-ID: > Content-Type: text/plain; charset=3D"utf-8" > > Hi Andreas, > > `nil` seemed more appropriate than returning either an empty string or > throwing an error. The intent is to signal a failure in general, as it > looks like other related functions in that file do. > > On Tue, 25 May 2021, at 10:48, Andreas Schwab wrote: > > On Mai 25 2021, Colin Woodbury wrote: > > > > > diff --git a/lisp/files.el b/lisp/files.el > > > index 62e1702fdf..f8aefa7930 100644 > > > --- a/lisp/files.el > > > +++ b/lisp/files.el > > > @@ -4889,6 +4889,20 @@ extension, the value is \"\"." > > > (if period > > > ""))))) > > > > > > +(defun file-name-set-extension (filename extension) > > > + "Change the extension of a FILENAME to EXTENSION. > > > +Sanitizes the input to consolidate leading/trailing dots. > > > + > > > +Returns `nil' if either of the FILENAME or EXTENSION are `nil' > > > +before sanitizing, or empty afterwards." > > > + (when (and filename extension) > > > > What is the use-case for nil? > > > > Andreas. > > > > -- > > Andreas Schwab, schwab@linux-m68k.org > > GPG Key fingerprint =3D 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA A= EC1 > > "And now for something completely different." > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.gnu.org/archive/html/emacs-devel/attachments/20210525/e7d4c= 532/attachment.html > > > > ------------------------------ > > Message: 23 > Date: Tue, 25 May 2021 22:44:29 +0300 > From: Eli Zaretskii > To: Cl=C3=A9ment Pit-Claudel > Cc: emacs-devel@gnu.org > Subject: Re: Unicode combining characters > Message-ID: <83a6oibntu.fsf@gnu.org> > Content-Type: text/plain; charset=3Dutf-8 > > > Cc: emacs-devel@gnu.org > > From: Cl=C3=A9ment Pit-Claudel > > Date: Tue, 25 May 2021 15:30:21 -0400 > > > > Based on the screenshot this is an issue with Company. Company display= s > its "pop-ups" by putting a replacing 'display property on the text > following the point (and on the next few lines). So if the buffer contai= ns > > > > ABC XYZ DEF GHI > > JKL MNO PQR STU > > > > and the point is after XYZ, then company puts a replacing display spec > from " DEF" to "STU". > > To display completions "XYZ1233" and "XYZ456", the replacing display > spec contains "123| GHI\nJKL XYZ456| STU", so the final display is > > > > ABC XYZ123| GHI > > JKL XYZ456| STU > > > > The OP's issue is that "123" and "456" don't have the same length. As > far as I know, there is no way to add extra space after 123 or 456 so tha= t > they reach the same X coordinate, given that they are already part of a > display spec. > > First, the OP said "overlay", and overlay strings can have display > properties. > > And second, I'd expect the current code to use string-width to compute > how much whitespace will be needed after each completion candidate, > and string-width already accounts for composed (a.k.a "combined") > characters. Yes, string-width provides only an approximation for the > true pixel width of the string, but that's not specific to > compositions, and the whole technique is somewhat of a kludge anyway, > for this reason and others. > > > > ------------------------------ > > Message: 24 > Date: Tue, 25 May 2021 12:45:58 -0700 > From: "Colin Woodbury" > To: "Basil L. Contovounesios" > Cc: emacs-devel@gnu.org > Subject: Re: [PATCH] lisp/files.el: Add `file-name-set-extension` > Message-ID: > Content-Type: text/plain; charset=3D"utf-8" > > Thank you, you're right. I've tested the old and revised code, and the > double backslash wasn't neccesary. > > I've attached the revised patch. > > On Tue, 25 May 2021, at 11:00, Basil L. Contovounesios wrote: > > "Colin Woodbury" > > writes: > > > > > + (let* ((patt "[ \\t\\n\\r.]+") ; Borrowed from `string-trim'. > > > > Those backslashes need escaping only in string-trim's docstring, not in > > the literal regexp string. > > > > Thanks, > > > > -- > > Basil > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.gnu.org/archive/html/emacs-devel/attachments/20210525/4b16c= 111/attachment.html > > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: file-name-set-extension.patch > Type: text/x-patch > Size: 1045 bytes > Desc: not available > URL: < > https://lists.gnu.org/archive/html/emacs-devel/attachments/20210525/4b16c= 111/attachment.bin > > > > ------------------------------ > > Message: 25 > Date: Tue, 25 May 2021 14:50:14 +0100 > From: Alan Third > To: Eli Zaretskii > Cc: aaronjensen@gmail.com, emacs-devel@gnu.org > Subject: Re: macOS metal rendering engine in mac port > Message-ID: > Content-Type: text/plain; charset=3Dus-ascii > > On Tue, May 25, 2021 at 04:47:41PM +0300, Eli Zaretskii wrote: > > > Date: Tue, 25 May 2021 14:34:37 +0100 > > > From: Alan Third > > > Cc: aaronjensen@gmail.com, emacs-devel@gnu.org > > > > > > FWIW, on the Mac I see a slightly smaller performance penalty with > > > display-line-numbers-mode, around 18%. > > > > Is that an optimized build or unoptimized? In my tests with optimized > > builds, line numbers add about 10% to 12% to the scroll benchmark. > > Unoptimized code shows almost no effect: around 2%. > > In both cases the default, so -O2. > -- > Alan Third > > > > ------------------------------ > > Message: 26 > Date: Tue, 25 May 2021 16:01:14 -0400 > From: Stefan Monnier > To: Jo=C3=A3o T=C3=A1vora > Cc: Juri Linkov , Daniel Mendler > , emacs-devel@gnu.org > Subject: Re: [PATCH] (icomplete-vertical-mode): Add support for > affixations and, annotations > Message-ID: > Content-Type: text/plain > > > I see, broken windows. You keep asking for good API's but when things > > are proposed in that direction "that's good" but doesn't matter. > > [ Remember that the whole design of Emacs and ELisp goes against the > usual software engineering practice of using encapsulation and > abstraction to modularize the code so that one part can't mess with > the other. > > Instead, Emacs's idea of empowering users means that for one part to > be able to mess with another is considered a feature rather than > a bug, and the "abstraction boundaries" are enforced by conventions > rather than by technical means. > > As a dependent-types kinda guy, I sometimes find it odd as well, but > I think it has served Emacs surprisingly well, so I tend to try and > keep following the same design, despite my natural leaning > against it. ] > > > As to the current shape affixation-function, I'm not mortally against i= t > > just that its misdesign is a bit jarring, but so are so many other part= s > > of the completion system, so I guess, broken windows. It's just that > > this is supposed to be a new part. > > The part of `affixation-function` which I find problematic is the fact > that it does the layout itself, whereas I think it would be better to do > it in the UI (so it can choose to use columns or not, to put it at the > beginning or at the end, etc...). > > The fact that it takes a whole list rather than a single element is more > in the "bikeshedcolor" category for me. > > > Stefan > > > > > ------------------------------ > > Message: 27 > Date: Tue, 25 May 2021 15:24:44 -0500 > From: Karl Fogel > To: Eli Zaretskii > Cc: orontee@gmail.com, drew.adams@oracle.com, larsi@gnus.org, > monnier@iro.umontreal.ca, emacs-devel@gnu.org > Subject: Re: [External] : Re: [PATCH] When deleting in bookmark menu, > prompt for confirmation. > Message-ID: <87fsyatvcj.fsf@red-bean.com> > Content-Type: text/plain; charset=3D"utf-8"; Format=3D"flowed" > > On 25 May 2021, Eli Zaretskii wrote: > >> From: Karl Fogel > >> Cc: orontee@gmail.com, drew.adams@oracle.com, larsi@gnus.org, > >> monnier@iro.umontreal.ca, emacs-devel@gnu.org > >> Date: Tue, 25 May 2021 00:38:22 -0500 > >> > >> >> Thoughts? > >> > > >> >I'll have thoughts when I see the result ;-) > >> > >> Heh, fair enough. My inquiry was about the general practice of > >> having one function's doc string referring out to another > >> function's. > > > >It depends on what you need to say, thus my response above. > > > >Given what you wrote, and what bookmark-load does with the prefix > >argument, I think it is better to say that explicitly in > >bookmark-bmenu-load's doc string, since you only need a single > >quite > >simple sentence to say that, whereas the doc strong of > >bookmark-load > >is quite long. > > Well, now that I've done it, I think your way is an improvement -- > although it turned out to be slightly more doc change than I > expected. Revised patch attached for review. > > Best regards, > -Karl > > -------------- next part -------------- > An embedded and charset-unspecified text was scrubbed... > Name: 0001-Improve-some-doc-strings-in-bookmark.el.patch > URL: < > https://lists.gnu.org/archive/html/emacs-devel/attachments/20210525/d4a44= b49/attachment.ksh > > > > ------------------------------ > > Message: 28 > Date: Tue, 25 May 2021 16:25:38 -0400 > From: Stefan Monnier > To: "Colin Woodbury" > Cc: "Basil L. Contovounesios" , emacs-devel@gnu.org > Subject: Re: [PATCH] lisp/files.el: Add `file-name-set-extension` > Message-ID: > Content-Type: text/plain > > > + (when (and filename extension) > > + (let* ((patt "[ \t\n\r.]+") ; Inspired by `string-trim'. > > + (filename (string-trim-right filename patt)) > > + (extension (string-trim-left extension patt))) > > + (unless (or (string-empty-p filename) > > + (string-empty-p extension)) > > + (concat (file-name-sans-extension filename) "." extension))))) > > Why do you trim [ \t\n\r.]+ from the end of the filename and the > beginning of the extension? > > I can see why you'd want to remove a single "." at the beginning of > `extension`, so as to allow extension to come with or without a leading > ".", but the rest seems rather surprising because such characters in my > experience almost never show up in such a circumstance (which means > that if they do, it's either on purpose and we should preserve it, or > it's an error "upstream" and we should try and help expose the error > rather than silently try to cover it). > > > Stefan > > > > > ------------------------------ > > Message: 29 > Date: Tue, 25 May 2021 23:27:36 +0300 > From: Dmitry Gutov > To: Stefan Monnier , Jo=C3=A3o T=C3=A1vora > > Cc: Juri Linkov , Daniel Mendler > , emacs-devel@gnu.org > Subject: Re: [PATCH] (icomplete-vertical-mode): Add support for > affixations and, annotations > Message-ID: <9d551b41-1559-b707-c3c0-61dbb055f148@yandex.ru> > Content-Type: text/plain; charset=3Dutf-8; format=3Dflowed > > On 25.05.2021 23:01, Stefan Monnier wrote: > > The fact that it takes a whole list rather than a single element is mor= e > > in the "bikeshedcolor" category for me. > > From where I'm standing, this color of the bike shed would make it > harder to use (if I ever found a way to support it in Company, that is). > > If affixation-function returns a list including extra data, I will then > have to convert it to some structure that allows lookup by completion > string (e.g. a hash table), and then pass that table on to the place the > completions are rendered. > > display-sort-function is different, because you can use it in one place, > have your list re-sorted, and then go on with the rendering of the > resulting collection. It doesn't force me to do any extra accounting. > > > > ------------------------------ > > Message: 30 > Date: Tue, 25 May 2021 23:37:43 +0300 > From: Juri Linkov > To: Jo=C3=A3o T=C3=A1vora > Cc: Daniel Mendler , "emacs-devel@gnu.org" > , monnier@iro.umontreal.ca, Dmitry Gutov > > Subject: Re: [PATCH] (icomplete-vertical-mode): Add support for > affixations and, annotations > Message-ID: <87y2c24lww.fsf@mail.linkov.net> > Content-Type: text/plain > > > Sure it's not beautiful, but it's an improvement to annotation-function= . > > If affixation-function were a function of a single completion, it would > > be fine. For a hint at a good design, look at the language server > > protocol. It returns a large list of completions, and then you can > > "resolve" a completion to get many more of its properties. So > > resolution-function is an option. > > resolution-function sounds good. Maybe this is not the most > suitable comparison but since you mentioned the word "resolve" > that evoked by association: resolver functions used in GraphQL. > > > > ------------------------------ > > Message: 31 > Date: Tue, 25 May 2021 21:46:43 +0100 > From: Jo=C3=A3o T=C3=A1vora > To: Stefan Monnier > Cc: Juri Linkov , Daniel Mendler > , emacs-devel@gnu.org > Subject: Re: [PATCH] (icomplete-vertical-mode): Add support for > affixations and, annotations > Message-ID: <87fsyafsng.fsf@gmail.com> > Content-Type: text/plain; charset=3Dutf-8 > > Stefan Monnier writes: > > >> I see, broken windows. You keep asking for good API's but when things > >> are proposed in that direction "that's good" but doesn't matter. > > > > [ Remember that the whole design of Emacs and ELisp goes against the > > usual software engineering practice of using encapsulation and > > abstraction to modularize the code so that one part can't mess with > > the other. > > No it doesn't :-) At least I don't design Lisp (Elisp or CL) systems > that way (or Ruby or JS, for more examples). Encapsulation or > abstraction aren't property of a specific language. Elisp can't > strictly enforce many things the way a C++ compiler refuses to compile, > but that doesn't mean there aren't a bunch of compile-time and run-time > assertions, much less that they are are useless. Among many examples, > just because Emacs Lisp uses a shared symbol namespace (sigh...) hasn't > stopped us from making the '--' convention or, say, carefully deciding > if a variable name should end in "-functions" or "-function". This is > nor bikeshedding for me, it's a daily part of design. > > > Instead, Emacs's idea of empowering users means that for one part to > > be able to mess with another is considered a feature rather than > > a bug, and the "abstraction boundaries" are enforced by conventions > > rather than by technical means. > > By both. There's always a way to subvert API intent by the programmer. > That's fine, but it doesn't mean it should be easy to. Pretty sure one > can frobnicate the order of the candidates in a single-arg annotation > function, but it's going to be a lot more code. > > Jo=C3=A3o > > > > > > > > ------------------------------ > > Message: 32 > Date: Tue, 25 May 2021 23:50:27 +0300 > From: Juri Linkov > To: Augusto Stoffel > Cc: emacs-devel@gnu.org > Subject: Re: [ELPA?] Controlling Isearch from the minibuffer > Message-ID: <87wnrm35d8.fsf@mail.linkov.net> > Content-Type: text/plain > > >> Now, I took a closer look at the history of changes around lazy > >> highlight and the interactions with other features seems very tricky. > >> I'm not super confident about the patch I'm attaching, but if you are > >> willing to review it and test a bit, I hope it helps. > > > > Everything looks right, but this needs more testing before pushing. > > Testing revealed some problems: > > 1. After enabling isearch-lazy-count, modes that use lazy-highligh, > such as e.g. query-replace displays the isearch message > overwriting query-replace prompt. Maybe this is because of the > removed check for 'isearch-mode' in isearch-lazy-highlight-* functions= ? > > 2. Using 'C-q' (isearch-quote-char) in the minibuffer or comint > displays a truncated string, e.g. on 'M-! C-r C-q C-a'. > Maybe the default message function should be called directly > in isearch-quote-char? > > 3. Maybe the same default message function should be called directly > also in some other functions like isearch-lazy-highlight-new-loop > and isearch-lazy-highlight-buffer-update? > > > > ------------------------------ > > Message: 33 > Date: Tue, 25 May 2021 14:21:07 -0700 > From: "Colin Woodbury" > To: "Stefan Monnier" > Cc: "Basil L. Contovounesios" , emacs-devel@gnu.org > Subject: Re: [PATCH] lisp/files.el: Add `file-name-set-extension` > Message-ID: <3780a7f9-19f4-4216-baa9-ce00b3dbace9@www.fastmail.com> > Content-Type: text/plain; charset=3D"utf-8" > > That regex was borrowed directly from `string-trim`, to which I added a > `.`. You're right that the main motivation was to allow the caller to pas= s > either `.foo` or `foo` as the extension and have either case work (many > languages do this). Leaving the other characters in the regex seemed like= a > sanitary thing to do, just in case they pass something bogus. Although as > the code is, there's nothing preventing them from still giving bogus > characters before the file, or after the extension, making the resulting > filepath still meaningless. > > So we could consider: > > 1. Simplifying the regex to just include dots (and perhaps whitespace) > (i.e. trust the caller), or; > 2. Expanding the logic to sanitize both ends of both arguments, (i.e. > don't trust the caller), or; > 3. Adding error-throwing logic if malformed files or extensions are given > (i.e. warn the user). > > I'm happy to alter the patch for any of those scenarios, whichever is > preferable. Thanks! > > On Tue, 25 May 2021, at 13:25, Stefan Monnier wrote: > > > + (when (and filename extension) > > > + (let* ((patt "[ \t\n\r.]+") ; Inspired by `string-trim'. > > > + (filename (string-trim-right filename patt)) > > > + (extension (string-trim-left extension patt))) > > > + (unless (or (string-empty-p filename) > > > + (string-empty-p extension)) > > > + (concat (file-name-sans-extension filename) "." extension)))= )) > > > > Why do you trim [ \t\n\r.]+ from the end of the filename and the > > beginning of the extension? > > > > I can see why you'd want to remove a single "." at the beginning of > > `extension`, so as to allow extension to come with or without a leading > > ".", but the rest seems rather surprising because such characters in my > > experience almost never show up in such a circumstance (which means > > that if they do, it's either on purpose and we should preserve it, or > > it's an error "upstream" and we should try and help expose the error > > rather than silently try to cover it). > > > > > > Stefan > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.gnu.org/archive/html/emacs-devel/attachments/20210525/d78ba= c17/attachment.html > > > > ------------------------------ > > Message: 34 > Date: Tue, 25 May 2021 17:29:19 -0400 > From: Stefan Monnier > To: "Colin Woodbury" > Cc: "Basil L. Contovounesios" , emacs-devel@gnu.org > Subject: Re: [PATCH] lisp/files.el: Add `file-name-set-extension` > Message-ID: > Content-Type: text/plain > > > That regex was borrowed directly from `string-trim`, to which I added > > a `.`. You're right that the main motivation was to allow the caller to > pass > > either `.foo` or `foo` as the extension and have either case work (many > > languages do this). Leaving the other characters in the regex seemed li= ke > > a sanitary thing to do, just in case they pass something bogus. > > File names can be used in different ways for different purposes. > We don't have any good reason to think that a space or a newline at the > end of a file name (or beginning of an extension) is "bogus". > > If such things occurred somewhat often and always in ways where they are > indeed undesirable, we could consider removing them (the tradeoff > between occasional harm and frequent error-avoidance would be > favorable), but here this is just asking for trouble with no benefit. > > > 1. Simplifying the regex to just include dots (and perhaps whitespace) > (i.e. trust the caller), or; > > Please do that. > > > 2. Expanding the logic to sanitize both ends of both arguments, (i.e. > don't trust the caller), or; > > I don't think we have any reason to think we should "sanitize" it. > > > 3. Adding error-throwing logic if malformed files or extensions are > given (i.e. warn the user). > > "Malformed" according to which standard? > > > Stefan > > > > > ------------------------------ > > Message: 35 > Date: Tue, 25 May 2021 22:34:18 +0100 (BST) > From: Peter Oliver > To: emacs-devel@gnu.org > Subject: Re: GUI X-FreeDesktop integration > Message-ID: > <7f52af92-4fb5-74b4-232a-eabfa315ac0@froglet.home.mavit.org.uk> > Content-Type: text/plain; charset=3D"utf-8"; Format=3D"flowed" > > On Sunday 16th May, Robin Tarsiger wrote: > > > In fact, the _least_ surprising from > > an XDG/FDO perspective would actually be to _only_ expose > > a "client+autolaunch" desktop entry and just call that the > > point of integration for Emacs. > > Agreed. Attached is a patch which achieves this. > > -- > Peter Oliver > -------------- next part -------------- > From 84508dbc948038f9b7c797b3ec012c00379df7ee Mon Sep 17 00:00:00 2001 > From: Peter Oliver > Date: Tue, 25 May 2021 22:06:43 +0100 > Subject: [PATCH] From a GUI, lauch via emacsclient by default > > * etc/emacs-mail.desktop, etc/emacs.desktop: Call emacsclient not > emacs by default. Provide plain emacs as an alternative action. > --- > etc/NEWS | 7 +++++++ > etc/emacs-mail.desktop | 13 ++++++++++--- > etc/emacs.desktop | 11 ++++++++++- > etc/emacsclient.desktop | 12 ------------ > 4 files changed, 27 insertions(+), 16 deletions(-) > delete mode 100644 etc/emacsclient.desktop > > diff --git a/etc/NEWS b/etc/NEWS > index 1541b74a3b..0605c8b46c 100644 > --- a/etc/NEWS > +++ b/etc/NEWS > @@ -108,6 +108,13 @@ avoid security issues when executing untrusted code. > See the manual > page for 'seccomp' system call, for details about Secure Computing > filters. > > +** Launching Emacs from a GUI now defaults to trying emacsclient. > +When launching Emacs via a freedesktop.org-compatible GUI, it is now > +the default to try to use emacsclient to open the file in an existing > +Emacs frame. Opening a new frame in an existing Emacs or a separate > +instance of Emacs are available as an alternative action (performed, > +for example, by right-clicking on the icon). > + > > * Changes in Emacs 28.1 > > diff --git a/etc/emacs-mail.desktop b/etc/emacs-mail.desktop > index 0c5fab1dd1..e949b7f1ed 100644 > --- a/etc/emacs-mail.desktop > +++ b/etc/emacs-mail.desktop > @@ -1,12 +1,19 @@ > [Desktop Entry] > Categories=3DNetwork;Email; > Comment=3DGNU Emacs is an extensible, customizable text editor - and mor= e > -Exec=3Demacs -f message-mailto %u > -# If you prefer to use emacsclient, use this instead > -#Exec=3Demacsclient -e '(message-mailto "%u")' > +Exec=3Demacsclient --alternate-editor=3D --eval '(message-mailto "%u")' > Icon=3Demacs > Name=3DEmacs (Mail) > MimeType=3Dx-scheme-handler/mailto; > NoDisplay=3Dfalse > Terminal=3Dfalse > Type=3DApplication > +Actions=3Dnew-window;new-instance; > + > +[Desktop Action new-window] > +Name=3DNew Window > +Exec=3Demacsclient --alternate-editor=3D --create-frame --eval > '(message-mailto "%u")' > + > +[Desktop Action new-instance] > +Name=3DNew Instance > +Exec=3Demacs -f message-mailto %u > diff --git a/etc/emacs.desktop b/etc/emacs.desktop > index 2e6496e58c..d21bba0e10 100644 > --- a/etc/emacs.desktop > +++ b/etc/emacs.desktop > @@ -3,10 +3,19 @@ Name=3DEmacs > GenericName=3DText Editor > Comment=3DEdit text > > MimeType=3Dtext/english;text/plain;text/x-makefile;text/x-c++hdr;text/x-= c++src;text/x-chdr;text/x-csrc;text/x-java;text/x-moc;text/x-pascal;text/x-= tcl;text/x-tex;application/x-shellscript;text/x-c;text/x-c++; > -Exec=3Demacs %F > +Exec=3Demacsclient --alternate-editor=3D %F > Icon=3Demacs > Type=3DApplication > Terminal=3Dfalse > Categories=3DDevelopment;TextEditor; > StartupWMClass=3DEmacs > Keywords=3DText;Editor; > +Actions=3Dnew-window;new-instance; > + > +[Desktop Action new-window] > +Name=3DNew Window > +Exec=3Demacsclient --alternate-editor=3D --create-frame %F > + > +[Desktop Action new-instance] > +Name=3DNew Instance > +Exec=3Demacs %F > diff --git a/etc/emacsclient.desktop b/etc/emacsclient.desktop > deleted file mode 100644 > index 3feb83c729..0000000000 > --- a/etc/emacsclient.desktop > +++ /dev/null > @@ -1,12 +0,0 @@ > -[Desktop Entry] > -Name=3DEmacs (Client) > -GenericName=3DText Editor > -Comment=3DEdit text > > -MimeType=3Dtext/english;text/plain;text/x-makefile;text/x-c++hdr;text/x-= c++src;text/x-chdr;text/x-csrc;text/x-java;text/x-moc;text/x-pascal;text/x-= tcl;text/x-tex;application/x-shellscript;text/x-c;text/x-c++; > -Exec=3Demacsclient -c %F > -Icon=3Demacs > -Type=3DApplication > -Terminal=3Dfalse > -Categories=3DDevelopment;TextEditor; > -StartupWMClass=3DEmacsd > -Keywords=3DText;Editor; > -- > 2.31.1 > > > ------------------------------ > > Message: 36 > Date: Tue, 25 May 2021 14:44:30 -0700 > From: "Colin Woodbury" > To: "Stefan Monnier" > Cc: "Basil L. Contovounesios" , emacs-devel@gnu.org > Subject: Re: [PATCH] lisp/files.el: Add `file-name-set-extension` > Message-ID: <6ba4668c-9b39-40e0-a155-f7e583fd33b6@www.fastmail.com> > Content-Type: text/plain; charset=3D"utf-8" > > Thanks Stefan, I've revised the patch according to your suggestions (see > attached). I also revised the docstring. > > Thanks! > Colin > > On Tue, 25 May 2021, at 14:29, Stefan Monnier wrote: > > > That regex was borrowed directly from `string-trim`, to which I added > > > a `.`. You're right that the main motivation was to allow the caller > to pass > > > either `.foo` or `foo` as the extension and have either case work (ma= ny > > > languages do this). Leaving the other characters in the regex seemed > like > > > a sanitary thing to do, just in case they pass something bogus. > > > > File names can be used in different ways for different purposes. > > We don't have any good reason to think that a space or a newline at the > > end of a file name (or beginning of an extension) is "bogus". > > > > If such things occurred somewhat often and always in ways where they ar= e > > indeed undesirable, we could consider removing them (the tradeoff > > between occasional harm and frequent error-avoidance would be > > favorable), but here this is just asking for trouble with no benefit. > > > > > 1. Simplifying the regex to just include dots (and perhaps whitespace= ) > (i.e. trust the caller), or; > > > > Please do that. > > > > > 2. Expanding the logic to sanitize both ends of both arguments, (i.e. > don't trust the caller), or; > > > > I don't think we have any reason to think we should "sanitize" it. > > > > > 3. Adding error-throwing logic if malformed files or extensions are > given (i.e. warn the user). > > > > "Malformed" according to which standard? > > > > > > Stefan > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.gnu.org/archive/html/emacs-devel/attachments/20210525/65b29= 394/attachment.html > > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: file-name-set-extension.patch > Type: text/x-patch > Size: 1050 bytes > Desc: not available > URL: < > https://lists.gnu.org/archive/html/emacs-devel/attachments/20210525/65b29= 394/attachment.bin > > > > ------------------------------ > > Message: 37 > Date: Tue, 25 May 2021 15:40:34 -0700 > From: Alex Bochannek > To: Lars Ingebrigtsen > Cc: emacs-devel@gnu.org > Subject: Re: master eaf224f: Repad the Face header in Gnus > Message-ID: > Content-Type: text/plain; charset=3D"utf-8" > > Lars Ingebrigtsen writes: > > > Alex Bochannek writes: > > > >> OK, agreed. Do you want me to submit a patch to revert that code and t= he > >> tests? > > > > I think that might make sense, but I have no strong feelings about the > > matter. > > Here's a patch that reverts that code and the tests. > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: text/x-patch > Size: 5684 bytes > Desc: not available > URL: < > https://lists.gnu.org/archive/html/emacs-devel/attachments/20210525/43403= fd6/attachment.bin > > > -------------- next part -------------- > > -- > Alex. > > ------------------------------ > > Message: 38 > Date: Tue, 25 May 2021 15:43:54 -0700 > From: Alex Bochannek > To: Lars Ingebrigtsen > Cc: emacs-devel@gnu.org > Subject: Re: master eaf224f: Repad the Face header in Gnus > Message-ID: > Content-Type: text/plain > > Alex Bochannek writes: > > > --- a/lisp/gnus/gnus-util.el > > +++ b/lisp/gnus/gnus-util.el > > @@ -1,3 +1,4 @@ > > + > > ;;; gnus-util.el --- utility functions for Gnus -*- lexical-binding: > t; -*- > > That blank line is incorrect, of course. Not sure how that made it > through. Sorry about that. > > -- > Alex. > > > > ------------------------------ > > Message: 39 > Date: Wed, 26 May 2021 01:03:33 +0100 > From: Jo=C3=A3o T=C3=A1vora > To: Gregory Heytings > Cc: Daniel Mendler , Stefan Monnier > , Juri Linkov , > emacs-devel@gnu.org > Subject: Re: [PATCH] (icomplete-vertical-mode): Add support for > affixations and, annotations > Message-ID: <874keqfjje.fsf@gmail.com> > Content-Type: text/plain; charset=3Dutf-8 > > Gregory Heytings writes: > > > Hi Daniel and Jo=C3=A3o, > > > > I said in bug#48013 that I was working on this, but I was waiting for > > my copyright assignment to complete before sending patches. Anyway, > > apparently you've now taken this over, which is fine. Alas I have no > > time to look at what you did to send useful comments this week. > > > > Gregory > > I've done a bit more work on icomplete.el and after seeing the > discussion evolve, I agree with Daniel that it's better to keep those > two things orthogonal. > > So I've now published two branches: > > - scratch/icomplete-vertical-mode-improvements > > This makes icomplete-vertical-mode much nicer IMO. After removing the > rotation in the vertical mode and adding a highlight color it looks a > bit like Vertico (which I tried recently). If people like the > rotation in vertical mode, too, it's very easy to get it back. It > also adds the annotation capabilities using some of the code Daniel > originally submitted. > > Since you, Gregory, made icomplete-vertical-mode and you, Daniel, > worked on its annotation capabilities, I wish you'd both have a look. > Else I will test it for a few days and then push to master. There are > still a lot of edges to polish, and I may have introduced some bugs, > though hopefully not in the legacy non-vertical parts. > > - scratch/annotation-function-improvements > > This overhauls annotation-function and makes the C-h f and M-x > backends use it instead of affixation-function. It doesn't delete > affixation-function. > > It _may_ be useful, but I guess it's not the end of the > affixation-function thing anyway, and I don't any much more to > contribute at this point. > > Jo=C3=A3o > > > > > > > > ------------------------------ > > Message: 40 > Date: Tue, 25 May 2021 17:32:09 -0700 > From: Aaron Jensen > To: Alan Third , Aaron Jensen > , emacs-devel@gnu.org, YAMAMOTO Mitsuharu > > Subject: Re: macOS metal rendering engine in mac port > Message-ID: > < > CAHyO48y-WP-WJrdTh1dGoBsZYVyZ24TpJpAdZndw+pu-z8xzuw@mail.gmail.com> > Content-Type: text/plain; charset=3D"UTF-8" > > On Tue, May 25, 2021 at 9:31 AM Aaron Jensen > wrote: > > > > On Mon, May 24, 2021 at 2:01 AM Alan Third wrote: > > > > > > I think so. A lot of what people like (smooth scrolling, etc.) would > > > have to be removed. > > > > Weird, this has never worked for me, but maybe I've had it misconfigure= d > > > > > One more thing to try... > > > > > > modified src/nsterm.m > > > @@ -8376,7 +8376,13 @@ - (void)unfocusDrawingBuffer > > > NSTRACE ("[EmacsView unfocusDrawingBuffer]"); > > > > > > [NSGraphicsContext setCurrentContext:nil]; > > > - [self setNeedsDisplay:YES]; > > > + [surface releaseContext]; > > > + [[self layer] setContents:(id)[surface getSurface]]; > > > + [surface performSelectorOnMainThread:@selector (getContext) > > > + withObject:nil > > > + waitUntilDone:NO]; > > > + > > > + //[self setNeedsDisplay:YES]; > > > } > > > > > > > > > @@ -8513,11 +8519,11 @@ - (void)updateLayer > > > There's a private method, -[CALayer setContentsChanged], that w= e > > > could use to force it, but we shouldn't often get the same > > > surface twice in a row. */ > > > - [surface releaseContext]; > > > - [[self layer] setContents:(id)[surface getSurface]]; > > > - [surface performSelectorOnMainThread:@selector (getContext) > > > - withObject:nil > > > - waitUntilDone:NO]; > > > + // [surface releaseContext]; > > > + // [[self layer] setContents:(id)[surface getSurface]]; > > > + // [surface performSelectorOnMainThread:@selector (getContext) > > > + // withObject:nil > > > + // waitUntilDone:NO]; > > > } > > > #endif > > > > > > > > > All this does is reduce the time between us deciding we're done with > > > drawing and sending it off to VRAM (although it might not, I'm not > > > entirely sure when updateLayer gets called). > > > > > > I expect this to reduce frame rate, but perhaps it will improve input > > > lag a little. > > > > I don't know if it's something funky with my machine or not but I've > > noticed some stutters with this patch. As in, it appears to miss > > paints. I'll type a character and won't see it until I type something > > else. Is it possible that this patch could cause that? > > This stopped, so maybe it was something funky. So far, today, things > feel pretty good from a latency perspective. I haven't measured > anything yet. > > Thanks, > > Aaron > > > > ------------------------------ > > Message: 41 > Date: Wed, 26 May 2021 07:23:19 +0100 > From: Alan Third > To: Aaron Jensen > Cc: emacs-devel@gnu.org, YAMAMOTO Mitsuharu > > Subject: Re: macOS metal rendering engine in mac port > Message-ID: > Content-Type: text/plain; charset=3Dus-ascii > > On Tue, May 25, 2021 at 05:32:09PM -0700, Aaron Jensen wrote: > > On Tue, May 25, 2021 at 9:31 AM Aaron Jensen > wrote: > > > > > > I don't know if it's something funky with my machine or not but I've > > > noticed some stutters with this patch. As in, it appears to miss > > > paints. I'll type a character and won't see it until I type something > > > else. Is it possible that this patch could cause that? > > > > This stopped, so maybe it was something funky. So far, today, things > > feel pretty good from a latency perspective. I haven't measured > > anything yet. > > It probably could, I've seen something similar when I was testing > something or other. It will be bypassing the viewWillDraw code that > forces a redisplay, but I think in theory we shouldn't need it with > this code. > > Oh, I suppose that might break the live resizing. But we can work that > out if so. > -- > Alan Third > > > > ------------------------------ > > Message: 42 > Date: Tue, 25 May 2021 23:26:55 -0700 > From: Aaron Jensen > To: Alan Third , Aaron Jensen > , emacs-devel@gnu.org, YAMAMOTO Mitsuharu > > Subject: Re: macOS metal rendering engine in mac port > Message-ID: > Pu9Lu3d2M98a-sn23XVLA@mail.gmail.com> > Content-Type: text/plain; charset=3D"UTF-8" > > On Tue, May 25, 2021 at 11:23 PM Alan Third wrote: > > > > It probably could, I've seen something similar when I was testing > > something or other. It will be bypassing the viewWillDraw code that > > forces a redisplay, but I think in theory we shouldn't need it with > > this code. > > > > Oh, I suppose that might break the live resizing. But we can work that > > out if so. > > Live resizing? I don't see the flicker and if I drag to resize it > remains painted usually. I did see it flash white once. And I think > I've perhaps seen it blank one time today briefly, but I don't > remember what I was doing. > > > > ------------------------------ > > Message: 43 > Date: Wed, 26 May 2021 09:34:11 +0200 > From: Andreas Schwab > To: "Colin Woodbury" > Cc: "Stefan Monnier" , "Basil L. > Contovounesios" , emacs-devel@gnu.org > Subject: Re: [PATCH] lisp/files.el: Add `file-name-set-extension` > Message-ID: <87czteeyoc.fsf@igel.home> > Content-Type: text/plain > > On Mai 25 2021, Colin Woodbury wrote: > > > +Returns nil if either of the FILENAME or EXTENSION are nil before > > +dot consolidation, or empty afterwards." > > + (when (and filename extension) > > I still don't see any reason to allow nil. A file name is always a > string. > > Andreas. > > -- > Andreas Schwab, schwab@linux-m68k.org > GPG Key fingerprint =3D 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC= 1 > "And now for something completely different." > > > > ------------------------------ > > Message: 44 > Date: Wed, 26 May 2021 00:35:36 -0700 > From: Aaron Jensen > To: Alan Third , Aaron Jensen > , emacs-devel@gnu.org, YAMAMOTO Mitsuharu > > Subject: Re: macOS metal rendering engine in mac port > Message-ID: > ZbAry3CAzmeUgPtpz0GKmmxuh+QFSbQDpFA@mail.gmail.com> > Content-Type: text/plain; charset=3D"UTF-8" > > On Tue, May 25, 2021 at 11:26 PM Aaron Jensen > wrote: > > > > On Tue, May 25, 2021 at 11:23 PM Alan Third wrote: > > > > > > It probably could, I've seen something similar when I was testing > > > something or other. It will be bypassing the viewWillDraw code that > > > forces a redisplay, but I think in theory we shouldn't need it with > > > this code. > > > > > > Oh, I suppose that might break the live resizing. But we can work tha= t > > > out if so. > > > > Live resizing? I don't see the flicker and if I drag to resize it > > remains painted usually. I did see it flash white once. And I think > > I've perhaps seen it blank one time today briefly, but I don't > > remember what I was doing. > > Just did some latency measurements with emacs -Q (my previous ones > were w/ my config) > > emacs27-drawing branch: 79.2 62.5 75.0 70.4 (71.775 avg) > emacs28 surface-stuff branch: 66.7 66.7 75.0 70.8 (69.8 avg) > emacs28 surface-stuff branch+last patch: 70.8 75.0 66.7 62.5 (68.75 avg) > > Those are similar, if not slightly better than iterm2 latency on my > machine, so that's probably pretty good. The margin of error is going > to be pretty high on those, so I can't definitely say that 28 is > faster. > > The scroll-up-benchmark w/o the patch is slightly better from my > limited testing (4.9s vs 5.2s). > > Aaron > > > > ------------------------------ > > Message: 45 > Date: Wed, 26 May 2021 10:49:09 +0200 > From: Robert Pluim > To: Peter Oliver > Cc: emacs-devel@gnu.org > Subject: Re: GUI X-FreeDesktop integration > Message-ID: <87eedt518a.fsf@gmail.com> > Content-Type: text/plain; charset=3Dutf-8 > > >>>>> On Tue, 25 May 2021 22:34:18 +0100 (BST), Peter Oliver < > p.d.oliver@mavit.org.uk> said: > > Peter> On Sunday 16th May, Robin Tarsiger wrote: > >> In fact, the _least_ surprising from > >> an XDG/FDO perspective would actually be to _only_ expose > >> a "client+autolaunch" desktop entry and just call that the > >> point of integration for Emacs. > > Peter> Agreed. Attached is a patch which achieves this. > > I don=CA=BCt object to this approach, but I have a couple of points: > > - If the user hasn't enabled the server, then this starts emacs in > daemon mode, which needs to be documented somewhere, possibly in > the .desktop file > - Can you document that enabling the server is a pre-requisite > (modulo the daemon behaviour)? > > Robert > -- > > > > ------------------------------ > > Message: 46 > Date: Wed, 26 May 2021 15:21:05 +0530 > From: Anand Tamariya > To: Eli Zaretskii > Cc: emacs-devel@gnu.org > Subject: Re: Unicode combining characters > Message-ID: > 2owO5XBpV9-iMavfRxRVySuATkCzcZ+_p84M+BQ@mail.gmail.com> > Content-Type: text/plain; charset=3D"utf-8" > > Thanks Eli - align-to 'space' display spec seems helpful. > > Though it's a company specific issue related to unicode character > composition, here's some more details on the issue for record should > somebody else stumble upon the same. > > Let's call the first character in the screenshot as shr (single glyph) an= d > the second one as sh-r (two glyphs). > (setq shr (string 2358 2381 2352)) > (setq sh-r (string 2358 2352)) > > (string-width shr) ;; 2 > (string-width sh-r) ;; 2 > > To create the rectangular region, we need to pad the strings with > appropriate number of spaces. align-to 'space' display spec seems helpful > in this case as shown below. You will notice that character "a" is aligne= d > in both cases. Now I need to figure out how to use the same within compan= y. > > (insert (concat shr > (let ((sp " ")) > (font-lock-append-text-property 0 1 'display `(space . (:align-to 10)) s= p) > sp) > "a")) > > (insert (concat sh-r > (let ((sp " ")) > (font-lock-append-text-property 0 1 'display `(space . (:align-to 10)) s= p) > sp) > "a")) > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.gnu.org/archive/html/emacs-devel/attachments/20210526/b3286= 557/attachment.html > > > > ------------------------------ > > Message: 47 > Date: Wed, 26 May 2021 12:04:39 +0200 > From: Joost Kremers > To: emacs-devel@gnu.org > Subject: Re: Unicode combining characters > Message-ID: <874kepiz6i.fsf@fastmail.fm> > Content-Type: text/plain > > > On Wed, May 26 2021, Anand Tamariya wrote: > > Thanks Eli - align-to 'space' display spec seems helpful. > > > > Though it's a company specific issue related to unicode character > > composition, here's some more details on the issue for record should > > somebody else stumble upon the same. > > At the risk of posting something irrelevant: the effect shown in the > screen shot > you posted also occurs if you use company in a buffer with > variable-pitch-mode > (which I do in e.g., LaTeX buffers). I don't know if that's the same > problem, > but if it is, a solution would be applicable beyond combining characters. > > -- > Joost Kremers > Life has its moments > > > > ------------------------------ > > Message: 48 > Date: Wed, 26 May 2021 14:59:44 +0300 > From: Eli Zaretskii > To: Karl Fogel > Cc: orontee@gmail.com, drew.adams@oracle.com, larsi@gnus.org, > monnier@iro.umontreal.ca, emacs-devel@gnu.org > Subject: Re: [External] : Re: [PATCH] When deleting in bookmark menu, > prompt for confirmation. > Message-ID: <837djlbt8v.fsf@gnu.org> > > > From: Karl Fogel > > Cc: orontee@gmail.com, drew.adams@oracle.com, larsi@gnus.org, > > monnier@iro.umontreal.ca, emacs-devel@gnu.org > > Date: Tue, 25 May 2021 15:24:44 -0500 > > > > >Given what you wrote, and what bookmark-load does with the prefix > > >argument, I think it is better to say that explicitly in > > >bookmark-bmenu-load's doc string, since you only need a single > > >quite > > >simple sentence to say that, whereas the doc strong of > > >bookmark-load > > >is quite long. > > > > Well, now that I've done it, I think your way is an improvement -- > > although it turned out to be slightly more doc change than I > > expected. Revised patch attached for review. > > LGTM, thanks. > > > > ------------------------------ > > Message: 49 > Date: Wed, 26 May 2021 13:14:23 +0100 (BST) > From: Peter Oliver > To: emacs-devel@gnu.org > Subject: Re: GUI X-FreeDesktop integration > Message-ID: > <573eb311-e0f6-2216-4298-458ae8ab827b@froglet.home.mavit.org.uk> > Content-Type: text/plain; charset=3D"iso8859-7"; Format=3D"flowed" > > On Tue, 25 May 2021, Peter Oliver wrote: > > > On Sunday 16th May, Robin Tarsiger wrote: > > > >> In fact, the _least_ surprising from > >> an XDG/FDO perspective would actually be to _only_ expose > >> a "client+autolaunch" desktop entry and just call that the > >> point of integration for Emacs. > > > > Agreed. Attached is a patch which achieves this. > > After a bit more testing, I discovered a snag. > > I believe that the default behaviour when opening a file from a desktop= =E2=80=99s > file manager should be to open it in an existing GUI frame if one exists, > or a new GUI frame if one does not. Clicking Emacs in a desktop=E2=80=99= s > application launcher should open a new GUI frame. > > The trouble is that, if Emacs is running as a daemon with no frames, > `emacsclient /path/to/foo` will create a new TTY frame rather than a GUI > frame. Should this behaviour be changed so that a GUI frame is preferred > if $DISPLAY is set? While we=E2=80=99re here, should we report an error = if there > is no display and no TTY? > > -- > Peter Oliver > > ------------------------------ > > Message: 50 > Date: Wed, 26 May 2021 15:19:22 +0300 > From: Eli Zaretskii > To: Peter Oliver > Cc: emacs-devel@gnu.org > Subject: Re: GUI X-FreeDesktop integration > Message-ID: <8335u9bsc5.fsf@gnu.org> > > > Date: Tue, 25 May 2021 22:34:18 +0100 (BST) > > From: Peter Oliver > > > > > In fact, the _least_ surprising from > > > an XDG/FDO perspective would actually be to _only_ expose > > > a "client+autolaunch" desktop entry and just call that the > > > point of integration for Emacs. > > > > Agreed. Attached is a patch which achieves this. > > This is a backward-incompatible change, so why should it be the > default, and not the alternative action via right-click? And anyway, > wouldn't some people be surprised to see emacsclient frame when they > expected a new instance of Emacs, without their say-so? > > > > ------------------------------ > > Message: 51 > Date: Wed, 26 May 2021 15:54:43 +0300 > From: Eli Zaretskii > To: Anand Tamariya > Cc: emacs-devel@gnu.org > Subject: Re: Unicode combining characters > Message-ID: <83v975ac4s.fsf@gnu.org> > > > From: Anand Tamariya > > Date: Wed, 26 May 2021 15:21:05 +0530 > > Cc: emacs-devel@gnu.org > > > > Let's call the first character in the screenshot as shr (single glyph) > and the second one as sh-r (two glyphs). > > (setq shr (string 2358 2381 2352)) > > (setq sh-r (string 2358 2352)) > > > > (string-width shr) ;; 2 > > (string-width sh-r) ;; 2 > > Sorry, it turns out I've misremembered: string-width doesn't account > for "automatic compositions", the ones that happen due to > composition-function-table (as opposed to "static compositions" which > happen due to the 'composition' text property). So this case > currently cannot be handled correctly by string-width; we should fix > that. > > > > ------------------------------ > > Message: 52 > Date: Wed, 26 May 2021 21:57:22 +0800 > From: Ihor Radchenko > To: Jean Louis > Cc: Christopher Dimech , emacs-devel@gnu.org > Subject: Re: Cycling first N heading levels in outline > Message-ID: <87o8cxy4vx.fsf@localhost> > Content-Type: text/plain > > Jean Louis writes: > > > Especially for Org users the outline-minor-mode is universal and gives > > similar concepts of outline in various other modes: > > Thanks for pointing this out. A long time ago, before I knew about > outline-minor-mode, I started using hideshow package with similar > functionality. Now, comparing the two, I can see how outline-minor-mode > can be sometimes better (not always though). > > > - editing Emacs Lisp? Fold levels, sections, functions and open it. It > > gives visual index of functions, it becomes very easy to move them > > from place to place; > > outline-minor-mode is definitely very nice when handling Elisp file > sections. Yet, it unfortunately cannot fold sexps inside functions > independently, unlike hideshow (correct me if I am wrong). I ended up > using both outline-minor-mode and hs-minor-mode for the time being. The > former for folding top-level defuns and comments and the latter for > folding sexps inside defuns. > > Best, > Ihor > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Emacs-devel mailing list > Emacs-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/emacs-devel > > ------------------------------ > > End of Emacs-devel Digest, Vol 207, Issue 32 > ******************************************** > --=20 Fragen sind nicht da um beantwortet zu werden, Fragen sind da um gestellt zu werden Georg Kreisler --000000000000861e9605c3c50b1a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Message: 50
> Date: Wed, 26 May 2021 15:19:22 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> To: Peter Oliver <p.d.ol= iver@mavit.org.uk>
> Cc: emacs-devel@gnu.org
> Subject: Re: GUI X-FreeDesktop integratio= n
> Message-ID: <8335u9b= sc5.fsf@gnu.org>

>> Date: Tue, 25 May 2021 22:34:18 +0100 (BST)
>> From: Peter Oliver <= p.d.oliver@mavit.org.uk>
>>
>> > In fact, the _least_ surprising from
>> > an XDG/FDO perspective would actually be to _only_ expose
>> > a "client+autolaunch" desktop entry and just call t= hat the
>> > point of integration for Emacs.
>>
>> Agreed.=C2=A0 Attached is a patch which achieves this.

>This is a backward-incompatible change, so why should it be the
>default, and not the alternative action via right-click?=C2=A0 And anyw= ay,
>wouldn't some people be surprised to see emacsclient frame when the= y
>expected a new instance of Emacs, without their say-so?
=
I was ;-)

/Pedro A.
=
On Wed= , 26 May 2021 at 18:05, <= emacs-devel-request@gnu.org> wrote:
Send Emacs-devel mailing list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 emacs-devel@gnu.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://lists.gnu.org/= mailman/listinfo/emacs-devel
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 emacs-devel-request@gnu.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 emacs-devel-owner@gnu.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Emacs-devel digest..."


Today's Topics:

=C2=A0 =C2=A01. Re: macOS metal rendering engine in mac port (Aaron Jensen)=
=C2=A0 =C2=A02. Re: [PATCH] (icomplete-vertical-mode): Add support for
=C2=A0 =C2=A0 =C2=A0 affixations and, annotations (Juri Linkov)
=C2=A0 =C2=A03. Re: [PATCH] (icomplete-vertical-mode): Add support for
=C2=A0 =C2=A0 =C2=A0 affixations and, annotations (Juri Linkov)
=C2=A0 =C2=A04. Re: Unicode combining characters (Stefan Monnier)
=C2=A0 =C2=A05. Re: Unicode combining characters (Eli Zaretskii)
=C2=A0 =C2=A06. Re: [PATCH] (icomplete-vertical-mode): Add support for
=C2=A0 =C2=A0 =C2=A0 affixations and, annotations (Stefan Monnier)
=C2=A0 =C2=A07. Re: macOS metal rendering engine in mac port (Eli Zaretskii= )
=C2=A0 =C2=A08. Re: [PATCH] (icomplete-vertical-mode): Add support for
=C2=A0 =C2=A0 =C2=A0 affixations and, annotations (Jo=C3=A3o T=C3=A1vora) =C2=A0 =C2=A09. Re: Emacs is not reproducible (Stefan Monnier)
=C2=A0 10. Cycling first N heading levels in outline (Christopher Dimech) =C2=A0 11. Re: [PATCH] (icomplete-vertical-mode): Add support for
=C2=A0 =C2=A0 =C2=A0 affixations and, annotations (Jo=C3=A3o T=C3=A1vora) =C2=A0 12. Re: macOS metal rendering engine in mac port (Aaron Jensen)
=C2=A0 13. Re: [PATCH] lisp/files.el: Add `file-name-set-extension`
=C2=A0 =C2=A0 =C2=A0 (Andreas Schwab)
=C2=A0 14. Re: Emacs is not reproducible (T.V Raman)
=C2=A0 15. Re: [PATCH] lisp/files.el: Add `file-name-set-extension`
=C2=A0 =C2=A0 =C2=A0 (Basil L. Contovounesios)
=C2=A0 16. Re: Emacs is not reproducible (Glenn Morris)
=C2=A0 17. Re: Unicode combining characters (Cl=C3=A9ment Pit-Claudel)
=C2=A0 18. Re: Emacs is not reproducible (Basil L. Contovounesios)
=C2=A0 19. Re: Unicode combining characters (Eli Zaretskii)
=C2=A0 20. Re: Unicode combining characters (Cl=C3=A9ment Pit-Claudel)
=C2=A0 21. Re: master eaf224f: Repad the Face header in Gnus
=C2=A0 =C2=A0 =C2=A0 (Lars Ingebrigtsen)
=C2=A0 22. Re: [PATCH] lisp/files.el: Add `file-name-set-extension`
=C2=A0 =C2=A0 =C2=A0 (Colin Woodbury)
=C2=A0 23. Re: Unicode combining characters (Eli Zaretskii)
=C2=A0 24. Re: [PATCH] lisp/files.el: Add `file-name-set-extension`
=C2=A0 =C2=A0 =C2=A0 (Colin Woodbury)
=C2=A0 25. Re: macOS metal rendering engine in mac port (Alan Third)
=C2=A0 26. Re: [PATCH] (icomplete-vertical-mode): Add support for
=C2=A0 =C2=A0 =C2=A0 affixations and, annotations (Stefan Monnier)
=C2=A0 27. Re: [External] : Re: [PATCH] When deleting in bookmark menu,
=C2=A0 =C2=A0 =C2=A0 prompt for confirmation. (Karl Fogel)
=C2=A0 28. Re: [PATCH] lisp/files.el: Add `file-name-set-extension`
=C2=A0 =C2=A0 =C2=A0 (Stefan Monnier)
=C2=A0 29. Re: [PATCH] (icomplete-vertical-mode): Add support for
=C2=A0 =C2=A0 =C2=A0 affixations and, annotations (Dmitry Gutov)
=C2=A0 30. Re: [PATCH] (icomplete-vertical-mode): Add support for
=C2=A0 =C2=A0 =C2=A0 affixations and, annotations (Juri Linkov)
=C2=A0 31. Re: [PATCH] (icomplete-vertical-mode): Add support for
=C2=A0 =C2=A0 =C2=A0 affixations and, annotations (Jo=C3=A3o T=C3=A1vora) =C2=A0 32. Re: [ELPA?] Controlling Isearch from the minibuffer (Juri Linkov= )
=C2=A0 33. Re: [PATCH] lisp/files.el: Add `file-name-set-extension`
=C2=A0 =C2=A0 =C2=A0 (Colin Woodbury)
=C2=A0 34. Re: [PATCH] lisp/files.el: Add `file-name-set-extension`
=C2=A0 =C2=A0 =C2=A0 (Stefan Monnier)
=C2=A0 35. Re: GUI X-FreeDesktop integration (Peter Oliver)
=C2=A0 36. Re: [PATCH] lisp/files.el: Add `file-name-set-extension`
=C2=A0 =C2=A0 =C2=A0 (Colin Woodbury)
=C2=A0 37. Re: master eaf224f: Repad the Face header in Gnus (Alex Bochanne= k)
=C2=A0 38. Re: master eaf224f: Repad the Face header in Gnus (Alex Bochanne= k)
=C2=A0 39. Re: [PATCH] (icomplete-vertical-mode): Add support for
=C2=A0 =C2=A0 =C2=A0 affixations and, annotations (Jo=C3=A3o T=C3=A1vora) =C2=A0 40. Re: macOS metal rendering engine in mac port (Aaron Jensen)
=C2=A0 41. Re: macOS metal rendering engine in mac port (Alan Third)
=C2=A0 42. Re: macOS metal rendering engine in mac port (Aaron Jensen)
=C2=A0 43. Re: [PATCH] lisp/files.el: Add `file-name-set-extension`
=C2=A0 =C2=A0 =C2=A0 (Andreas Schwab)
=C2=A0 44. Re: macOS metal rendering engine in mac port (Aaron Jensen)
=C2=A0 45. Re: GUI X-FreeDesktop integration (Robert Pluim)
=C2=A0 46. Re: Unicode combining characters (Anand Tamariya)
=C2=A0 47. Re: Unicode combining characters (Joost Kremers)
=C2=A0 48. Re: [External] : Re: [PATCH] When deleting in bookmark menu,
=C2=A0 =C2=A0 =C2=A0 prompt for confirmation. (Eli Zaretskii)
=C2=A0 49. Re: GUI X-FreeDesktop integration (Peter Oliver)
=C2=A0 50. Re: GUI X-FreeDesktop integration (Eli Zaretskii)
=C2=A0 51. Re: Unicode combining characters (Eli Zaretskii)
=C2=A0 52. Re: Cycling first N heading levels in outline (Ihor Radchenko)

----------------------------------------------------------------------

Message: 1
Date: Tue, 25 May 2021 09:31:16 -0700
From: Aaron Jensen <aaronjensen@gmail.com>
To: Alan Third <ala= n@idiocy.org>, Aaron Jensen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <aaronjensen@gmail.com>, emacs-devel@gnu.org, YAMAMOTO Mitsuharu =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mituharu@math.s.chiba-u.ac.jp>
Subject: Re: macOS metal rendering engine in mac port
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <CAHyO48y-V= e+gjPxdt+hbPcXwFLA5LFvuccah_-SaPa6dvk67Bw@mail.gmail.com>
Content-Type: text/plain; charset=3D"UTF-8"

On Mon, May 24, 2021 at 2:01 AM Alan Third <alan@idiocy.org> wrote:
>
> I think so. A lot of what people like (smooth scrolling, etc.) would > have to be removed.

Weird, this has never worked for me, but maybe I've had it misconfigure= d

> One more thing to try...
>
> modified=C2=A0 =C2=A0src/nsterm.m
> @@ -8376,7 +8376,13 @@ - (void)unfocusDrawingBuffer
>=C2=A0 =C2=A0 NSTRACE ("[EmacsView unfocusDrawingBuffer]"); >
>=C2=A0 =C2=A0 [NSGraphicsContext setCurrentContext:nil];
> -=C2=A0 [self setNeedsDisplay:YES];
> +=C2=A0 [surface releaseContext];
> +=C2=A0 [[self layer] setContents:(id)[surface getSurface]];
> +=C2=A0 [surface performSelectorOnMainThread:@selector (getContext) > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 withObject:nil
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0waitUntilDone:NO];
> +
> +=C2=A0 //[self setNeedsDisplay:YES];
>=C2=A0 }
>
>
> @@ -8513,11 +8519,11 @@ - (void)updateLayer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0There's a private method, -[CALayer setC= ontentsChanged], that we
>=C2=A0 =C2=A0 =C2=A0 =C2=A0could use to force it, but we shouldn't = often get the same
>=C2=A0 =C2=A0 =C2=A0 =C2=A0surface twice in a row.=C2=A0 */
> -=C2=A0 [surface releaseContext];
> -=C2=A0 [[self layer] setContents:(id)[surface getSurface]];
> -=C2=A0 [surface performSelectorOnMainThread:@selector (getContext) > -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 withObject:nil
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0waitUntilDone:NO];
> +=C2=A0 // [surface releaseContext];
> +=C2=A0 // [[self layer] setContents:(id)[surface getSurface]];
> +=C2=A0 // [surface performSelectorOnMainThread:@selector (getContext)=
> +=C2=A0 //=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0withObject:nil
> +=C2=A0 //=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 waitUntilDone:NO];
>=C2=A0 }
>=C2=A0 #endif
>
>
> All this does is reduce the time between us deciding we're done wi= th
> drawing and sending it off to VRAM (although it might not, I'm not=
> entirely sure when updateLayer gets called).
>
> I expect this to reduce frame rate, but perhaps it will improve input<= br> > lag a little.

I don't know if it's something funky with my machine or not but I&#= 39;ve
noticed some stutters with this patch. As in, it appears to miss
paints. I'll type a character and won't see it until I type somethi= ng
else. Is it possible that this patch could cause that?

Thanks,

Aaron



------------------------------

Message: 2
Date: Tue, 25 May 2021 19:53:00 +0300
From: Juri Linkov <= juri@linkov.net>
To: Jo=C3=A3o T=C3=A1vora <joaotavora@gmail.com>
Cc: Daniel Mendler <mail@daniel-mendler.de>,=C2=A0 emacs-devel@gnu.org,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 monnier@iro.umontreal.ca
Subject: Re: [PATCH] (icomplete-vertical-mode): Add support for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 affixations and, annotations
Message-ID: <87mtsibwjz.fsf@mail.linkov.net>
Content-Type: text/plain

> I've seen this in read-extended-command--affixation.el indeed. I d= on't
> understand:
>
> - the need for this window switch, but I might be missing something; > - if the need is to process in the same buffer, why one switches
>=C2=A0 =C2=A0windows;

It can switch buffers instead of selecting windows.

> - why it can't and shouldn't be done in the funcall locus by t= he frontend
>=C2=A0 =C2=A0(in this case minibuffer-completion-help)

Because this requirement is specific only to read-extended-command--affixat= ion,
other uses might require other buffers to be current, so this doesn't r= emove
the argument for having the affixation-function.

> But if they exercise this freedom fully they're going to break the=
> layout of the frontend, like icomplete.el, which potentially does layo= ut
> calculations.=C2=A0 Probably company.el or any other frontend is the s= ame.
> So not so much holding hands, more like saving feet from being shot :-= ).

For many years we allowed the users to shoot themselves in the foot,
and yet nobody did it :-)

With the existing function 'display-sort-function' you can easily add new elements to the list of completions or remove the existing
candidates.=C2=A0 And that is not a problem in practice.



------------------------------

Message: 3
Date: Tue, 25 May 2021 19:59:25 +0300
From: Juri Linkov <= juri@linkov.net>
To: Jo=C3=A3o T=C3=A1vora <joaotavora@gmail.com>
Cc: Daniel Mendler <mail@daniel-mendler.de>,=C2=A0 "emacs-devel@gnu.org"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <emacs-devel@gnu.org>,=C2=A0 monnier@iro.umontreal.ca,=C2=A0 Dmi= try Gutov
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <dgutov@yandex.ru>
Subject: Re: [PATCH] (icomplete-vertical-mode): Add support for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 affixations and, annotations
Message-ID: <87tumq92pe.fsf@mail.linkov.net>
Content-Type: text/plain

> I have no strong feelings on plist, versus alist, versus propertized > string, versus object, versus whatever.=C2=A0 Just slightly strong fee= lings
> as to the fundamental mission of this function which is to do
> annotation/affixation/whatchacallit, not filtering or reordering.
>
> For reasons of "forward compatibility", as you called them, = which is the
> ability for newer backends to work on older Emacs that don't under= stand
> these new things, if that work is done in `annotation-function` then i= t
> needs to use propertized strings.=C2=A0 But if it's done in a new = thing, say
> called decoration-function, it doesn't.

As I said a month ago, while affixation-function was an improvement over annotation-function, it's still not perfect.=C2=A0 I welcome a better A= PI function,
but OTOH adding prefix/suffix text properties on the annotation strings
is not an improvement.

> To clarify, the analog in some markup format is specifying something a= s
> "emphasis" and then the renderer usually decides that bold i= f it can, or
> surround it in asterisks.=C2=A0 But the markup format doesn't usua= lly say
> "bold".=C2=A0 For the same reasons, what you're now call= ing "columns" should
> probably be referred to as "fields" or something equivalentl= y agnostic
> as to the format in which they are display.

While looking for an analog, a better analogy would be the classic
MVC architecture:

- M: data comes from the list of completion strings;
- V: render functions like completion--insert-* or icomplete-completions; - C: API callers that provide metadata functions that specify
=C2=A0 how to process data for displaying, e.g. they define display-sort-fu= nction
=C2=A0 where the prefix 'display-' hints that it affects the view,<= br> =C2=A0 so the frontend has no own choice how to sort completions.

Following such pattern, affixation-function could return more fields
(e.g. when completions-format is customized to the value 'multi-column&= #39;)
in the same format as tabulated-list (and an indication in which column
there are completion candidates) for the frontend to display in columns.


------------------------------

Message: 4
Date: Tue, 25 May 2021 13:22:25 -0400
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Anand Tamariya <atamariya@gmail.com>
Cc: emacs-devel@gn= u.org
Subject: Re: Unicode combining characters
Message-ID: <jwvo8cysp8x.fsf-monnier+emacs@gnu.org>
Content-Type: text/plain

> Hindi Devanagari script has lot of unicode combining characters which<= br> > results in misalignment in a rectangular overlay for constant number o= f
> characters=C2=A0 (screenshot )
> <https://1.bp.blogspot.com/-P2ZnFePOpOo/YK= 0cNJ4B5II/AAAAAAAAJJs/t-MADtxUeps3S_WXZ_rFWjf9daH49sr9QCLcBGAsYHQ/s421/comb= ining.png>
> What would be a recommended way to tackle this in Emacs?

In a GUI session, the usual answer is to use posframe, AFAIK.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Stefan




------------------------------

Message: 5
Date: Tue, 25 May 2021 20:24:15 +0300
From: Eli Zaretskii <e= liz@gnu.org>
To: Anand Tamariya <atamariya@gmail.com>
Cc: emacs-devel@gn= u.org
Subject: Re: Unicode combining characters
Message-ID: <83k0nmbubk.fsf@gnu.org>

> From: Anand Tamariya <atamariya@gmail.com>
> Date: Tue, 25 May 2021 21:26:44 +0530
>
> Hindi Devanagari script has lot of unicode combining characters which = results in misalignment in a
> rectangular overlay for constant number of characters (screenshot ) > What would be a recommended way to tackle this in Emacs?

Use align-to 'space' display spec and/or the window-text-pixel-size=
function, which will account for the actual size of the text on
display.=C2=A0 string-width can also be used, but it only gives an
approximation, as it is oblivious of the actual size of the font
glyphs.



------------------------------

Message: 6
Date: Tue, 25 May 2021 13:24:42 -0400
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Juri Linkov <ju= ri@linkov.net>
Cc: Jo=C3=A3o T=C3=A1vora <joaotavora@gmail.com>,=C2=A0 Daniel Mendler
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mail@daniel-mendler.de>,=C2=A0 emacs-devel@gnu.org
Subject: Re: [PATCH] (icomplete-vertical-mode): Add support for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 affixations and, annotations
Message-ID: <jwvim36sp6v.fsf-monnier+emacs@gnu.org>
Content-Type: text/plain

> With the existing function 'display-sort-function' you can eas= ily
> add new elements to the list of completions or remove the existing
> candidates.=C2=A0 And that is not a problem in practice.

Indeed.=C2=A0 I think we should aim for an API that's easy to use corre= ctly.
If it makes incorrect uses difficult, that's good, but that shouldn'= ;t be
the driving goal.

If you want to make incorrect uses hard or even impossible, there are
dependently typed programming languages for that ;-)


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Stefan




------------------------------

Message: 7
Date: Tue, 25 May 2021 20:34:19 +0300
From: Eli Zaretskii <e= liz@gnu.org>
To: Aaron Jensen <aaronjensen@gmail.com>
Cc: emacs-devel@gn= u.org, alan@idiocy= .org,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mituharu@math.s.chiba-u.ac.jp
Subject: Re: macOS metal rendering engine in mac port
Message-ID: <83h7iqbtus.fsf@gnu.org>

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Tue, 25 May 2021 08:35:42 -0700
> Cc: emacs-dev= el@gnu.org, Alan Third <alan@idiocy.org>,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp= >
>
> > The 17% is about twice what I'd expect, since adding 3 charac= ters to
> > each line of xdisp.c enlarges its text by only 9.3%.
>
> Pure guess here, but it's also making a lot of empty lines non-emp= ty
> (14% more). Perhaps that has an added cost somehow?

Not AFAIU, but I had so many surprises in this investigation that I no
longer believe in my intuition.=C2=A0 So who knows, maybe you are right.
> > How did you compile Emacs? which compiler and what compiler and l= inker
> > switches?=C2=A0 And what kind of CPU do you have there?=C2=A0 I&#= 39;m looking for
> > something that could explain why parts of code that should take l= ike
> > 20% of the total redisplay time are so dominant in your case.
>
> clang, with -O2. Specifically these configure flags:
>
> CFLAGS=3D"-g3 -O2" \
> --disable-silent-rules \
> --with-xml2 \
> --with-gnutls \
> --without-dbus \
> --with-imagemagick \
> --with-modules \
> --with-rsvg \
> --with-ns \
> --disable-ns-self-contained
>
>
> This CPU: Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz

So you have 16 execution units, but a relatively slow clock.=C2=A0 Hmm...
> > Alan, do you see similar numbers (in percents) to what Aaron repo= rts?
> > Or is that something peculiar to his system?
>
> What I get depends on frame size and whether or not I'm using
> nativecomp or Alan's branch or master. I just a test with a smalle= r
> frame size (on Alan's branch this time, just happens to be what I = have
> built) and saw 5.58 vs 6.8s: 22%. But then I ran the bench again w/ > line numbers and couldn't get it below 7.2s, so there's quite = a bit of
> variability in the test runs.

FWIW, in my case, the default frame size (~37 lines) and a maximized
frame produce the same timings here.



------------------------------

Message: 8
Date: Tue, 25 May 2021 18:40:45 +0100
From: Jo=C3=A3o T=C3=A1vora <joaotavora@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Juri Linkov <ju= ri@linkov.net>,=C2=A0 Daniel Mendler
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mail@daniel-mendler.de>, emacs-devel@gnu.org
Subject: Re: [PATCH] (icomplete-vertical-mode): Add support for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 affixations and, annotations
Message-ID: <87pmxeg19e.fsf@gmail.com>
Content-Type: text/plain; charset=3Dutf-8

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> With the existing function 'display-sort-function' you can= easily
>> add new elements to the list of completions or remove the existing=
>> candidates.=C2=A0 And that is not a problem in practice.
> Indeed.=C2=A0 I think we should aim for an API that's easy to use = correctly.
> If it makes incorrect uses difficult, that's good, but that should= n't be
> the driving goal.

I see, broken windows.=C2=A0 You keep asking for good API's but when th= ings
are proposed in that direction "that's good" but doesn't = matter.

I'm not exactly a fan of d-s-f, but likelyhood that it messes up is les= s
since it's likely called unconditionally on all returned completions by=
the frontend.=C2=A0 Indeed I wonder why d-s-f exists at all.

As to the current shape affixation-function, I'm not mortally against i= t
just that its misdesign is a bit jarring, but so are so many other parts of the completion system, so I guess, broken windows.=C2=A0 It's just t= hat
this is supposed to be a new part.

Jo=C3=A3o





------------------------------

Message: 9
Date: Tue, 25 May 2021 13:41:17 -0400
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Glenn Morris <rgm@g= nu.org>
Cc: emacs-devel@gn= u.org
Subject: Re: Emacs is not reproducible
Message-ID: <jwv7djmsogi.fsf-monnier+emacs@gnu.org>
Content-Type: text/plain

Glenn Morris [2021-05-23 19:52:08] wrote:
> Stefan Monnier wrote:
>>> There has been changes made in the past to fix some problems.<= br> >>> I have a pending patch in bug#46502 (see below) which aims to = fix some
>>> more of those problems, but still haven't heard confirmati= on that it
>>> helps.
> I did 10 builds with -j8; 5 without your patch and 5 with.
> The builds without your patch had changes in 12, 10, 9, 11 elc files.<= br> > The builds with your patch had changes in 4, 4, 7, 4 elc files.

Thanks for confirming what I was seeing.=C2=A0 I pushed the patch to `maste= r`.

> Mostly tramp.elc, ox-odt.elc, ox.elc, cc-mode.elc; sometimes in
> eieio files. At least some of these seem to be https://debbugs.gnu= .org/34322

The mystery for those remains,

> So it seems better in terms of less elc variation.
> It causes all tests in test/lisp/cedet/semantic-utest-ia.el to fail.
I'm indeed looking at it,


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Stefan




------------------------------

Message: 10
Date: Tue, 25 May 2021 19:41:12 +0200
From: Christopher Dimech <dimech@gmx.com>
To: K=C3=A9vin Le Gouguec <kevin.legouguec@gmail.com>
Cc: Stefan Monnier <monnier@iro.umontreal.ca>, Ihor Radchenko
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <yantar92@gmail.com>, Jean Louis <bugs@gnu.support>= ;,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 emacs-devel@gnu.org
Subject: Cycling first N heading levels in outline
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <trinity-7081abb3-2fb9-477c-9af7-ca5d5658a08= d-1621964471853@3c-app-mailcom-bs01>

Content-Type: text/plain; charset=3DUTF-8

I need some help on how to use "outline-minor-mode-highlight" opt= ion to customize
the colours for headings because they are showing up as normal comments.
I am in emacs-lisp-mode.


> Sent: Monday, May 24, 2021 at 10:57 PM
> From: "K=C3=A9vin Le Gouguec" <kevin.legouguec@gmail.com>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: "Stefan Monnier" <monnier@iro.umontreal.ca>, "Ihor Rad= chenko" <ya= ntar92@gmail.com>, "Jean Louis" <bugs@gnu.support>, = emacs-devel@gnu.or= g
> Subject: Re: Cycling first N heading levels in outline
>
> Christopher Dimech <dimech@gmx.com> writes:
>
> >> The convention used in ELisp is:
> >>
> >>=C2=A0 =C2=A0 ;;; Section
> >>=C2=A0 =C2=A0 ;;;; Subsection
> >>=C2=A0 =C2=A0 ;;;;; Subsubsection
> >>=C2=A0 =C2=A0 ;;;;;; Subsubsubsection
> >>=C2=A0 =C2=A0 ;;;;;;; Subsubsubsubsection
> >>=C2=A0 =C2=A0 [...]
> >
> > The headings still look like comments, whereas they are supposed = to get highlighted
> > according to the heading level.
> >
> > Could we get that to work in said way?
>
> On Emacs master, the outline-minor-mode-highlight option allows you to=
> customize how headings are fontified:
>
> > When t, it puts outline faces only if there are no major mode=E2= =80=99s faces
> > on headings.=C2=A0 When =E2=80=98override=E2=80=99, it completely= overwrites major mode=E2=80=99s
> > faces with outline faces.=C2=A0 When =E2=80=98append=E2=80=99, it= tries to append outline
> > faces to major mode=E2=80=99s faces.
>



------------------------------

Message: 11
Date: Tue, 25 May 2021 18:46:07 +0100
From: Jo=C3=A3o T=C3=A1vora <joaotavora@gmail.com>
To: Juri Linkov <ju= ri@linkov.net>
Cc: Daniel Mendler <mail@daniel-mendler.de>,=C2=A0 "emacs-devel@gnu.org"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <emacs-devel@gnu.org>,=C2=A0 monnier@iro.umontreal.ca,=C2=A0 Dmi= try Gutov
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <dgutov@yandex.ru>
Subject: Re: [PATCH] (icomplete-vertical-mode): Add support for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 affixations and, annotations
Message-ID: <87lf82g10g.fsf@gmail.com>
Content-Type: text/plain; charset=3Dutf-8

Juri Linkov <juri@l= inkov.net> writes:

> As I said a month ago, while affixation-function was an improvement ov= er
> annotation-function, it's still not perfect.=C2=A0 I welcome a bet= ter API function,
> but OTOH adding prefix/suffix text properties on the annotation string= s
> is not an improvement.

Sure it's not beautiful, but it's an improvement to annotation-func= tion.
If affixation-function were a function of a single completion, it would
be fine.=C2=A0 For a hint at a good design, look at the language server
protocol.=C2=A0 It returns a large list of completions, and then you can "resolve" a completion to get many more of its properties.=C2=A0 = So
resolution-function is an option.

> Following such pattern, affixation-function could return more fields > (e.g. when completions-format is customized to the value 'multi-co= lumn')
> in the same format as tabulated-list (and an indication in which colum= n
> there are completion candidates) for the frontend to display in
> columns.

If you prefer to see it that way, I have no objection, though I prefer
to think of backend and frontend simply (i.e. your C doesn't match
anything here very accurately).

Jo=C3=A3o





------------------------------

Message: 12
Date: Tue, 25 May 2021 10:48:09 -0700
From: Aaron Jensen <aaronjensen@gmail.com>
To: Eli Zaretskii <eli= z@gnu.org>
Cc: emacs-devel@gn= u.org, Alan Third <alan@idiocy.org>,=C2=A0 YAMAMOTO
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
Subject: Re: macOS metal rendering engine in mac port
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <CAHyO48xPo2T= wFixRCwsmonzMk03TZZYRT9WRX+BVQS6Dpkx6rg@mail.gmail.com>
Content-Type: text/plain; charset=3D"UTF-8"

On Tue, May 25, 2021 at 10:34 AM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > This CPU: Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz
>
> So you have 16 execution units, but a relatively slow clock.=C2=A0 Hmm= ...

It's a laptop, so the low clock is power saving. It has turbo boost to<= br> 5GHz, though thermally I don't think I can actually hit that for very long, if at all. But at least 4.3GHz or so.



------------------------------

Message: 13
Date: Tue, 25 May 2021 19:48:25 +0200
From: Andreas Schwab <schwab@linux-m68k.org>
To: "Colin Woodbury" <colin@fosskers.ca>
Cc: emacs-devel@gn= u.org
Subject: Re: [PATCH] lisp/files.el: Add `file-name-set-extension`
Message-ID: <87r1hu3dsm.fsf@igel.home>
Content-Type: text/plain

On Mai 25 2021, Colin Woodbury wrote:

> diff --git a/lisp/files.el b/lisp/files.el
> index 62e1702fdf..f8aefa7930 100644
> --- a/lisp/files.el
> +++ b/lisp/files.el
> @@ -4889,6 +4889,20 @@ extension, the value is \"\"." >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (if period
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "")))))
>=C2=A0
> +(defun file-name-set-extension (filename extension)
> +=C2=A0 "Change the extension of a FILENAME to EXTENSION.
> +Sanitizes the input to consolidate leading/trailing dots.
> +
> +Returns `nil' if either of the FILENAME or EXTENSION are `nil'= ;
> +before sanitizing, or empty afterwards."
> +=C2=A0 (when (and filename extension)

What is the use-case for nil?

Andreas.

--
Andreas Schwab, = schwab@linux-m68k.org
GPG Key fingerprint =3D 7578 EB47 D4E5 4D69 2510=C2=A0 2552 DF73 E780 A9DA = AEC1
"And now for something completely different."



------------------------------

Message: 14
Date: Tue, 25 May 2021 10:52:35 -0700
From: "T.V Raman" <raman@google.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Glenn Morris <rgm@g= nu.org>,=C2=A0 emacs-devel@gnu.org
Subject: Re: Emacs is not reproducible
Message-ID: <p91o8cy1z18.fsf@google.com>
Content-Type: text/plain; charset=3Dgb18030

Stefan Monnier <monnier@iro.umontreal.ca> writes:


This may or may not be related --- but I reported a few months ago that
compiling emacspeak with make -j 4 resulted in unpredictable behavior -- I got rid of the parallel build and problems went away.

1. There were no warnings during the parallel build.

2. Things were "weird" in that some advice definitions were not a= ctive,
=C2=A0 =C2=A0reloading files fixed it.

I decided to keep life simple at that point and got rid of the parallel
build.
> Glenn Morris [2021-05-23 19:52:08] wrote:
>> Stefan Monnier wrote:
>>>> There has been changes made in the past to fix some proble= ms.
>>>> I have a pending patch in bug#46502 (see below) which aims= to fix some
>>>> more of those problems, but still haven't heard confir= mation that it
>>>> helps.
>> I did 10 builds with -j8; 5 without your patch and 5 with.
>> The builds without your patch had changes in 12, 10, 9, 11 elc fil= es.
>> The builds with your patch had changes in 4, 4, 7, 4 elc files. >
> Thanks for confirming what I was seeing.=C2=A0 I pushed the patch to `= master`.
>
>> Mostly tramp.elc, ox-odt.elc, ox.elc, cc-mode.elc; sometimes in >> eieio files. At least some of these seem to be https://debbugs= .gnu.org/34322
>
> The mystery for those remains,
>
>> So it seems better in terms of less elc variation.
>> It causes all tests in test/lisp/cedet/semantic-utest-ia.el to fai= l.
>
> I'm indeed looking at it,
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Stefan
>
>

--

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
=E2=99=88 Id: kg:/m/0285kf1=C2=A0 =F0=9F=A6=AE



------------------------------

Message: 15
Date: Tue, 25 May 2021 19:00:44 +0100
From: "Basil L. Contovounesios" <contovob@tcd.ie>
To: "Colin Woodbury" <colin@fosskers.ca>
Cc: emacs-devel@gn= u.org
Subject: Re: [PATCH] lisp/files.el: Add `file-name-set-extension`
Message-ID: <= 87lf82y9pv.fsf@tcd.ie>
Content-Type: text/plain

"Colin Woodbury" <colin@fosskers.ca> writes:

> +=C2=A0 =C2=A0 (let* ((patt "[ \\t\\n\\r.]+") ; Borrowed fro= m `string-trim'.

Those backslashes need escaping only in string-trim's docstring, not in=
the literal regexp string.

Thanks,

--
Basil



------------------------------

Message: 16
Date: Tue, 25 May 2021 14:03:52 -0400
From: Glenn Morris <rgm= @gnu.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gn= u.org
Subject: Re: Emacs is not reproducible
Message-ID: <w0y2c2g06v.fsf@fencepost.gnu.org>
Content-Type: text/plain


>> It causes all tests in test/lisp/cedet/semantic-utest-ia.el to fai= l.

FTR, I should have said "four", not "all".



------------------------------

Message: 17
Date: Tue, 25 May 2021 14:15:33 -0400
From: Cl=C3=A9ment Pit-Claudel <cpitclaudel@gmail.com>
To: emacs-devel@gn= u.org
Subject: Re: Unicode combining characters
Message-ID: <2437db42-62fc-ea3c-279b-170152defc62@gmail.com= >
Content-Type: text/plain; charset=3Dutf-8

On 5/25/21 1:24 PM, Eli Zaretskii wrote:
>> From: Anand Tamariya <atamariya@gmail.com>
>> Date: Tue, 25 May 2021 21:26:44 +0530
>>
>> Hindi Devanagari script has lot of unicode combining characters wh= ich results in misalignment in a
>> rectangular overlay for constant number of characters (screenshot = )
>> What would be a recommended way to tackle this in Emacs?
>
> Use align-to 'space' display spec and/or the window-text-pixel= -size
> function, which will account for the actual size of the text on
> display.

Will this work? The misaligned specs are already part of a replacing dipspl= ay spec, so the additional align-to would be ignored, no?

(IIRC, there is no way to say "replace this text by this string follow= ed by this specified space; it's one or the other, right?)



------------------------------

Message: 18
Date: Tue, 25 May 2021 19:27:24 +0100
From: "Basil L. Contovounesios" <contovob@tcd.ie>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Glenn Morris <rgm@g= nu.org>,=C2=A0 emacs-devel@gnu.org
Subject: Re: Emacs is not reproducible
Message-ID: <= 87r1huwtwz.fsf@tcd.ie>
Content-Type: text/plain; charset=3Dutf-8

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Glenn Morris [2021-05-23 19:52:08] wrote:
>> Stefan Monnier wrote:
>>>> There has been changes made in the past to fix some proble= ms.
>>>> I have a pending patch in bug#46502 (see below) which aims= to fix some
>>>> more of those problems, but still haven't heard confir= mation that it
>>>> helps.
>> I did 10 builds with -j8; 5 without your patch and 5 with.
>> The builds without your patch had changes in 12, 10, 9, 11 elc fil= es.
>> The builds with your patch had changes in 4, 4, 7, 4 elc files. >
> Thanks for confirming what I was seeing.=C2=A0 I pushed the patch to `= master`.
>
>> So it seems better in terms of less elc variation.
>> It causes all tests in test/lisp/cedet/semantic-utest-ia.el to fai= l.
>
> I'm indeed looking at it,

FYI if those test failures prove too boring there are some new and
exciting bootstrap warnings to play with too :).

In end of data:
calc/calc.el:3126:27: Warning: the function =E2=80=98math-compare=E2=80=99 = is not known to be
=C2=A0 =C2=A0 defined.
calc/calc.el:2805:27: Warning: the function =E2=80=98math-zerop=E2=80=99 is= not known to be
=C2=A0 =C2=A0 defined.
In tramp-handle-access-file:
net/tramp.el:3238:43: Warning: attempt to inline =E2=80=98tramp-error=E2=80= =99 before it was
=C2=A0 =C2=A0 defined
net/tramp.el:3238:43: Warning: attempt to inline =E2=80=98tramp-error=E2=80= =99 before it was
=C2=A0 =C2=A0 defined

Thanks,

--
Basil



------------------------------

Message: 19
Date: Tue, 25 May 2021 21:39:50 +0300
From: Eli Zaretskii <e= liz@gnu.org>
To: Cl=C3=A9ment Pit-Claudel <cpitclaudel@gmail.com>
Cc: emacs-devel@gn= u.org
Subject: Re: Unicode combining characters
Message-ID: <83cztebqtl.fsf@gnu.org>
Content-Type: text/plain; charset=3Dutf-8

> From: Cl=C3=A9ment Pit-Claudel <cpitclaudel@gmail.com>
> Date: Tue, 25 May 2021 14:15:33 -0400
>
> On 5/25/21 1:24 PM, Eli Zaretskii wrote:
> >> From: Anand Tamariya <atamariya@gmail.com>
> >> Date: Tue, 25 May 2021 21:26:44 +0530
> >>
> >> Hindi Devanagari script has lot of unicode combining characte= rs which results in misalignment in a
> >> rectangular overlay for constant number of characters (screen= shot )
> >> What would be a recommended way to tackle this in Emacs?
> >
> > Use align-to 'space' display spec and/or the window-text-= pixel-size
> > function, which will account for the actual size of the text on > > display.
>
> Will this work? The misaligned specs are already part of a replacing d= ipsplay spec, so the additional align-to would be ignored, no?

I don't understand, but maybe you know about the particular use case more than I do.=C2=A0 I just mentioned two devices that can be accurate to<= br> 1 pixel wrt to the X coordinate.

> (IIRC, there is no way to say "replace this text by this string f= ollowed by this specified space; it's one or the other, right?)

Again, I don't think I follow.=C2=A0 If you have "this text",= you can
calculate its width on display, and then know how many pixels of white
space you will need after "this string" replaces that text.=C2=A0= So,
unless I'm missing something, specifying the space width is redundant,<= br> and actually makes a solvable problem unsolvable.

But I might be talking nonsense because I don't understand what
problem the OP wants to solve.



------------------------------

Message: 20
Date: Tue, 25 May 2021 15:30:21 -0400
From: Cl=C3=A9ment Pit-Claudel <cpitclaudel@gmail.com>
To: Eli Zaretskii <eli= z@gnu.org>
Cc: emacs-devel@gn= u.org
Subject: Re: Unicode combining characters
Message-ID: <3e40bcd1-3d04-23c0-37a7-6a283ca4e3e4@gmail.com= >
Content-Type: text/plain; charset=3Dutf-8

On 5/25/21 2:39 PM, Eli Zaretskii wrote:
>> From: Cl=C3=A9ment Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Tue, 25 May 2021 14:15:33 -0400
>>
>> On 5/25/21 1:24 PM, Eli Zaretskii wrote:
>>>> From: Anand Tamariya <atamariya@gmail.com>
>>>> Date: Tue, 25 May 2021 21:26:44 +0530
>>>>
>>>> Hindi Devanagari script has lot of unicode combining chara= cters which results in misalignment in a
>>>> rectangular overlay for constant number of characters (scr= eenshot )
>>>> What would be a recommended way to tackle this in Emacs? >>>
>>> Use align-to 'space' display spec and/or the window-te= xt-pixel-size
>>> function, which will account for the actual size of the text o= n
>>> display.
>>
>> Will this work? The misaligned specs are already part of a replaci= ng dipsplay spec, so the additional align-to would be ignored, no?
>
> I don't understand, but maybe you know about the particular use ca= se
> more than I do.=C2=A0 I just mentioned two devices that can be accurat= e to
> 1 pixel wrt to the X coordinate.
>
>> (IIRC, there is no way to say "replace this text by this stri= ng followed by this specified space; it's one or the other, right?)
>
> Again, I don't think I follow.=C2=A0 If you have "this text&q= uot;, you can
> calculate its width on display, and then know how many pixels of white=
> space you will need after "this string" replaces that text.= =C2=A0 So,
> unless I'm missing something, specifying the space width is redund= ant,
> and actually makes a solvable problem unsolvable.

Based on the screenshot this is an issue with Company.=C2=A0 Company displa= ys its "pop-ups" by putting a replacing 'display property on = the text following the point (and on the next few lines).=C2=A0 So if the b= uffer contains

ABC XYZ DEF GHI
JKL MNO PQR STU

and the point is after XYZ, then company puts a replacing display spec from= " DEF" to "STU".
To display completions "XYZ1233" and "XYZ456", the repl= acing display spec contains "123| GHI\nJKL XYZ456| STU", so the f= inal display is

ABC XYZ123| GHI
JKL XYZ456| STU

The OP's issue is that "123" and "456" don't ha= ve the same length.=C2=A0 As far as I know, there is no way to add extra sp= ace after 123 or 456 so that they reach the same X coordinate, given that t= hey are already part of a display spec.

Cl=C3=A9ment.



------------------------------

Message: 21
Date: Tue, 25 May 2021 21:31:58 +0200
From: Lars Ingebrigtsen <larsi@gnus.org>
To: Alex Bochannek <alex@bochannek.com>
Cc: emacs-devel@gn= u.org
Subject: Re: master eaf224f: Repad the Face header in Gnus
Message-ID: <871r9upq35.fsf@gnus.org>
Content-Type: text/plain

Alex Bochannek <= alex@bochannek.com> writes:

> OK, agreed. Do you want me to submit a patch to revert that code and t= he
> tests?

I think that might make sense, but I have no strong feelings about the
matter.

--
(domestic pets only, the antidote for overdose, milk.)
=C2=A0 =C2=A0bloggy blog: http://lars.ingebrigtsen.no



------------------------------

Message: 22
Date: Tue, 25 May 2021 12:42:05 -0700
From: "Colin Woodbury" <colin@fosskers.ca>
To: "Andreas Schwab" <schwab@linux-m68k.org>
Cc: emacs-devel@gn= u.org
Subject: Re: [PATCH] lisp/files.el: Add `file-name-set-extension`
Message-ID: <c915ee30-8c7e-41a3-aad7-51d296c82bb0@www.fa= stmail.com>
Content-Type: text/plain; charset=3D"utf-8"

Hi Andreas,

`nil` seemed more appropriate than returning either an empty string or thro= wing an error. The intent is to signal a failure in general, as it looks li= ke other related functions in that file do.

On Tue, 25 May 2021, at 10:48, Andreas Schwab wrote:
> On Mai 25 2021, Colin Woodbury wrote:
>
> > diff --git a/lisp/files.el b/lisp/files.el
> > index 62e1702fdf..f8aefa7930 100644
> > --- a/lisp/files.el
> > +++ b/lisp/files.el
> > @@ -4889,6 +4889,20 @@ extension, the value is \"\".&qu= ot;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (if period
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "")))))=
> >=C2=A0
> > +(defun file-name-set-extension (filename extension)
> > +=C2=A0 "Change the extension of a FILENAME to EXTENSION. > > +Sanitizes the input to consolidate leading/trailing dots.
> > +
> > +Returns `nil' if either of the FILENAME or EXTENSION are `ni= l'
> > +before sanitizing, or empty afterwards."
> > +=C2=A0 (when (and filename extension)
>
> What is the use-case for nil?
>
> Andreas.
>
> --
> Andreas Schwab, schwab@linux-m68k.org <mailto:schwab%40linux-m68k.org>
> GPG Key fingerprint =3D 7578 EB47 D4E5 4D69 2510=C2=A0 2552 DF73 E780 = A9DA AEC1
> "And now for something completely different."
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnu.org/archive/html/emacs-devel/attachments/20210525/e7d4c5= 32/attachment.html>

------------------------------

Message: 23
Date: Tue, 25 May 2021 22:44:29 +0300
From: Eli Zaretskii <e= liz@gnu.org>
To: Cl=C3=A9ment Pit-Claudel <cpitclaudel@gmail.com>
Cc: emacs-devel@gn= u.org
Subject: Re: Unicode combining characters
Message-ID: <83a6oibntu.fsf@gnu.org>
Content-Type: text/plain; charset=3Dutf-8

> Cc: emacs-dev= el@gnu.org
> From: Cl=C3=A9ment Pit-Claudel <cpitclaudel@gmail.com>
> Date: Tue, 25 May 2021 15:30:21 -0400
>
> Based on the screenshot this is an issue with Company.=C2=A0 Company d= isplays its "pop-ups" by putting a replacing 'display propert= y on the text following the point (and on the next few lines).=C2=A0 So if = the buffer contains
>
> ABC XYZ DEF GHI
> JKL MNO PQR STU
>
> and the point is after XYZ, then company puts a replacing display spec= from " DEF" to "STU".
> To display completions "XYZ1233" and "XYZ456", the= replacing display spec contains "123| GHI\nJKL XYZ456| STU", so = the final display is
>
> ABC XYZ123| GHI
> JKL XYZ456| STU
>
> The OP's issue is that "123" and "456" don'= ;t have the same length.=C2=A0 As far as I know, there is no way to add ext= ra space after 123 or 456 so that they reach the same X coordinate, given t= hat they are already part of a display spec.

First, the OP said "overlay", and overlay strings can have displa= y
properties.

And second, I'd expect the current code to use string-width to compute<= br> how much whitespace will be needed after each completion candidate,
and string-width already accounts for composed (a.k.a "combined")=
characters.=C2=A0 Yes, string-width provides only an approximation for the<= br> true pixel width of the string, but that's not specific to
compositions, and the whole technique is somewhat of a kludge anyway,
for this reason and others.



------------------------------

Message: 24
Date: Tue, 25 May 2021 12:45:58 -0700
From: "Colin Woodbury" <colin@fosskers.ca>
To: "Basil L. Contovounesios" <contovob@tcd.ie>
Cc: emacs-devel@gn= u.org
Subject: Re: [PATCH] lisp/files.el: Add `file-name-set-extension`
Message-ID: <c4eef0ed-3ae1-4c54-a967-674e73ac5774@www.fa= stmail.com>
Content-Type: text/plain; charset=3D"utf-8"

Thank you, you're right. I've tested the old and revised code, and = the double backslash wasn't neccesary.

I've attached the revised patch.

On Tue, 25 May 2021, at 11:00, Basil L. Contovounesios wrote:
> "Colin Woodbury" <colin@fosskers.ca <mailto:colin%40fosskers.ca>> writes: >
> > +=C2=A0 =C2=A0 (let* ((patt "[ \\t\\n\\r.]+") ; Borrowe= d from `string-trim'.
>
> Those backslashes need escaping only in string-trim's docstring, n= ot in
> the literal regexp string.
>
> Thanks,
>
> --
> Basil
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnu.org/archive/html/emacs-devel/attachments/20210525/4b16c1= 11/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: file-name-set-extension.patch
Type: text/x-patch
Size: 1045 bytes
Desc: not available
URL: <= https://lists.gnu.org/archive/html/emacs-devel/attachments/20210525/4b16c11= 1/attachment.bin>

------------------------------

Message: 25
Date: Tue, 25 May 2021 14:50:14 +0100
From: Alan Third <a= lan@idiocy.org>
To: Eli Zaretskii <eli= z@gnu.org>
Cc: aaronjensen@= gmail.com, ema= cs-devel@gnu.org
Subject: Re: macOS metal rendering engine in mac port
Message-ID: <YK0AlmpL+MOWymV3@breton.holly.idiocy.org>
Content-Type: text/plain; charset=3Dus-ascii

On Tue, May 25, 2021 at 04:47:41PM +0300, Eli Zaretskii wrote:
> > Date: Tue, 25 May 2021 14:34:37 +0100
> > From: Alan Third <alan@idiocy.org>
> > Cc: aa= ronjensen@gmail.com, emacs-devel@gnu.org
> >
> > FWIW, on the Mac I see a slightly smaller performance penalty wit= h
> > display-line-numbers-mode, around 18%.
>
> Is that an optimized build or unoptimized?=C2=A0 In my tests with opti= mized
> builds, line numbers add about 10% to 12% to the scroll benchmark.
> Unoptimized code shows almost no effect: around 2%.

In both cases the default, so -O2.
--
Alan Third



------------------------------

Message: 26
Date: Tue, 25 May 2021 16:01:14 -0400
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Jo=C3=A3o T=C3=A1vora <joaotavora@gmail.com>
Cc: Juri Linkov <ju= ri@linkov.net>,=C2=A0 Daniel Mendler
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mail@daniel-mendler.de>, emacs-devel@gnu.org
Subject: Re: [PATCH] (icomplete-vertical-mode): Add support for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 affixations and, annotations
Message-ID: <jwvpmxer4mo.fsf-monnier+emacs@gnu.org>
Content-Type: text/plain

> I see, broken windows.=C2=A0 You keep asking for good API's but wh= en things
> are proposed in that direction "that's good" but doesn&#= 39;t matter.

[ Remember that the whole design of Emacs and ELisp goes against the
=C2=A0 usual software engineering practice of using encapsulation and
=C2=A0 abstraction to modularize the code so that one part can't mess w= ith
=C2=A0 the other.

=C2=A0 Instead, Emacs's idea of empowering users means that for one par= t to
=C2=A0 be able to mess with another is considered a feature rather than
=C2=A0 a bug, and the "abstraction boundaries" are enforced by co= nventions
=C2=A0 rather than by technical means.

=C2=A0 As a dependent-types kinda guy, I sometimes find it odd as well, but=
=C2=A0 I think it has served Emacs surprisingly well, so I tend to try and<= br> =C2=A0 keep following the same design, despite my natural leaning
=C2=A0 against it.=C2=A0 ]

> As to the current shape affixation-function, I'm not mortally agai= nst it
> just that its misdesign is a bit jarring, but so are so many other par= ts
> of the completion system, so I guess, broken windows.=C2=A0 It's j= ust that
> this is supposed to be a new part.

The part of `affixation-function` which I find problematic is the fact
that it does the layout itself, whereas I think it would be better to do it in the UI (so it can choose to use columns or not, to put it at the
beginning or at the end, etc...).

The fact that it takes a whole list rather than a single element is more in the "bikeshedcolor" category for me.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Stefan




------------------------------

Message: 27
Date: Tue, 25 May 2021 15:24:44 -0500
From: Karl Fogel <kfogel@red-bean.com>
To: Eli Zaretskii <eli= z@gnu.org>
Cc: orontee@gmail.co= m,=C2=A0 dre= w.adams@oracle.com,=C2=A0 larsi@gnus.org,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 monnier@iro.umontreal.ca,=C2=A0 emacs-devel@gnu.org
Subject: Re: [External] : Re: [PATCH] When deleting in bookmark menu,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 prompt for confirmation.
Message-ID: <87fsyatvcj.fsf@red-bean.com>
Content-Type: text/plain; charset=3D"utf-8"; Format=3D"flowe= d"

On 25 May 2021, Eli Zaretskii wrote:
>> From: Karl Fogel <kfogel@red-bean.com>
>> Cc: orontee= @gmail.com,=C2=A0 drew.adams@oracle.com,=C2=A0 larsi@gnus.org,
>>=C2=A0 =C2=A0monnier@iro.umontreal.ca,=C2=A0 emacs-devel@gnu.org
>> Date: Tue, 25 May 2021 00:38:22 -0500
>>
>> >> Thoughts?
>> >
>> >I'll have thoughts when I see the result ;-)
>>
>> Heh, fair enough.=C2=A0 My inquiry was about the general practice = of
>> having one function's doc string referring out to another
>> function's.
>
>It depends on what you need to say, thus my response above.
>
>Given what you wrote, and what bookmark-load does with the prefix
>argument, I think it is better to say that explicitly in
>bookmark-bmenu-load's doc string, since you only need a single
>quite
>simple sentence to say that, whereas the doc strong of
>bookmark-load
>is quite long.

Well, now that I've done it, I think your way is an improvement --
although it turned out to be slightly more doc change than I
expected.=C2=A0 Revised patch attached for review.

Best regards,
-Karl

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 0001-Improve-some-doc-strings-in-bookmark.el.patch
URL: <= https://lists.gnu.org/archive/html/emacs-devel/attachments/20210525/d4a44b4= 9/attachment.ksh>

------------------------------

Message: 28
Date: Tue, 25 May 2021 16:25:38 -0400
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: "Colin Woodbury" <colin@fosskers.ca>
Cc: "Basil L. Contovounesios" <contovob@tcd.ie>,=C2=A0 emacs-devel@gnu.org
Subject: Re: [PATCH] lisp/files.el: Add `file-name-set-extension`
Message-ID: <jwveedur2cl.fsf-monnier+emacs@gnu.org>
Content-Type: text/plain

> +=C2=A0 (when (and filename extension)
> +=C2=A0 =C2=A0 (let* ((patt "[ \t\n\r.]+") ; Inspired by `st= ring-trim'.
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(filename (string-trim-right= filename patt))
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(extension (string-trim-left= extension patt)))
> +=C2=A0 =C2=A0 =C2=A0 (unless (or (string-empty-p filename)
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (strin= g-empty-p extension))
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 (concat (file-name-sans-extension filenam= e) "." extension)))))

Why do you trim [ \t\n\r.]+ from the end of the filename and the
beginning of the extension?

I can see why you'd want to remove a single "." at the beginn= ing of
`extension`, so as to allow extension to come with or without a leading
".", but the rest seems rather surprising because such characters= in my
experience almost never show up in such a circumstance (which means
that if they do, it's either on purpose and we should preserve it, or it's an error "upstream" and we should try and help expose th= e error
rather than silently try to cover it).


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Stefan




------------------------------

Message: 29
Date: Tue, 25 May 2021 23:27:36 +0300
From: Dmitry Gutov <dgutov@yandex.ru>
To: Stefan Monnier <monnier@iro.umontreal.ca>, Jo=C3=A3o T=C3=A1vora
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <joaotavora@gmail.com>
Cc: Juri Linkov <ju= ri@linkov.net>, Daniel Mendler
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mail@daniel-mendler.de>, emacs-devel@gnu.org
Subject: Re: [PATCH] (icomplete-vertical-mode): Add support for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 affixations and, annotations
Message-ID: <9d551b41-1559-b707-c3c0-61dbb055f148@yandex.ru= >
Content-Type: text/plain; charset=3Dutf-8; format=3Dflowed

On 25.05.2021 23:01, Stefan Monnier wrote:
> The fact that it takes a whole list rather than a single element is mo= re
> in the "bikeshedcolor" category for me.

=C2=A0From where I'm standing, this color of the bike shed would make i= t
harder to use (if I ever found a way to support it in Company, that is).
If affixation-function returns a list including extra data, I will then have to convert it to some structure that allows lookup by completion
string (e.g. a hash table), and then pass that table on to the place the completions are rendered.

display-sort-function is different, because you can use it in one place, have your list re-sorted, and then go on with the rendering of the
resulting collection. It doesn't force me to do any extra accounting.


------------------------------

Message: 30
Date: Tue, 25 May 2021 23:37:43 +0300
From: Juri Linkov <= juri@linkov.net>
To: Jo=C3=A3o T=C3=A1vora <joaotavora@gmail.com>
Cc: Daniel Mendler <mail@daniel-mendler.de>,=C2=A0 "emacs-devel@gnu.org"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <emacs-devel@gnu.org>,=C2=A0 monnier@iro.umontreal.ca,=C2=A0 Dmi= try Gutov
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <dgutov@yandex.ru>
Subject: Re: [PATCH] (icomplete-vertical-mode): Add support for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 affixations and, annotations
Message-ID: <87y2c24lww.fsf@mail.linkov.net>
Content-Type: text/plain

> Sure it's not beautiful, but it's an improvement to annotation= -function.
> If affixation-function were a function of a single completion, it woul= d
> be fine.=C2=A0 For a hint at a good design, look at the language serve= r
> protocol.=C2=A0 It returns a large list of completions, and then you c= an
> "resolve" a completion to get many more of its properties.= =C2=A0 So
> resolution-function is an option.

resolution-function sounds good.=C2=A0 Maybe this is not the most
suitable comparison but since you mentioned the word "resolve" that evoked by association: resolver functions used in GraphQL.



------------------------------

Message: 31
Date: Tue, 25 May 2021 21:46:43 +0100
From: Jo=C3=A3o T=C3=A1vora <joaotavora@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Juri Linkov <ju= ri@linkov.net>,=C2=A0 Daniel Mendler
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mail@daniel-mendler.de>, emacs-devel@gnu.org
Subject: Re: [PATCH] (icomplete-vertical-mode): Add support for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 affixations and, annotations
Message-ID: <87fsyafsng.fsf@gmail.com>
Content-Type: text/plain; charset=3Dutf-8

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I see, broken windows.=C2=A0 You keep asking for good API's bu= t when things
>> are proposed in that direction "that's good" but doe= sn't matter.
>
> [ Remember that the whole design of Emacs and ELisp goes against the >=C2=A0 =C2=A0usual software engineering practice of using encapsulation= and
>=C2=A0 =C2=A0abstraction to modularize the code so that one part can= 9;t mess with
>=C2=A0 =C2=A0the other.

No it doesn't :-) At least I don't design Lisp (Elisp or CL) system= s
that way (or Ruby or JS, for more examples).=C2=A0 Encapsulation or
abstraction aren't property of a specific language.=C2=A0 Elisp can'= ;t
strictly enforce many things the way a C++ compiler refuses to compile,
but that doesn't mean there aren't a bunch of compile-time and run-= time
assertions, much less that they are are useless.=C2=A0 Among many examples,=
just because Emacs Lisp uses a shared symbol namespace (sigh...) hasn't=
stopped us from making the '--' convention or, say, carefully decid= ing
if a variable name should end in "-functions" or "-function&= quot;.=C2=A0 This is
nor bikeshedding for me, it's a daily part of design.

>=C2=A0 =C2=A0Instead, Emacs's idea of empowering users means that f= or one part to
>=C2=A0 =C2=A0be able to mess with another is considered a feature rathe= r than
>=C2=A0 =C2=A0a bug, and the "abstraction boundaries" are enfo= rced by conventions
>=C2=A0 =C2=A0rather than by technical means.

By both.=C2=A0 There's always a way to subvert API intent by the progra= mmer.
That's fine, but it doesn't mean it should be easy to.=C2=A0 Pretty= sure one
can frobnicate the order of the candidates in a single-arg annotation
function, but it's going to be a lot more code.

Jo=C3=A3o







------------------------------

Message: 32
Date: Tue, 25 May 2021 23:50:27 +0300
From: Juri Linkov <= juri@linkov.net>
To: Augusto Stoffel <arstoffel@gmail.com>
Cc: emacs-devel@gn= u.org
Subject: Re: [ELPA?] Controlling Isearch from the minibuffer
Message-ID: <87wnrm35d8.fsf@mail.linkov.net>
Content-Type: text/plain

>> Now, I took a closer look at the history of changes around lazy >> highlight and the interactions with other features seems very tric= ky.
>> I'm not super confident about the patch I'm attaching, but= if you are
>> willing to review it and test a bit, I hope it helps.
>
> Everything looks right, but this needs more testing before pushing.
Testing revealed some problems:

1. After enabling isearch-lazy-count, modes that use lazy-highligh,
=C2=A0 =C2=A0such as e.g. query-replace displays the isearch message
=C2=A0 =C2=A0overwriting query-replace prompt.=C2=A0 Maybe this is because = of the
=C2=A0 =C2=A0removed check for 'isearch-mode' in isearch-lazy-highl= ight-* functions?

2. Using 'C-q' (isearch-quote-char) in the minibuffer or comint
=C2=A0 =C2=A0displays a truncated string, e.g. on 'M-! C-r C-q C-a'= .
=C2=A0 =C2=A0Maybe the default message function should be called directly =C2=A0 =C2=A0in isearch-quote-char?

3. Maybe the same default message function should be called directly
=C2=A0 =C2=A0also in some other functions like isearch-lazy-highlight-new-l= oop
=C2=A0 =C2=A0and isearch-lazy-highlight-buffer-update?



------------------------------

Message: 33
Date: Tue, 25 May 2021 14:21:07 -0700
From: "Colin Woodbury" <colin@fosskers.ca>
To: "Stefan Monnier" <monnier@iro.umontreal.ca>
Cc: "Basil L. Contovounesios" <contovob@tcd.ie>, emacs-devel@gnu.org
Subject: Re: [PATCH] lisp/files.el: Add `file-name-set-extension`
Message-ID: <3780a7f9-19f4-4216-baa9-ce00b3dbace9@www.fa= stmail.com>
Content-Type: text/plain; charset=3D"utf-8"

That regex was borrowed directly from `string-trim`, to which I added a `.`= . You're right that the main motivation was to allow the caller to pass= either `.foo` or `foo` as the extension and have either case work (many la= nguages do this). Leaving the other characters in the regex seemed like a s= anitary thing to do, just in case they pass something bogus. Although as th= e code is, there's nothing preventing them from still giving bogus char= acters before the file, or after the extension, making the resulting filepa= th still meaningless.

So we could consider:

1. Simplifying the regex to just include dots (and perhaps whitespace) (i.e= . trust the caller), or;
2. Expanding the logic to sanitize both ends of both arguments, (i.e. don&#= 39;t trust the caller), or;
3. Adding error-throwing logic if malformed files or extensions are given (= i.e. warn the user).

I'm happy to alter the patch for any of those scenarios, whichever is p= referable. Thanks!

On Tue, 25 May 2021, at 13:25, Stefan Monnier wrote:
> > +=C2=A0 (when (and filename extension)
> > +=C2=A0 =C2=A0 (let* ((patt "[ \t\n\r.]+") ; Inspired b= y `string-trim'.
> > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(filename (string-trim-= right filename patt))
> > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(extension (string-trim= -left extension patt)))
> > +=C2=A0 =C2=A0 =C2=A0 (unless (or (string-empty-p filename)
> > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (= string-empty-p extension))
> > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 (concat (file-name-sans-extension fi= lename) "." extension)))))
>
> Why do you trim [ \t\n\r.]+ from the end of the filename and the
> beginning of the extension?
>
> I can see why you'd want to remove a single "." at the b= eginning of
> `extension`, so as to allow extension to come with or without a leadin= g
> ".", but the rest seems rather surprising because such chara= cters in my
> experience almost never show up in such a circumstance (which means > that if they do, it's either on purpose and we should preserve it,= or
> it's an error "upstream" and we should try and help expo= se the error
> rather than silently try to cover it).
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Stefan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnu.org/archive/html/emacs-devel/attachments/20210525/d78bac= 17/attachment.html>

------------------------------

Message: 34
Date: Tue, 25 May 2021 17:29:19 -0400
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: "Colin Woodbury" <colin@fosskers.ca>
Cc: "Basil L. Contovounesios" <contovob@tcd.ie>,=C2=A0 emacs-devel@gnu.org
Subject: Re: [PATCH] lisp/files.el: Add `file-name-set-extension`
Message-ID: <jwvy2c2pkv5.fsf-monnier+emacs@gnu.org>
Content-Type: text/plain

> That regex was borrowed directly from `string-trim`, to which I added<= br> > a `.`. You're right that the main motivation was to allow the call= er to pass
> either `.foo` or `foo` as the extension and have either case work (man= y
> languages do this). Leaving the other characters in the regex seemed l= ike
> a sanitary thing to do, just in case they pass something bogus.

File names can be used in different ways for different purposes.
We don't have any good reason to think that a space or a newline at the=
end of a file name (or beginning of an extension) is "bogus".

If such things occurred somewhat often and always in ways where they are indeed undesirable, we could consider removing them (the tradeoff
between occasional harm and frequent error-avoidance would be
favorable), but here this is just asking for trouble with no benefit.

> 1. Simplifying the regex to just include dots (and perhaps whitespace)= (i.e. trust the caller), or;

Please do that.

> 2. Expanding the logic to sanitize both ends of both arguments, (i.e. = don't trust the caller), or;

I don't think we have any reason to think we should "sanitize"= ; it.

> 3. Adding error-throwing logic if malformed files or extensions are gi= ven (i.e. warn the user).

"Malformed" according to which standard?


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Stefan




------------------------------

Message: 35
Date: Tue, 25 May 2021 22:34:18 +0100 (BST)
From: Peter Oliver <p.d.oliver@mavit.org.uk>
To: emacs-devel@gn= u.org
Subject: Re: GUI X-FreeDesktop integration
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <7f52af92-4fb5-74b4-= 232a-eabfa315ac0@froglet.home.mavit.org.uk>
Content-Type: text/plain; charset=3D"utf-8"; Format=3D"flowe= d"

On Sunday 16th May, Robin Tarsiger wrote:

> In fact, the _least_ surprising from
> an XDG/FDO perspective would actually be to _only_ expose
> a "client+autolaunch" desktop entry and just call that the > point of integration for Emacs.

Agreed.=C2=A0 Attached is a patch which achieves this.

--
Peter Oliver
-------------- next part --------------
>From 84508dbc948038f9b7c797b3ec012c00379df7ee Mon Sep 17 00:00:00 2001
From: Peter Oliver <git@mavit.org.uk>
Date: Tue, 25 May 2021 22:06:43 +0100
Subject: [PATCH] From a GUI, lauch via emacsclient by default

* etc/emacs-mail.desktop, etc/emacs.desktop: Call emacsclient not
=C2=A0 emacs by default.=C2=A0 Provide plain emacs as an alternative action= .
---
=C2=A0etc/NEWS=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2= =A0 7 +++++++
=C2=A0etc/emacs-mail.desktop=C2=A0 | 13 ++++++++++---
=C2=A0etc/emacs.desktop=C2=A0 =C2=A0 =C2=A0 =C2=A0| 11 ++++++++++-
=C2=A0etc/emacsclient.desktop | 12 ------------
=C2=A04 files changed, 27 insertions(+), 16 deletions(-)
=C2=A0delete mode 100644 etc/emacsclient.desktop

diff --git a/etc/NEWS b/etc/NEWS
index 1541b74a3b..0605c8b46c 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -108,6 +108,13 @@ avoid security issues when executing untrusted code.= =C2=A0 See the manual
=C2=A0page for 'seccomp' system call, for details about Secure Comp= uting
=C2=A0filters.

+** Launching Emacs from a GUI now defaults to trying emacsclient.
+When launching Emacs via a freedesktop.org-compatible GUI, it is now
+the default to try to use emacsclient to open the file in an existing
+Emacs frame.=C2=A0 Opening a new frame in an existing Emacs or a separate<= br> +instance of Emacs are available as an alternative action (performed,
+for example, by right-clicking on the icon).
+

=C2=A0* Changes in Emacs 28.1

diff --git a/etc/emacs-mail.desktop b/etc/emacs-mail.desktop
index 0c5fab1dd1..e949b7f1ed 100644
--- a/etc/emacs-mail.desktop
+++ b/etc/emacs-mail.desktop
@@ -1,12 +1,19 @@
=C2=A0[Desktop Entry]
=C2=A0Categories=3DNetwork;Email;
=C2=A0Comment=3DGNU Emacs is an extensible, customizable text editor - and = more
-Exec=3Demacs -f message-mailto %u
-# If you prefer to use emacsclient, use this instead
-#Exec=3Demacsclient -e '(message-mailto "%u")'
+Exec=3Demacsclient --alternate-editor=3D --eval '(message-mailto "= ;%u")'
=C2=A0Icon=3Demacs
=C2=A0Name=3DEmacs (Mail)
=C2=A0MimeType=3Dx-scheme-handler/mailto;
=C2=A0NoDisplay=3Dfalse
=C2=A0Terminal=3Dfalse
=C2=A0Type=3DApplication
+Actions=3Dnew-window;new-instance;
+
+[Desktop Action new-window]
+Name=3DNew Window
+Exec=3Demacsclient --alternate-editor=3D --create-frame --eval '(messa= ge-mailto "%u")'
+
+[Desktop Action new-instance]
+Name=3DNew Instance
+Exec=3Demacs -f message-mailto %u
diff --git a/etc/emacs.desktop b/etc/emacs.desktop
index 2e6496e58c..d21bba0e10 100644
--- a/etc/emacs.desktop
+++ b/etc/emacs.desktop
@@ -3,10 +3,19 @@ Name=3DEmacs
=C2=A0GenericName=3DText Editor
=C2=A0Comment=3DEdit text
=C2=A0MimeType=3Dtext/english;text/plain;text/x-makefile;text/x-c++hdr;text= /x-c++src;text/x-chdr;text/x-csrc;text/x-java;text/x-moc;text/x-pascal;text= /x-tcl;text/x-tex;application/x-shellscript;text/x-c;text/x-c++;
-Exec=3Demacs %F
+Exec=3Demacsclient --alternate-editor=3D %F
=C2=A0Icon=3Demacs
=C2=A0Type=3DApplication
=C2=A0Terminal=3Dfalse
=C2=A0Categories=3DDevelopment;TextEditor;
=C2=A0StartupWMClass=3DEmacs
=C2=A0Keywords=3DText;Editor;
+Actions=3Dnew-window;new-instance;
+
+[Desktop Action new-window]
+Name=3DNew Window
+Exec=3Demacsclient --alternate-editor=3D --create-frame %F
+
+[Desktop Action new-instance]
+Name=3DNew Instance
+Exec=3Demacs %F
diff --git a/etc/emacsclient.desktop b/etc/emacsclient.desktop
deleted file mode 100644
index 3feb83c729..0000000000
--- a/etc/emacsclient.desktop
+++ /dev/null
@@ -1,12 +0,0 @@
-[Desktop Entry]
-Name=3DEmacs (Client)
-GenericName=3DText Editor
-Comment=3DEdit text
-MimeType=3Dtext/english;text/plain;text/x-makefile;text/x-c++hdr;text/x-c+= +src;text/x-chdr;text/x-csrc;text/x-java;text/x-moc;text/x-pascal;text/x-tc= l;text/x-tex;application/x-shellscript;text/x-c;text/x-c++;
-Exec=3Demacsclient -c %F
-Icon=3Demacs
-Type=3DApplication
-Terminal=3Dfalse
-Categories=3DDevelopment;TextEditor;
-StartupWMClass=3DEmacsd
-Keywords=3DText;Editor;
--
2.31.1


------------------------------

Message: 36
Date: Tue, 25 May 2021 14:44:30 -0700
From: "Colin Woodbury" <colin@fosskers.ca>
To: "Stefan Monnier" <monnier@iro.umontreal.ca>
Cc: "Basil L. Contovounesios" <contovob@tcd.ie>, emacs-devel@gnu.org
Subject: Re: [PATCH] lisp/files.el: Add `file-name-set-extension`
Message-ID: <6ba4668c-9b39-40e0-a155-f7e583fd33b6@www.fa= stmail.com>
Content-Type: text/plain; charset=3D"utf-8"

Thanks Stefan, I've revised the patch according to your suggestions (se= e attached). I also revised the docstring.

Thanks!
Colin

On Tue, 25 May 2021, at 14:29, Stefan Monnier wrote:
> > That regex was borrowed directly from `string-trim`, to which I a= dded
> > a `.`. You're right that the main motivation was to allow the= caller to pass
> > either `.foo` or `foo` as the extension and have either case work= (many
> > languages do this). Leaving the other characters in the regex see= med like
> > a sanitary thing to do, just in case they pass something bogus. >
> File names can be used in different ways for different purposes.
> We don't have any good reason to think that a space or a newline a= t the
> end of a file name (or beginning of an extension) is "bogus"= .
>
> If such things occurred somewhat often and always in ways where they a= re
> indeed undesirable, we could consider removing them (the tradeoff
> between occasional harm and frequent error-avoidance would be
> favorable), but here this is just asking for trouble with no benefit.<= br> >
> > 1. Simplifying the regex to just include dots (and perhaps whites= pace) (i.e. trust the caller), or;
>
> Please do that.
>
> > 2. Expanding the logic to sanitize both ends of both arguments, (= i.e. don't trust the caller), or;
>
> I don't think we have any reason to think we should "sanitize= " it.
>
> > 3. Adding error-throwing logic if malformed files or extensions a= re given (i.e. warn the user).
>
> "Malformed" according to which standard?
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Stefan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnu.org/archive/html/emacs-devel/attachments/20210525/65b293= 94/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: file-name-set-extension.patch
Type: text/x-patch
Size: 1050 bytes
Desc: not available
URL: <= https://lists.gnu.org/archive/html/emacs-devel/attachments/20210525/65b2939= 4/attachment.bin>

------------------------------

Message: 37
Date: Tue, 25 May 2021 15:40:34 -0700
From: Alex Bochannek <alex@bochannek.com>
To: Lars Ingebrigtsen <larsi@gnus.org>
Cc: emacs-devel@gn= u.org
Subject: Re: master eaf224f: Repad the Face header in Gnus
Message-ID: <m2eedul9nh.fsf@bochannek.com>
Content-Type: text/plain; charset=3D"utf-8"

Lars Ingebrigtsen <l= arsi@gnus.org> writes:

> Alex Bochannek <alex@bochannek.com> writes:
>
>> OK, agreed. Do you want me to submit a patch to revert that code a= nd the
>> tests?
>
> I think that might make sense, but I have no strong feelings about the=
> matter.

Here's a patch that reverts that code and the tests.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-patch
Size: 5684 bytes
Desc: not available
URL: <= https://lists.gnu.org/archive/html/emacs-devel/attachments/20210525/43403fd= 6/attachment.bin>
-------------- next part --------------

--
Alex.

------------------------------

Message: 38
Date: Tue, 25 May 2021 15:43:54 -0700
From: Alex Bochannek <alex@bochannek.com>
To: Lars Ingebrigtsen <larsi@gnus.org>
Cc: emacs-devel@gn= u.org
Subject: Re: master eaf224f: Repad the Face header in Gnus
Message-ID: <m2a6oil9hx.fsf@bochannek.com>
Content-Type: text/plain

Alex Bochannek <= alex@bochannek.com> writes:

> --- a/lisp/gnus/gnus-util.el
> +++ b/lisp/gnus/gnus-util.el
> @@ -1,3 +1,4 @@
> +
>=C2=A0 ;;; gnus-util.el --- utility functions for Gnus=C2=A0 -*- lexica= l-binding: t; -*-

That blank line is incorrect, of course. Not sure how that made it
through. Sorry about that.

--
Alex.



------------------------------

Message: 39
Date: Wed, 26 May 2021 01:03:33 +0100
From: Jo=C3=A3o T=C3=A1vora <joaotavora@gmail.com>
To: Gregory Heytings <gregory@heytings.org>
Cc: Daniel Mendler <mail@daniel-mendler.de>,=C2=A0 Stefan Monnier
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <monnier@iro.umontreal.ca>,=C2=A0 Juri Linkov <= juri@linkov.net>= ;,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 emacs-devel@gnu.org
Subject: Re: [PATCH] (icomplete-vertical-mode): Add support for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 affixations and, annotations
Message-ID: <874keqfjje.fsf@gmail.com>
Content-Type: text/plain; charset=3Dutf-8

Gregory Heytings <gregory@heytings.org> writes:

> Hi Daniel and Jo=C3=A3o,
>
> I said in bug#48013 that I was working on this, but I was waiting for<= br> > my copyright assignment to complete before sending patches.=C2=A0 Anyw= ay,
> apparently you've now taken this over, which is fine.=C2=A0 Alas I= have no
> time to look at what you did to send useful comments this week.
>
> Gregory

I've done a bit more work on icomplete.el and after seeing the
discussion evolve, I agree with Daniel that it's better to keep those two things orthogonal.

So I've now published two branches:

- scratch/icomplete-vertical-mode-improvements

=C2=A0 This makes icomplete-vertical-mode much nicer IMO.=C2=A0 After remov= ing the
=C2=A0 rotation in the vertical mode and adding a highlight color it looks = a
=C2=A0 bit like Vertico (which I tried recently).=C2=A0 If people like the<= br> =C2=A0 rotation in vertical mode, too, it's very easy to get it back.= =C2=A0 It
=C2=A0 also adds the annotation capabilities using some of the code Daniel<= br> =C2=A0 originally submitted.

=C2=A0 Since you, Gregory, made icomplete-vertical-mode and you, Daniel, =C2=A0 worked on its annotation capabilities, I wish you'd both have a = look.
=C2=A0 Else I will test it for a few days and then push to master.=C2=A0 Th= ere are
=C2=A0 still a lot of edges to polish, and I may have introduced some bugs,=
=C2=A0 though hopefully not in the legacy non-vertical parts.

- scratch/annotation-function-improvements

=C2=A0 This overhauls annotation-function and makes the C-h f and M-x
=C2=A0 backends use it instead of affixation-function.=C2=A0 It doesn't= delete
=C2=A0 affixation-function.

=C2=A0 It _may_ be useful, but I guess it's not the end of the
=C2=A0 affixation-function thing anyway, and I don't any much more to =C2=A0 contribute at this point.

Jo=C3=A3o







------------------------------

Message: 40
Date: Tue, 25 May 2021 17:32:09 -0700
From: Aaron Jensen <aaronjensen@gmail.com>
To: Alan Third <ala= n@idiocy.org>, Aaron Jensen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <aaronjensen@gmail.com>, emacs-devel@gnu.org, YAMAMOTO Mitsuharu =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mituharu@math.s.chiba-u.ac.jp>
Subject: Re: macOS metal rendering engine in mac port
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <CAHyO48y-WP-= WJrdTh1dGoBsZYVyZ24TpJpAdZndw+pu-z8xzuw@mail.gmail.com>
Content-Type: text/plain; charset=3D"UTF-8"

On Tue, May 25, 2021 at 9:31 AM Aaron Jensen <aaronjensen@gmail.com> wrote:
>
> On Mon, May 24, 2021 at 2:01 AM Alan Third <alan@idiocy.org> wrote:
> >
> > I think so. A lot of what people like (smooth scrolling, etc.) wo= uld
> > have to be removed.
>
> Weird, this has never worked for me, but maybe I've had it misconf= igured
>
> > One more thing to try...
> >
> > modified=C2=A0 =C2=A0src/nsterm.m
> > @@ -8376,7 +8376,13 @@ - (void)unfocusDrawingBuffer
> >=C2=A0 =C2=A0 NSTRACE ("[EmacsView unfocusDrawingBuffer]"= ;);
> >
> >=C2=A0 =C2=A0 [NSGraphicsContext setCurrentContext:nil];
> > -=C2=A0 [self setNeedsDisplay:YES];
> > +=C2=A0 [surface releaseContext];
> > +=C2=A0 [[self layer] setContents:(id)[surface getSurface]];
> > +=C2=A0 [surface performSelectorOnMainThread:@selector (getContex= t)
> > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 withObject:nil
> > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0waitUntilDone:NO];
> > +
> > +=C2=A0 //[self setNeedsDisplay:YES];
> >=C2=A0 }
> >
> >
> > @@ -8513,11 +8519,11 @@ - (void)updateLayer
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0There's a private method, -[CALayer= setContentsChanged], that we
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0could use to force it, but we shouldn&#= 39;t often get the same
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0surface twice in a row.=C2=A0 */
> > -=C2=A0 [surface releaseContext];
> > -=C2=A0 [[self layer] setContents:(id)[surface getSurface]];
> > -=C2=A0 [surface performSelectorOnMainThread:@selector (getContex= t)
> > -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 withObject:nil
> > -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0waitUntilDone:NO];
> > +=C2=A0 // [surface releaseContext];
> > +=C2=A0 // [[self layer] setContents:(id)[surface getSurface]]; > > +=C2=A0 // [surface performSelectorOnMainThread:@selector (getCon= text)
> > +=C2=A0 //=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0withObject:nil
> > +=C2=A0 //=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 waitUntilDone:NO];
> >=C2=A0 }
> >=C2=A0 #endif
> >
> >
> > All this does is reduce the time between us deciding we're do= ne with
> > drawing and sending it off to VRAM (although it might not, I'= m not
> > entirely sure when updateLayer gets called).
> >
> > I expect this to reduce frame rate, but perhaps it will improve i= nput
> > lag a little.
>
> I don't know if it's something funky with my machine or not bu= t I've
> noticed some stutters with this patch. As in, it appears to miss
> paints. I'll type a character and won't see it until I type so= mething
> else. Is it possible that this patch could cause that?

This stopped, so maybe it was something funky. So far, today, things
feel pretty good from a latency perspective. I haven't measured
anything yet.

Thanks,

Aaron



------------------------------

Message: 41
Date: Wed, 26 May 2021 07:23:19 +0100
From: Alan Third <a= lan@idiocy.org>
To: Aaron Jensen <aaronjensen@gmail.com>
Cc: emacs-devel@gn= u.org, YAMAMOTO Mitsuharu
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mituharu@math.s.chiba-u.ac.jp>
Subject: Re: macOS metal rendering engine in mac port
Message-ID: <YK3pV+0Ep7f+WymS@idiocy.org>
Content-Type: text/plain; charset=3Dus-ascii

On Tue, May 25, 2021 at 05:32:09PM -0700, Aaron Jensen wrote:
> On Tue, May 25, 2021 at 9:31 AM Aaron Jensen <aaronjensen@gmail.com> wrote:<= br> > >
> > I don't know if it's something funky with my machine or n= ot but I've
> > noticed some stutters with this patch. As in, it appears to miss<= br> > > paints. I'll type a character and won't see it until I ty= pe something
> > else. Is it possible that this patch could cause that?
>
> This stopped, so maybe it was something funky. So far, today, things > feel pretty good from a latency perspective. I haven't measured > anything yet.

It probably could, I've seen something similar when I was testing
something or other. It will be bypassing the viewWillDraw code that
forces a redisplay, but I think in theory we shouldn't need it with
this code.

Oh, I suppose that might break the live resizing. But we can work that
out if so.
--
Alan Third



------------------------------

Message: 42
Date: Tue, 25 May 2021 23:26:55 -0700
From: Aaron Jensen <aaronjensen@gmail.com>
To: Alan Third <ala= n@idiocy.org>, Aaron Jensen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <aaronjensen@gmail.com>, emacs-devel@gnu.org, YAMAMOTO Mitsuharu =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mituharu@math.s.chiba-u.ac.jp>
Subject: Re: macOS metal rendering engine in mac port
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <CAHyO48xVo6zhkUPUoPJkKrLZgcBt=3DPu9Lu3d2M98a= -sn23XVLA@mail.gmail.com>
Content-Type: text/plain; charset=3D"UTF-8"

On Tue, May 25, 2021 at 11:23 PM Alan Third <alan@idiocy.org> wrote:
>
> It probably could, I've seen something similar when I was testing<= br> > something or other. It will be bypassing the viewWillDraw code that > forces a redisplay, but I think in theory we shouldn't need it wit= h
> this code.
>
> Oh, I suppose that might break the live resizing. But we can work that=
> out if so.

Live resizing? I don't see the flicker and if I drag to resize it
remains painted usually. I did see it flash white once. And I think
I've perhaps seen it blank one time today briefly, but I don't
remember what I was doing.



------------------------------

Message: 43
Date: Wed, 26 May 2021 09:34:11 +0200
From: Andreas Schwab <schwab@linux-m68k.org>
To: "Colin Woodbury" <colin@fosskers.ca>
Cc: "Stefan Monnier" <monnier@iro.umontreal.ca>,=C2=A0 "Basil L= .
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Contovounesios" <contovob@tcd.ie>,=C2=A0 emacs-devel@gnu.org
Subject: Re: [PATCH] lisp/files.el: Add `file-name-set-extension`
Message-ID: <87czteeyoc.fsf@igel.home>
Content-Type: text/plain

On Mai 25 2021, Colin Woodbury wrote:

> +Returns nil if either of the FILENAME or EXTENSION are nil before
> +dot consolidation, or empty afterwards."
> +=C2=A0 (when (and filename extension)

I still don't see any reason to allow nil.=C2=A0 A file name is always = a
string.

Andreas.

--
Andreas Schwab, = schwab@linux-m68k.org
GPG Key fingerprint =3D 7578 EB47 D4E5 4D69 2510=C2=A0 2552 DF73 E780 A9DA = AEC1
"And now for something completely different."



------------------------------

Message: 44
Date: Wed, 26 May 2021 00:35:36 -0700
From: Aaron Jensen <aaronjensen@gmail.com>
To: Alan Third <ala= n@idiocy.org>, Aaron Jensen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <aaronjensen@gmail.com>, emacs-devel@gnu.org, YAMAMOTO Mitsuharu =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mituharu@math.s.chiba-u.ac.jp>
Subject: Re: macOS metal rendering engine in mac port
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <CAHyO48wqKmwh6v=3DZbAry3CAzm= eUgPtpz0GKmmxuh+QFSbQDpFA@mail.gmail.com>
Content-Type: text/plain; charset=3D"UTF-8"

On Tue, May 25, 2021 at 11:26 PM Aaron Jensen <aaronjensen@gmail.com> wrote:
>
> On Tue, May 25, 2021 at 11:23 PM Alan Third <alan@idiocy.org> wrote:
> >
> > It probably could, I've seen something similar when I was tes= ting
> > something or other. It will be bypassing the viewWillDraw code th= at
> > forces a redisplay, but I think in theory we shouldn't need i= t with
> > this code.
> >
> > Oh, I suppose that might break the live resizing. But we can work= that
> > out if so.
>
> Live resizing? I don't see the flicker and if I drag to resize it<= br> > remains painted usually. I did see it flash white once. And I think > I've perhaps seen it blank one time today briefly, but I don't=
> remember what I was doing.

Just did some latency measurements with emacs -Q (my previous ones
were w/ my config)

emacs27-drawing branch: 79.2 62.5 75.0 70.4 (71.775 avg)
emacs28 surface-stuff branch: 66.7 66.7 75.0 70.8 (69.8 avg)
emacs28 surface-stuff branch+last patch: 70.8 75.0 66.7 62.5 (68.75 avg)
Those are similar, if not slightly better than iterm2 latency on my
machine, so that's probably pretty good. The margin of error is going to be pretty high on those, so I can't definitely say that 28 is
faster.

The scroll-up-benchmark w/o the patch is slightly better from my
limited testing (4.9s vs 5.2s).

Aaron



------------------------------

Message: 45
Date: Wed, 26 May 2021 10:49:09 +0200
From: Robert Pluim <rpluim@gmail.com>
To: Peter Oliver <p.d.oliver@mavit.org.uk>
Cc: emacs-devel@gn= u.org
Subject: Re: GUI X-FreeDesktop integration
Message-ID: <87eedt518a.fsf@gmail.com>
Content-Type: text/plain; charset=3Dutf-8

>>>>> On Tue, 25 May 2021 22:34:18 +0100 (BST), Peter Oliver= <p.d.olive= r@mavit.org.uk> said:

=C2=A0 =C2=A0 Peter> On Sunday 16th May, Robin Tarsiger wrote:
=C2=A0 =C2=A0 >> In fact, the _least_ surprising from
=C2=A0 =C2=A0 >> an XDG/FDO perspective would actually be to _only_ e= xpose
=C2=A0 =C2=A0 >> a "client+autolaunch" desktop entry and ju= st call that the
=C2=A0 =C2=A0 >> point of integration for Emacs.

=C2=A0 =C2=A0 Peter> Agreed.=C2=A0 Attached is a patch which achieves th= is.

I don=CA=BCt object to this approach, but I have a couple of points:

=C2=A0 =C2=A0 - If the user hasn't enabled the server, then this starts= emacs in
=C2=A0 =C2=A0 =C2=A0 daemon mode, which needs to be documented somewhere, p= ossibly in
=C2=A0 =C2=A0 =C2=A0 the .desktop file
=C2=A0 =C2=A0 - Can you document that enabling the server is a pre-requisit= e
=C2=A0 =C2=A0 =C2=A0 (modulo the daemon behaviour)?

Robert
--



------------------------------

Message: 46
Date: Wed, 26 May 2021 15:21:05 +0530
From: Anand Tamariya <atamariya@gmail.com>
To: Eli Zaretskii <eli= z@gnu.org>
Cc: emacs-devel@gn= u.org
Subject: Re: Unicode combining characters
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <CADm7Y4kgqO=3D2owO5XBp= V9-iMavfRxRVySuATkCzcZ+_p84M+BQ@mail.gmail.com>
Content-Type: text/plain; charset=3D"utf-8"

Thanks Eli - align-to 'space' display spec seems helpful.

Though it's a company specific issue related to unicode character
composition, here's some more details on the issue for record should somebody else stumble upon the same.

Let's call the first character in the screenshot as shr (single glyph) = and
the second one as sh-r (two glyphs).
(setq shr=C2=A0 (string 2358 2381 2352))
(setq sh-r (string 2358 2352))

(string-width shr)=C2=A0 ;; 2
(string-width sh-r) ;; 2

To create the rectangular region, we need to pad the strings with
appropriate number of spaces. align-to 'space' display spec seems h= elpful
in this case as shown below. You will notice that character "a" i= s aligned
in both cases. Now I need to figure out how to use the same within company.=

(insert (concat shr
(let ((sp " "))
=C2=A0(font-lock-append-text-property 0 1 'display `(space . (:align-to= 10)) sp)
=C2=A0sp)
"a"))

(insert (concat sh-r
(let ((sp " "))
=C2=A0(font-lock-append-text-property 0 1 'display `(space . (:align-to= 10)) sp)
=C2=A0sp)
"a"))
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnu.org/archive/html/emacs-devel/attachments/20210526/b32865= 57/attachment.html>

------------------------------

Message: 47
Date: Wed, 26 May 2021 12:04:39 +0200
From: Joost Kremers <joostkremers@fastmail.fm>
To: emacs-devel@gn= u.org
Subject: Re: Unicode combining characters
Message-ID: <874kepiz6i.fsf@fastmail.fm>
Content-Type: text/plain


On Wed, May 26 2021, Anand Tamariya wrote:
> Thanks Eli - align-to 'space' display spec seems helpful.
>
> Though it's a company specific issue related to unicode character<= br> > composition, here's some more details on the issue for record shou= ld
> somebody else stumble upon the same.

At the risk of posting something irrelevant: the effect shown in the screen= shot
you posted also occurs if you use company in a buffer with variable-pitch-m= ode
(which I do in e.g., LaTeX buffers). I don't know if that's the sam= e problem,
but if it is, a solution would be applicable beyond combining characters. <= br>
--
Joost Kremers
Life has its moments



------------------------------

Message: 48
Date: Wed, 26 May 2021 14:59:44 +0300
From: Eli Zaretskii <e= liz@gnu.org>
To: Karl Fogel <kfogel@red-bean.com>
Cc: orontee@gmail.co= m, drew.adam= s@oracle.com, larsi= @gnus.org,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 monnier@iro.umontreal.ca, emacs-devel@gnu.org
Subject: Re: [External] : Re: [PATCH] When deleting in bookmark menu,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 prompt for confirmation.
Message-ID: <837djlbt8v.fsf@gnu.org>

> From: Karl Fogel <kfogel@red-bean.com>
> Cc: orontee@gma= il.com,=C2=A0 drew.adams@oracle.com,=C2=A0 larsi@gnus.org,
>=C2=A0 =C2=A0monnier@iro.umontreal.ca,=C2=A0 emacs-devel@gnu.org
> Date: Tue, 25 May 2021 15:24:44 -0500
>
> >Given what you wrote, and what bookmark-load does with the prefix<= br> > >argument, I think it is better to say that explicitly in
> >bookmark-bmenu-load's doc string, since you only need a single=
> >quite
> >simple sentence to say that, whereas the doc strong of
> >bookmark-load
> >is quite long.
>
> Well, now that I've done it, I think your way is an improvement --=
> although it turned out to be slightly more doc change than I
> expected.=C2=A0 Revised patch attached for review.

LGTM, thanks.



------------------------------

Message: 49
Date: Wed, 26 May 2021 13:14:23 +0100 (BST)
From: Peter Oliver <p.d.oliver@mavit.org.uk>
To: emacs-devel@gn= u.org
Subject: Re: GUI X-FreeDesktop integration
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <573eb311-e0f6-2216= -4298-458ae8ab827b@froglet.home.mavit.org.uk>
Content-Type: text/plain; charset=3D"iso8859-7"; Format=3D"f= lowed"

On Tue, 25 May 2021, Peter Oliver wrote:

> On Sunday 16th May, Robin Tarsiger wrote:
>
>>=C2=A0 In fact, the _least_ surprising from
>>=C2=A0 an XDG/FDO perspective would actually be to _only_ expose >>=C2=A0 a "client+autolaunch" desktop entry and just call = that the
>>=C2=A0 point of integration for Emacs.
>
> Agreed.=C2=A0 Attached is a patch which achieves this.

After a bit more testing, I discovered a snag.

I believe that the default behaviour when opening a file from a desktop=E2= =80=99s file manager should be to open it in an existing GUI frame if one e= xists, or a new GUI frame if one does not.=C2=A0 Clicking Emacs in a deskto= p=E2=80=99s application launcher should open a new GUI frame.

The trouble is that, if Emacs is running as a daemon with no frames, `emacs= client /path/to/foo` will create a new TTY frame rather than a GUI frame.= =C2=A0 Should this behaviour be changed so that a GUI frame is preferred if= $DISPLAY is set?=C2=A0 While we=E2=80=99re here, should we report an error= if there is no display and no TTY?

--
Peter Oliver

------------------------------

Message: 50
Date: Wed, 26 May 2021 15:19:22 +0300
From: Eli Zaretskii <e= liz@gnu.org>
To: Peter Oliver <p.d.oliver@mavit.org.uk>
Cc: emacs-devel@gn= u.org
Subject: Re: GUI X-FreeDesktop integration
Message-ID: <8335u9bsc5.fsf@gnu.org>

> Date: Tue, 25 May 2021 22:34:18 +0100 (BST)
> From: Peter Oliver <p.d.oliver@mavit.org.uk>
>
> > In fact, the _least_ surprising from
> > an XDG/FDO perspective would actually be to _only_ expose
> > a "client+autolaunch" desktop entry and just call that = the
> > point of integration for Emacs.
>
> Agreed.=C2=A0 Attached is a patch which achieves this.

This is a backward-incompatible change, so why should it be the
default, and not the alternative action via right-click?=C2=A0 And anyway,<= br> wouldn't some people be surprised to see emacsclient frame when they expected a new instance of Emacs, without their say-so?



------------------------------

Message: 51
Date: Wed, 26 May 2021 15:54:43 +0300
From: Eli Zaretskii <e= liz@gnu.org>
To: Anand Tamariya <atamariya@gmail.com>
Cc: emacs-devel@gn= u.org
Subject: Re: Unicode combining characters
Message-ID: <83v975ac4s.fsf@gnu.org>

> From: Anand Tamariya <atamariya@gmail.com>
> Date: Wed, 26 May 2021 15:21:05 +0530
> Cc: emacs-dev= el@gnu.org
>
> Let's call the first character in the screenshot as shr (single gl= yph) and the second one as sh-r (two glyphs).
> (setq shr=C2=A0 (string 2358 2381 2352))
> (setq sh-r (string 2358 2352))
>
> (string-width shr)=C2=A0 ;; 2
> (string-width sh-r) ;; 2

Sorry, it turns out I've misremembered: string-width doesn't accoun= t
for "automatic compositions", the ones that happen due to
composition-function-table (as opposed to "static compositions" w= hich
happen due to the 'composition' text property).=C2=A0 So this case<= br> currently cannot be handled correctly by string-width; we should fix
that.



------------------------------

Message: 52
Date: Wed, 26 May 2021 21:57:22 +0800
From: Ihor Radchenko <yantar92@gmail.com>
To: Jean Louis <bugs@gnu.support>
Cc: Christopher Dimech <dimech@gmx.com>,=C2=A0 emacs-devel@gnu.org
Subject: Re: Cycling first N heading levels in outline
Message-ID: <87o8cxy4vx.fsf@localhost>
Content-Type: text/plain

Jean Louis <bugs@gnu.support> writes:

> Especially for Org users the outline-minor-mode is universal and gives=
> similar concepts of outline in various other modes:

Thanks for pointing this out. A long time ago, before I knew about
outline-minor-mode, I started using hideshow package with similar
functionality. Now, comparing the two, I can see how outline-minor-mode
can be sometimes better (not always though).

> - editing Emacs Lisp? Fold levels, sections, functions and open it. It=
>=C2=A0 =C2=A0gives visual index of functions, it becomes very easy to m= ove them
>=C2=A0 =C2=A0from place to place;

outline-minor-mode is definitely very nice when handling Elisp file
sections. Yet, it unfortunately cannot fold sexps inside functions
independently, unlike hideshow (correct me if I am wrong). I ended up
using both outline-minor-mode and hs-minor-mode for the time being. The
former for folding top-level defuns and comments and the latter for
folding sexps inside defuns.

Best,
Ihor



------------------------------

Subject: Digest Footer

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.or= g
https://lists.gnu.org/mailman/listinfo/emacs-devel=

------------------------------

End of Emacs-devel Digest, Vol 207, Issue 32
********************************************


--
Fragen sin= d nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu= werden
Georg Kreisler
--000000000000861e9605c3c50b1a--