|
| From: | Pedro Andres Aranda Gutierrez |
| Subject: | Re: Emacs-devel Digest, Vol 207, Issue 32 |
| Date: | Wed, 2 Jun 2021 11:25:26 +0200 |
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
********************************************
| [Prev in Thread] | Current Thread | [Next in Thread] |