* Re: Emacs-devel Digest, Vol 207, Issue 32
[not found] <mailman.55.1622044835.28148.emacs-devel@gnu.org>
@ 2021-06-02 9:25 ` Pedro Andres Aranda Gutierrez
0 siblings, 0 replies; only message in thread
From: Pedro Andres Aranda Gutierrez @ 2021-06-02 9:25 UTC (permalink / raw)
To: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 91276 bytes --]
> Message: 50
> Date: Wed, 26 May 2021 15:19:22 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> To: Peter Oliver <p.d.oliver@mavit.org.uk>
> 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 <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. 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, <emacs-devel-request@gnu.org> 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 <aaronjensen@gmail.com>
> To: Alan Third <alan@idiocy.org>, Aaron Jensen
> <aaronjensen@gmail.com>, emacs-devel@gnu.org, YAMAMOTO Mitsuharu
> <mituharu@math.s.chiba-u.ac.jp>
> 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 <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 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 <juri@linkov.net>
> To: João Távora <joaotavora@gmail.com>
> Cc: Daniel Mendler <mail@daniel-mendler.de>, 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 <juri@linkov.net>
> To: João Távora <joaotavora@gmail.com>
> Cc: Daniel Mendler <mail@daniel-mendler.de>, "emacs-devel@gnu.org"
> <emacs-devel@gnu.org>, monnier@iro.umontreal.ca, Dmitry Gutov
> <dgutov@yandex.ru>
> 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 <monnier@iro.umontreal.ca>
> To: Anand Tamariya <atamariya@gmail.com>
> Cc: emacs-devel@gnu.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
> > 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 <eliz@gnu.org>
> To: Anand Tamariya <atamariya@gmail.com>
> Cc: emacs-devel@gnu.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. 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 <juri@linkov.net>
> Cc: João Távora <joaotavora@gmail.com>, Daniel Mendler
> <mail@daniel-mendler.de>, emacs-devel@gnu.org
> Subject: Re: [PATCH] (icomplete-vertical-mode): Add support for
> affixations and, annotations
> Message-ID: <jwvim36sp6v.fsf-monnier+emacs@gnu.org>
> 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 <eliz@gnu.org>
> To: Aaron Jensen <aaronjensen@gmail.com>
> 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 <aaronjensen@gmail.com>
> > Date: Tue, 25 May 2021 08:35:42 -0700
> > Cc: emacs-devel@gnu.org, Alan Third <alan@idiocy.org>,
> > YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> >
> > > 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 <joaotavora@gmail.com>
> To: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Juri Linkov <juri@linkov.net>, Daniel Mendler
> <mail@daniel-mendler.de>, 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 <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. 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 <monnier@iro.umontreal.ca>
> To: Glenn Morris <rgm@gnu.org>
> Cc: emacs-devel@gnu.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.
> >>> 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 <dimech@gmx.com>
> To: Kévin Le Gouguec <kevin.legouguec@gmail.com>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, Ihor Radchenko
> <yantar92@gmail.com>, Jean Louis <bugs@gnu.support>,
> emacs-devel@gnu.org
> Subject: Cycling first N heading levels in outline
> Message-ID:
>
> <trinity-7081abb3-2fb9-477c-9af7-ca5d5658a08d-1621964471853@3c-app-mailcom-bs01
> >
>
> 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" <kevin.legouguec@gmail.com>
> > To: "Christopher Dimech" <dimech@gmx.com>
> > Cc: "Stefan Monnier" <monnier@iro.umontreal.ca>, "Ihor Radchenko" <
> yantar92@gmail.com>, "Jean Louis" <bugs@gnu.support>, emacs-devel@gnu.org
> > Subject: Re: Cycling first N heading levels in outline
> >
> > Christopher Dimech <dimech@gmx.com> 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 <joaotavora@gmail.com>
> To: Juri Linkov <juri@linkov.net>
> Cc: Daniel Mendler <mail@daniel-mendler.de>, "emacs-devel@gnu.org"
> <emacs-devel@gnu.org>, monnier@iro.umontreal.ca, Dmitry Gutov
> <dgutov@yandex.ru>
> 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 <juri@linkov.net> 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 <aaronjensen@gmail.com>
> To: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org, Alan Third <alan@idiocy.org>, YAMAMOTO
> Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> 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 <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. 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 <schwab@linux-m68k.org>
> To: "Colin Woodbury" <colin@fosskers.ca>
> 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" <raman@google.com>
> To: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Glenn Morris <rgm@gnu.org>, emacs-devel@gnu.org
> Subject: Re: Emacs is not reproducible
> Message-ID: <p91o8cy1z18.fsf@google.com>
> Content-Type: text/plain; charset=gb18030
>
> 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 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" <contovob@tcd.ie>
> To: "Colin Woodbury" <colin@fosskers.ca>
> 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" <colin@fosskers.ca> 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 <rgm@gnu.org>
> To: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.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 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 <cpitclaudel@gmail.com>
> 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 <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.
>
> 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" <contovob@tcd.ie>
> To: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Glenn Morris <rgm@gnu.org>, 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 <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 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 <eliz@gnu.org>
> To: Clément Pit-Claudel <cpitclaudel@gmail.com>
> 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 <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 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 <cpitclaudel@gmail.com>
> To: Eli Zaretskii <eliz@gnu.org>
> 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 <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 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 <larsi@gnus.org>
> To: Alex Bochannek <alex@bochannek.com>
> 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 <alex@bochannek.com> 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" <colin@fosskers.ca>
> To: "Andreas Schwab" <schwab@linux-m68k.org>
> Cc: emacs-devel@gnu.org
> Subject: Re: [PATCH] lisp/files.el: Add `file-name-set-extension`
> Message-ID: <c915ee30-8c7e-41a3-aad7-51d296c82bb0@www.fastmail.com>
> 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 <mailto:schwab%40linux-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 <eliz@gnu.org>
> To: Clément Pit-Claudel <cpitclaudel@gmail.com>
> 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 <cpitclaudel@gmail.com>
> > 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" <colin@fosskers.ca>
> To: "Basil L. Contovounesios" <contovob@tcd.ie>
> Cc: emacs-devel@gnu.org
> Subject: Re: [PATCH] lisp/files.el: Add `file-name-set-extension`
> Message-ID: <c4eef0ed-3ae1-4c54-a967-674e73ac5774@www.fastmail.com>
> 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" <colin@fosskers.ca <mailto:colin%40fosskers.ca>>
> 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 <alan@idiocy.org>
> To: Eli Zaretskii <eliz@gnu.org>
> Cc: aaronjensen@gmail.com, emacs-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=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 <alan@idiocy.org>
> > > 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 <monnier@iro.umontreal.ca>
> To: João Távora <joaotavora@gmail.com>
> Cc: Juri Linkov <juri@linkov.net>, Daniel Mendler
> <mail@daniel-mendler.de>, emacs-devel@gnu.org
> Subject: Re: [PATCH] (icomplete-vertical-mode): Add support for
> affixations and, annotations
> Message-ID: <jwvpmxer4mo.fsf-monnier+emacs@gnu.org>
> 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 <kfogel@red-bean.com>
> To: Eli Zaretskii <eliz@gnu.org>
> 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 <kfogel@red-bean.com>
> >> 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 <monnier@iro.umontreal.ca>
> To: "Colin Woodbury" <colin@fosskers.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: <jwveedur2cl.fsf-monnier+emacs@gnu.org>
> 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 <dgutov@yandex.ru>
> To: Stefan Monnier <monnier@iro.umontreal.ca>, João Távora
> <joaotavora@gmail.com>
> Cc: Juri Linkov <juri@linkov.net>, Daniel Mendler
> <mail@daniel-mendler.de>, 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 <juri@linkov.net>
> To: João Távora <joaotavora@gmail.com>
> Cc: Daniel Mendler <mail@daniel-mendler.de>, "emacs-devel@gnu.org"
> <emacs-devel@gnu.org>, monnier@iro.umontreal.ca, Dmitry Gutov
> <dgutov@yandex.ru>
> 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 <joaotavora@gmail.com>
> To: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Juri Linkov <juri@linkov.net>, Daniel Mendler
> <mail@daniel-mendler.de>, 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 <monnier@iro.umontreal.ca> 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 <juri@linkov.net>
> To: Augusto Stoffel <arstoffel@gmail.com>
> 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" <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.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 <monnier@iro.umontreal.ca>
> To: "Colin Woodbury" <colin@fosskers.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: <jwvy2c2pkv5.fsf-monnier+emacs@gnu.org>
> 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 <p.d.oliver@mavit.org.uk>
> 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 <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
> 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" <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.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 <alex@bochannek.com>
> To: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Subject: Re: master eaf224f: Repad the Face header in Gnus
> Message-ID: <m2eedul9nh.fsf@bochannek.com>
> Content-Type: text/plain; charset="utf-8"
>
> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
> > Alex Bochannek <alex@bochannek.com> 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 <alex@bochannek.com>
> To: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.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 @@
> > +
> > ;;; 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 <joaotavora@gmail.com>
> To: Gregory Heytings <gregory@heytings.org>
> Cc: Daniel Mendler <mail@daniel-mendler.de>, Stefan Monnier
> <monnier@iro.umontreal.ca>, Juri Linkov <juri@linkov.net>,
> 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 <gregory@heytings.org> 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 <aaronjensen@gmail.com>
> To: Alan Third <alan@idiocy.org>, Aaron Jensen
> <aaronjensen@gmail.com>, emacs-devel@gnu.org, YAMAMOTO Mitsuharu
> <mituharu@math.s.chiba-u.ac.jp>
> 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 <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.) 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 <alan@idiocy.org>
> To: Aaron Jensen <aaronjensen@gmail.com>
> Cc: emacs-devel@gnu.org, YAMAMOTO Mitsuharu
> <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=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 <aaronjensen@gmail.com>
> 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 <aaronjensen@gmail.com>
> To: Alan Third <alan@idiocy.org>, Aaron Jensen
> <aaronjensen@gmail.com>, emacs-devel@gnu.org, YAMAMOTO Mitsuharu
> <mituharu@math.s.chiba-u.ac.jp>
> Subject: Re: macOS metal rendering engine in mac port
> Message-ID:
> <CAHyO48xVo6zhkUPUoPJkKrLZgcBt=
> Pu9Lu3d2M98a-sn23XVLA@mail.gmail.com>
> Content-Type: text/plain; charset="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
> > 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 <schwab@linux-m68k.org>
> To: "Colin Woodbury" <colin@fosskers.ca>
> Cc: "Stefan Monnier" <monnier@iro.umontreal.ca>, "Basil L.
> Contovounesios" <contovob@tcd.ie>, 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 <aaronjensen@gmail.com>
> To: Alan Third <alan@idiocy.org>, Aaron Jensen
> <aaronjensen@gmail.com>, emacs-devel@gnu.org, YAMAMOTO Mitsuharu
> <mituharu@math.s.chiba-u.ac.jp>
> Subject: Re: macOS metal rendering engine in mac port
> Message-ID:
> <CAHyO48wqKmwh6v=
> ZbAry3CAzmeUgPtpz0GKmmxuh+QFSbQDpFA@mail.gmail.com>
> Content-Type: text/plain; charset="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 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 <rpluim@gmail.com>
> To: Peter Oliver <p.d.oliver@mavit.org.uk>
> 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 <atamariya@gmail.com>
> To: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> Subject: Re: Unicode combining characters
> Message-ID:
> <CADm7Y4kgqO=
> 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 <joostkremers@fastmail.fm>
> 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 <eliz@gnu.org>
> To: Karl Fogel <kfogel@red-bean.com>
> 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 <kfogel@red-bean.com>
> > 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 <p.d.oliver@mavit.org.uk>
> 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 <eliz@gnu.org>
> To: Peter Oliver <p.d.oliver@mavit.org.uk>
> 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 <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. 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 <eliz@gnu.org>
> To: Anand Tamariya <atamariya@gmail.com>
> Cc: emacs-devel@gnu.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-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 <yantar92@gmail.com>
> To: Jean Louis <bugs@gnu.support>
> Cc: Christopher Dimech <dimech@gmx.com>, 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
> > 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
[-- Attachment #2: Type: text/html, Size: 126273 bytes --]
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2021-06-02 9:25 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <mailman.55.1622044835.28148.emacs-devel@gnu.org>
2021-06-02 9:25 ` Emacs-devel Digest, Vol 207, Issue 32 Pedro Andres Aranda Gutierrez
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).