> 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ão Távora) > 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ão Távora) > 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ément Pit-Claudel) > 18. Re: Emacs is not reproducible (Basil L. Contovounesios) > 19. Re: Unicode combining characters (Eli Zaretskii) > 20. Re: Unicode combining characters (Clément 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ão Távora) > 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ão Távora) > 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="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ão Távora > 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 frontend > > (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 layout > > 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ão Távora > 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 the > > 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, or > > 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-MADtxUeps3S_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ão Távora , 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 linker > > > 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="-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ão Távora > 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=utf-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 be > > 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ão > > > > > > ------------------------------ > > 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 some > >>> 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évin 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=UTF-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évin 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’s faces > > > on headings. When ‘override’, it completely overwrites major mode’s > > > faces with outline faces. When ‘append’, it tries to append outline > > > faces to major mode’s faces. > > > > > > ------------------------------ > > Message: 11 > Date: Tue, 25 May 2021 18:46:07 +0100 > From: João Távora > 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=utf-8 > > Juri Linkov writes: > > > 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. > > 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ão > > > > > > ------------------------------ > > 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="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 = 7578 EB47 D4E5 4D69 2510 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" > To: Stefan Monnier > Cc: Glenn Morris , emacs-devel@gnu.org > Subject: Re: Emacs is not reproducible > Message-ID: > Content-Type: text/plain; charset=gb18030 > > 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 some > >>>> 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) > ♈ Id: kg:/m/0285kf1 🦮 > > > > ------------------------------ > > 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ément 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=utf-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=utf-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 some > >>>> 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 ‘math-compare’ is not known to > be > defined. > calc/calc.el:2805:27: Warning: the function ‘math-zerop’ is not known to be > defined. > In tramp-handle-access-file: > net/tramp.el:3238:43: Warning: attempt to inline ‘tramp-error’ before it > was > defined > net/tramp.el:3238:43: Warning: attempt to inline ‘tramp-error’ before it > was > defined > > Thanks, > > -- > Basil > > > > ------------------------------ > > Message: 19 > Date: Tue, 25 May 2021 21:39:50 +0300 > From: Eli Zaretskii > To: Clément Pit-Claudel > Cc: emacs-devel@gnu.org > Subject: Re: Unicode combining characters > Message-ID: <83cztebqtl.fsf@gnu.org> > Content-Type: text/plain; charset=utf-8 > > > From: Clément 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 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? > > 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. > > 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ément 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=utf-8 > > On 5/25/21 2:39 PM, Eli Zaretskii wrote: > >> From: Clément 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 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? > > > > 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 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. As far > as I know, there is no way to add extra space after 123 or 456 so that they > reach the same X coordinate, given that they are already part of a display > spec. > > Clément. > > > > ------------------------------ > > 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 the > > 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="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 = 7578 EB47 D4E5 4D69 2510 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/e7d4c532/attachment.html > > > > ------------------------------ > > Message: 23 > Date: Tue, 25 May 2021 22:44:29 +0300 > From: Eli Zaretskii > To: Clément Pit-Claudel > Cc: emacs-devel@gnu.org > Subject: Re: Unicode combining characters > Message-ID: <83a6oibntu.fsf@gnu.org> > Content-Type: text/plain; charset=utf-8 > > > Cc: emacs-devel@gnu.org > > From: Clément Pit-Claudel > > Date: Tue, 25 May 2021 15:30:21 -0400 > > > > 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 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. As > far as I know, there is no way to add extra space after 123 or 456 so that > 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="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/4b16c111/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/4b16c111/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=us-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ão Távora > 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 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. > > 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="utf-8"; Format="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/d4a44b49/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ão Távora > > 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=utf-8; format=flowed > > On 25.05.2021 23:01, Stefan Monnier wrote: > > The fact that it takes a whole list rather than a single element is more > > 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ão Távora > 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ão Távora > 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=utf-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ão > > > > > > > > ------------------------------ > > 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="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 > 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/d78bac17/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 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 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="utf-8"; Format="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=Network;Email; > Comment=GNU Emacs is an extensible, customizable text editor - and more > -Exec=emacs -f message-mailto %u > -# If you prefer to use emacsclient, use this instead > -#Exec=emacsclient -e '(message-mailto "%u")' > +Exec=emacsclient --alternate-editor= --eval '(message-mailto "%u")' > Icon=emacs > Name=Emacs (Mail) > MimeType=x-scheme-handler/mailto; > NoDisplay=false > Terminal=false > Type=Application > +Actions=new-window;new-instance; > + > +[Desktop Action new-window] > +Name=New Window > +Exec=emacsclient --alternate-editor= --create-frame --eval > '(message-mailto "%u")' > + > +[Desktop Action new-instance] > +Name=New Instance > +Exec=emacs -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=Emacs > GenericName=Text Editor > Comment=Edit text > > MimeType=text/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=emacs %F > +Exec=emacsclient --alternate-editor= %F > Icon=emacs > Type=Application > Terminal=false > Categories=Development;TextEditor; > StartupWMClass=Emacs > Keywords=Text;Editor; > +Actions=new-window;new-instance; > + > +[Desktop Action new-window] > +Name=New Window > +Exec=emacsclient --alternate-editor= --create-frame %F > + > +[Desktop Action new-instance] > +Name=New Instance > +Exec=emacs %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=Emacs (Client) > -GenericName=Text Editor > -Comment=Edit text > > -MimeType=text/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=emacsclient -c %F > -Icon=emacs > -Type=Application > -Terminal=false > -Categories=Development;TextEditor; > -StartupWMClass=Emacsd > -Keywords=Text;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="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 (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. > > > > 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 > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.gnu.org/archive/html/emacs-devel/attachments/20210525/65b29394/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/65b29394/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="utf-8" > > Lars Ingebrigtsen writes: > > > Alex Bochannek writes: > > > >> OK, agreed. Do you want me to submit a patch to revert that code and 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/43403fd6/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ão Távora > 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=utf-8 > > Gregory Heytings writes: > > > Hi Daniel and João, > > > > 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ão > > > > > > > > ------------------------------ > > 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="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 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? > > 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=us-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="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 = 7578 EB47 D4E5 4D69 2510 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 > 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="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 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. > > 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=utf-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ʼt 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="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 (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 aligned > in both cases. Now I need to figure out how to use the same within company. > > (insert (concat shr > (let ((sp " ")) > (font-lock-append-text-property 0 1 'display `(space . (:align-to 10)) sp) > sp) > "a")) > > (insert (concat sh-r > (let ((sp " ")) > (font-lock-append-text-property 0 1 'display `(space . (:align-to 10)) sp) > sp) > "a")) > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.gnu.org/archive/html/emacs-devel/attachments/20210526/b3286557/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="iso8859-7"; Format="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’s > 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’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’re 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 > ******************************************** > -- Fragen sind nicht da um beantwortet zu werden, Fragen sind da um gestellt zu werden Georg Kreisler