Questions regarding PGTK, high-dpi font-rendering, new X11-Warning

Questions regarding PGTK, high-dpi font-rendering, new X11-Warning

[Björn Bidar]

Hello,

I have a questions regarding PGTK especially in the context of X11 and
Wayland in parallel.

I sometimes use X11 and sometimes Wayland, I build my Emacs with PGTK to
able to do both (without XWayland).

I also was under the impression that fondering is better using PGTK when
using a high dpi screen, even under X11. Was that wrong? 

Now there's this big warning block wich appears when you use PGTK under
X11.
- Will it break emacs --daemon? The frame is spawned right when the X11
  display connection is initiated.

- I think it kinda rude to right out spawn a big window on every start,
  it doesn't fit into how emacs usually acts. What I'm trying to say is
  I think it is ok so show a warning every time server starts but adding
  this big blob of text that spawns 2/10 of the screen when Emacs is in
  fullscreen is a little much.

I wonder how viable this strategy if Emacs has to be compiled twice for
Wayland support.

Br,

Björn

Re: Questions regarding PGTK, high-dpi font-rendering, new X11-Warning

[Po Lu]

Björn Bidar <bjorn.bidar@thaodan.de> writes:

> I also was under the impression that fondering is better using PGTK when
> using a high dpi screen, even under X11. Was that wrong? 

If by "fondering" you mean font display, then yes, that was wrong: the
same Cairo font backend as the default X11 build is also used by the
PGTK build.

> Now there's this big warning block wich appears when you use PGTK under
> X11.

> - Will it break emacs --daemon? The frame is spawned right when the X11
>   display connection is initiated.

Yes, it will crash regardless.

> - I think it kinda rude to right out spawn a big window on every start,
>   it doesn't fit into how emacs usually acts. What I'm trying to say is
>   I think it is ok so show a warning every time server starts but adding
>   this big blob of text that spawns 2/10 of the screen when Emacs is in
>   fullscreen is a little much.

The other alternative we considered was to prevent Emacs from starting
under X11 when compiled with PGTK.

> I wonder how viable this strategy if Emacs has to be compiled twice for
> Wayland support.

The alternative is to have an Emacs that crashes under X11 in various
common situations.  Please read the message in the dialog box.

Re: Questions regarding PGTK, high-dpi font-rendering, new X11-Warning

[Björn Bidar]

Po Lu <luangruo@yahoo.com> writes:

> Björn Bidar <bjorn.bidar@thaodan.de> writes:
>
>> I also was under the impression that fondering is better using PGTK when
>> using a high dpi screen, even under X11. Was that wrong? 
>
> If by "fondering" you mean font display, then yes, that was wrong: the
> same Cairo font backend as the default X11 build is also used by the
> PGTK build.

Hm something must be wrong then if it didn't scale properly outside of
the X11 build.

>> Now there's this big warning block wich appears when you use PGTK under
>> X11.
>
>> - Will it break emacs --daemon? The frame is spawned right when the X11
>>   display connection is initiated.
>
> Yes, it will crash regardless.

It didn't crash before..

>> - I think it kinda rude to right out spawn a big window on every start,
>>   it doesn't fit into how emacs usually acts. What I'm trying to say is
>>   I think it is ok so show a warning every time server starts but adding
>>   this big blob of text that spawns 2/10 of the screen when Emacs is in
>>   fullscreen is a little much.
>
> The other alternative we considered was to prevent Emacs from starting
> under X11 when compiled with PGTK.

Or make it run as good as it can under X11 and leave the rest of the
remaining issues as work as intended until a fix is found

>> I wonder how viable this strategy if Emacs has to be compiled twice for
>> Wayland support.
>
> The alternative is to have an Emacs that crashes under X11 in various
> common situations.  Please read the message in the dialog box.

Emacs might to something strange with GTK then, it is the only program
having these issues.

So far I didn't experience such issues.

Br,

Björn

Re: Questions regarding PGTK, high-dpi font-rendering, new X11-Warning

[Po Lu]

Björn Bidar <bjorn.bidar@thaodan.de> writes:

> It didn't crash before..

As a result of not crashing, the clipboard did not work well either.

> Or make it run as good as it can under X11 and leave the rest of the
> remaining issues as work as intended until a fix is found

Why? There is already a perfectly good X build, so doing so would be a
waste of our energy.

> Emacs might to something strange with GTK then, it is the only program
> having these issues.
>
> So far I didn't experience such issues.

Emacs uses more low level mechanisms in GTK compared to most other
programs, but there is nothing wrong with how it uses them.

Re: Questions regarding PGTK, high-dpi font-rendering, new X11-Warning

[Björn Bidar]

Po Lu <luangruo@yahoo.com> writes:

> Björn Bidar <bjorn.bidar@thaodan.de> writes:
>
>> It didn't crash before..
>
> As a result of not crashing, the clipboard did not work well either.

Which clipboard issues? It's working just fine for me.

>> Or make it run as good as it can under X11 and leave the rest of the
>> remaining issues as work as intended until a fix is found
>
> Why? There is already a perfectly good X build, so doing so would be a
> waste of our energy.

Why two Emacs binaries?

>> Emacs might to something strange with GTK then, it is the only program
>> having these issues.
>>
>> So far I didn't experience such issues.
>
> Emacs uses more low level mechanisms in GTK compared to most other
> programs, but there is nothing wrong with how it uses them.

The GTK devs probably disagree wit that.

Br,

Björn

Re: Questions regarding PGTK, high-dpi font-rendering, new X11-Warning

[Po Lu]

Björn Bidar <bjorn.bidar@thaodan.de> writes:

> Which clipboard issues? It's working just fine for me.

Try copying a large file into Emacs.  One such file would be
src/xterm.c.

> Why two Emacs binaries?

Why not? Wayland is a different window system from X, so you will need a
different build of Emacs.

Re: Questions regarding PGTK, high-dpi font-rendering, new X11-Warning

[xenodasein--- via Emacs development discussions.]

Nov 28, 2022, 11:41 by luangruo@yahoo.com:

> Björn Bidar <bjorn.bidar@thaodan.de> writes:
>
>> Which clipboard issues? It's working just fine for me.
>>
>
> Try copying a large file into Emacs.  One such file would be
> src/xterm.c.
>
>> Why two Emacs binaries?
>>
>
> Why not? Wayland is a different window system from X, so you will need a
> different build of Emacs.
>

To give less headaches to the users, why else.  Have one binary,
do it dynamically.

Re: Questions regarding PGTK, high-dpi font-rendering, new X11-Warning

[Po Lu]

xenodasein@tutanota.de writes:

> To give less headaches to the users, why else.  Have one binary,
> do it dynamically.

Then will you volunteer to write the code that makes it safe?  And keep
it working for the next 5 or so years, at least?  Regardless of what the
GTK developers decide to do in the meantime?

Re: Questions regarding PGTK, high-dpi font-rendering, new X11-Warning

[Stefan Monnier]

Po Lu [2022-11-30 18:13:14] wrote:
> xenodasein@tutanota.de writes:
>> To give less headaches to the users, why else.  Have one binary,
>> do it dynamically.
> Then will you volunteer to write the code that makes it safe?  And keep
> it working for the next 5 or so years, at least?  Regardless of what the
> GTK developers decide to do in the meantime?

FWIW, I really wish we moved in this direction.  Make it possible to
build a single Emacs executable which can use GNUstep frames, PGTK
frames, tty frames, X11 frames, some with Athena toolkit widgets others
with no-toolkit widgets, etc... ideally all at the same time.

For my own use the most important part is the support of both "toolkit"
and "no-toolkit" scrollbars, since I find the no-toolkit scrollbars more
useful than the toolkit ones.


        Stefan

Re: Questions regarding PGTK, high-dpi font-rendering, new X11-Warning

[Po Lu]

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

> FWIW, I really wish we moved in this direction.  Make it possible to
> build a single Emacs executable which can use GNUstep frames, PGTK
> frames, tty frames, X11 frames, some with Athena toolkit widgets others
> with no-toolkit widgets, etc... ideally all at the same time.

The first and second part is definitely too much to ask for... using the
event loop of one of those toolkits immediately precludes using the
other.

> For my own use the most important part is the support of both "toolkit"
> and "no-toolkit" scrollbars, since I find the no-toolkit scrollbars more
> useful than the toolkit ones.

I will work on that one eventually.  It should be easy, but I am too
preoccupied ATM.

Re: Questions regarding PGTK, high-dpi font-rendering, new X11-Warning

[Stefan Monnier]

Po Lu [2022-11-30 21:39:41] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> FWIW, I really wish we moved in this direction.  Make it possible to
>> build a single Emacs executable which can use GNUstep frames, PGTK
>> frames, tty frames, X11 frames, some with Athena toolkit widgets others
>> with no-toolkit widgets, etc... ideally all at the same time.
> The first and second part is definitely too much to ask for... using the
> event loop of one of those toolkits immediately precludes using the
> other.

What I read here is "we should move each GUI event loop into its own
thread" :-)


        Stefan

Re: Questions regarding PGTK, high-dpi font-rendering, new X11-Warning

[Po Lu]

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

> What I read here is "we should move each GUI event loop into its own
> thread" :-)

That's not ok, as Xlib (used by both those toolkits, and also Emacs
itself) is not thread safe.

Even though it can be thread safe at first glance, having multiple
threads work at the same time will mess up request serial tracking, and
`x_error_catcher' and friends will stop working.

Re: Questions regarding PGTK, high-dpi font-rendering, new X11-Warning

[Stefan Monnier]

Po Lu [2022-12-01 08:52:42] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> What I read here is "we should move each GUI event loop into its own
>> thread" :-)
> That's not ok, as Xlib (used by both those toolkits, and also Emacs
> itself) is not thread safe.

I read this as "it requires moving more than just the event loop: all
interactions with the GUI need to use the other thread" :-)


        Stefan

Re: Questions regarding PGTK, high-dpi font-rendering, new X11-Warning

[Po Lu]

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

> I read this as "it requires moving more than just the event loop: all
> interactions with the GUI need to use the other thread" :-)

As long as any thread is running one of GNUstep or GTK, no other thread
can run anything else.  :-(

Re: Questions regarding PGTK, high-dpi font-rendering, new X11-Warning

[Stefan Monnier]

Po Lu [2022-12-01 10:38:24] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> I read this as "it requires moving more than just the event loop: all
>> interactions with the GUI need to use the other thread" :-)
> As long as any thread is running one of GNUstep or GTK, no other thread
> can run anything else.  :-(

I doubt this is literally true.  Maybe you mean that if a thread runs
GTK then other threads can't simultaneously run GNUstep, for example,
but I'm pretty sure other threads can still run on their own, otherwise
GTK program could not be multithreaded.


        Stefan

Re: Questions regarding PGTK, high-dpi font-rendering, new X11-Warning

[Po Lu]

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

> I doubt this is literally true.  Maybe you mean that if a thread runs
> GTK then other threads can't simultaneously run GNUstep

Yes, this is what I meant.

> , for example, but I'm pretty sure other threads can still run on
> their own, otherwise GTK program could not be multithreaded.

GTK has a global lock around its own stuff, which GNUstep doesn't know
about.  The lock is taken whenever it starts waiting for events.

I think the only way to really do what you want is to run both GNUstep
and GTK in separate processes.

Re: Questions regarding PGTK, high-dpi font-rendering, new X11-Warning

[chad]

[-- Attachment #1: Type: text/plain, Size: 674 bytes --]

On Wed, Nov 30, 2022 at 7:54 PM Po Lu <luangruo@yahoo.com> wrote:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> > What I read here is "we should move each GUI event loop into its own
> > thread" :-)
>
> That's not ok, as Xlib (used by both those toolkits, and also Emacs
> itself) is not thread safe.
>
> Even though it can be thread safe at first glance, having multiple
> threads work at the same time will mess up request serial tracking, and
> `x_error_catcher' and friends will stop working.
>

I'm not up to doing the work myself, and obviously I'm not asking anyone
else to do so, but I wonder if anyone has looked at moving emacs from Xlib
to XCB?

~Chad

[-- Attachment #2: Type: text/html, Size: 1124 bytes --]

Re: Questions regarding PGTK, high-dpi font-rendering, new X11-Warning

[Po Lu]

chad <yandros@gmail.com> writes:

> I'm not up to doing the work myself, and obviously I'm not asking
> anyone else to do so, but I wonder if anyone has looked at moving
> emacs from Xlib to XCB?

Emacs already uses XCB where available and necessary for performance
reasons.

We will not "move" Emacs entirely to XCB, there is no point in that, and
the Qt folks are still dealing with the consequences of such a short
sighted decision even today.

Re: Questions regarding PGTK, high-dpi font-rendering, new X11-Warning

[xenodasein--- via Emacs development discussions.]

Dec 6, 2022, 11:39 by luangruo@yahoo.com:

> chad <yandros@gmail.com> writes:
>
>> I'm not up to doing the work myself, and obviously I'm not asking
>> anyone else to do so, but I wonder if anyone has looked at moving
>> emacs from Xlib to XCB?
>>
>
> Emacs already uses XCB where available and necessary for performance
> reasons.
>
> We will not "move" Emacs entirely to XCB, there is no point in that, and
> the Qt folks are still dealing with the consequences of such a short
> sighted decision even today.
>

Xlib uses XCB underneath anyway, what is this shortsightedness about?

Re: Questions regarding PGTK, high-dpi font-rendering, new X11-Warning

[Po Lu]

xenodasein@tutanota.de writes:

> Xlib uses XCB underneath anyway, what is this shortsightedness about?

Because you cannot give ownership of the event queue to Xlib if the
connection to the display was obtained through XCB.  As a result, Qt has
had to move from only using XCB to using both Xlib and XCB for the two
libraries that are much better than their XCB counterparts: the direct
rendering GLX library and the XInput client library.

You have to understand that Xlib uses XCB only as an underlying
transport.  It encodes all requests and reads events solely by itself,
with occasional hooks into XCB to synchronize i.e. the request serial
used (see the calls to xcb_take_socket.)  No matter whether or or not
_XSend, _XReadEvents, _XRead, _XReadPad or _XEatDataWords is implemented
on top of XCB, Xlib is still the only library reading events.

Re: Questions regarding PGTK, high-dpi font-rendering, new X11-Warning

[Manuel Giraud]

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

[...]

> For my own use the most important part is the support of both "toolkit"
> and "no-toolkit" scrollbars, since I find the no-toolkit scrollbars more
> useful than the toolkit ones.

I'm curious.  What do you find useful in the no-toolkit scroolbars
compared to the toolkit ones?
-- 
Manuel Giraud

Re: Questions regarding PGTK, high-dpi font-rendering, new X11-Warning

[Visuwesh]

[வியாழன் டிசம்பர் 01, 2022] Manuel Giraud wrote:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> [...]
>
>> For my own use the most important part is the support of both "toolkit"
>> and "no-toolkit" scrollbars, since I find the no-toolkit scrollbars more
>> useful than the toolkit ones.
>
> I'm curious.  What do you find useful in the no-toolkit scroolbars
> compared to the toolkit ones?

The fact that the direction of scrolling is dependent on the mouse
button and not the position of the click is already a net positive.  I
never worry about the position of the pointer this way; if the pointer
is on the text area, then I simply give it a gentle push using my
touchpad.

Re: Questions regarding PGTK, high-dpi font-rendering, new X11-Warning

[xenodasein--- via Emacs development discussions.]

Nov 30, 2022, 10:13 by luangruo@yahoo.com:

> xenodasein@tutanota.de writes:
>
>> To give less headaches to the users, why else.  Have one binary,
>> do it dynamically.
>>
>
> Then will you volunteer to write the code that makes it safe?  And keep
> it working for the next 5 or so years, at least?  Regardless of what the
> GTK developers decide to do in the meantime?
>

First of all thank you for not going straight for it's not possible /
no one would want that / it's the wrong way / etc.

I tried to suggest last year a way to draw your own window content
without GTK, Lars said great you can start from vanilla X build,
you and Eli on the other hand gave the impression that you found it
extremely undesirable.  Which brings me to the point that this seems
like a question of what do you want done instead of how to.  I am
myself not at the point where I could pull this off alone, but I'm
getting there.  Others would attempt at things like that if they found
any enthusiasm about I'm sure.

You must keep in mind that big contributions like this must have a
foundation if there will be any hope of them even happening.  For
example I can almost imagine the answers if I suggested separating
some translation units instead of using #ifdef's every five lines,
so I won't don't worry.  Or take as example the recent discussion on
macros.  It won't make much of a difference indeed if some line is
a function or a macro, issue is the resistance to even simple changes
like that; it implies the impossibility of something not as simple.
You can say no it doesn't, regardless that is the picture it paints.
I remember Eli requesting not to change the location of some function
on the grounds that it will now be harder to find where it is.

So what is my point, when some person asks why do I need to binaries,
instead of saying things like "why not" say we need more people to
work with C parts, that's all.

Re: Questions regarding PGTK, high-dpi font-rendering, new X11-Warning

[Po Lu]

xenodasein@tutanota.de writes:

> First of all thank you for not going straight for it's not possible /
> no one would want that / it's the wrong way / etc.

I only say that when it really is impossible, or wrong.  I see nothing
wrong in principle with making the PGTK build work well on X, but
whoever tries is in for a lot of pain, so I'm not volunteering.

> I tried to suggest last year a way to draw your own window content
> without GTK, Lars said great you can start from vanilla X build,
> you and Eli on the other hand gave the impression that you found it
> extremely undesirable.  Which brings me to the point that this seems
> like a question of what do you want done instead of how to.  I am
> myself not at the point where I could pull this off alone, but I'm
> getting there.  Others would attempt at things like that if they found
> any enthusiasm about I'm sure.

I've already explained why doing all graphics in Emacs will be a major
step backwards.  But let me reiterate:

  - it will not work well with X, especially not over slow network
    connections, because the only way to do that without special-casing
    X is to fedex the local back buffer contents to the X server every
    time something changes.

  - we will end up having to write a huge amount of code.  At least one
    set of code for each kind of graphics device: pseudo-color,
    static-color, and true-color.  And probably different sets of code
    every combination of pixmap format and visual.

    Each set of code will at least have to include, aside from
    trapezoid, line and arc rasterization, the ability to apply more or
    less arbitrary transformations to images, and alpha blending.

    All the code will need to be fast, which will be impossible to do
    portably: the best case on X is that the shared memory extension is
    usable, which will let Emacs avoid uploading huge amounts of image
    data to the X server upon each change.  The X server will still have
    to upload the shared memory to graphics memory every time Emacs
    tries to copy from the shared memory to the window, as it cannot
    know which parts of the shared memory has changed since the last
    upload.

  - it will not make Emacs more portable, because the vast majority of
    the complicated window system code involves interactions with the
    window system itself, and not computer graphics.  How do you propose
    to make, for example, xselect.c, portable, when the X selection API
    is fundamentally different from the clipboards or pasteboards found
    on different systems and exposed by toolkits, and Emacs has always
    exposed a very low level interface to Lisp via
    `selection-converter-alist', `x-get-selection', and related
    functions and variables?

> You must keep in mind that big contributions like this must have a
> foundation if there will be any hope of them even happening.

``this'' being?

> For example I can almost imagine the answers if I suggested separating
> some translation units instead of using #ifdef's every five lines, so
> I won't don't worry.

[...]

> Or take as example the recent discussion on macros.  It won't make
> much of a difference indeed if some line is a function or a macro,
> issue is the resistance to even simple changes like that; it implies
> the impossibility of something not as simple.

No, it does not.  What you're saying is that every time someone suggests
a change to Emacs, we should agree to it, even if the change is
absolutely pointless or even wrong.

The problem with that theory is self evident.

> I remember Eli requesting not to change the location of some function
> on the grounds that it will now be harder to find where it is.

Which is bad because..?

> So what is my point, when some person asks why do I need to binaries,
> instead of saying things like "why not" say we need more people to
> work with C parts, that's all.

What's the verb ``binaries''?

Re: Questions regarding PGTK, high-dpi font-rendering, new X11-Warning

[xenodasein--- via Emacs development discussions.]

I will try to answer the left out parts in a different mail.


Nov 30, 2022, 13:37 by luangruo@yahoo.com:

> xenodasein@tutanota.de writes:
>
>> First of all thank you for not going straight for it's not possible /
>> no one would want that / it's the wrong way / etc.
>>
>
> I only say that when it really is impossible, or wrong.  I see nothing
> wrong in principle with making the PGTK build work well on X, but
> whoever tries is in for a lot of pain, so I'm not volunteering.
>

This kind of belief in infallibility will make others less willing to
want to work with you if they don't have to.


>> You must keep in mind that big contributions like this must have a
>> foundation if there will be any hope of them even happening.
>>
>
> ``this'' being?
>

Having a single binary thing, or having own renderer.


>> I remember Eli requesting not to change the location of some function
>> on the grounds that it will now be harder to find where it is.
>>
>
> Which is bad because..?
>

I don't think it is worth for anyone to try to explain that as choices
are made, and apparent from the way you are asking that there is no
interest to reconsider anything.


>> So what is my point, when some person asks why do I need to binaries,
>> instead of saying things like "why not" say we need more people to
>> work with C parts, that's all.
>>
>
> What's the verb ``binaries''?
>

Meant to say "two binaries" pointing to Björn's complaint, in this
thread.

Re: Questions regarding PGTK, high-dpi font-rendering, new X11-Warning

[Po Lu]

xenodasein@tutanota.de writes:

> This kind of belief in infallibility will make others less willing to
> want to work with you if they don't have to.

[...]

> Having a single binary thing, or having own renderer.

[...]

> I don't think it is worth for anyone to try to explain that as choices
> are made, and apparent from the way you are asking that there is no
> interest to reconsider anything.

I see no point in taking this discussion any further, if you are only
capable of attacking the messenger, not the argument.

Re: Questions regarding PGTK, high-dpi font-rendering, new X11-Warning

[xenodasein--- via Emacs development discussions.]

Nov 30, 2022, 14:09 by luangruo@yahoo.com:

> xenodasein@tutanota.de writes:
>
>> This kind of belief in infallibility will make others less willing to
>> want to work with you if they don't have to.
>>
>
> [...]
>
>> Having a single binary thing, or having own renderer.
>>
>
> [...]
>
>> I don't think it is worth for anyone to try to explain that as choices
>> are made, and apparent from the way you are asking that there is no
>> interest to reconsider anything.
>>
>
> I see no point in taking this discussion any further, if you are only
> capable of attacking the messenger, not the argument.
>

Okay, I won't continue.  I can't help myself from asking though:
Which build target is it that have enough RAM to run Emacs but will
require implementing an X color table exactly?

My last suggestion is that before accusing anyone else of being wrong
or attacking you, try to stop yourself before writing things like:
"I've already explained why doing all graphics in Emacs will be a
major step backwards. But let me reiterate:"

Re: Questions regarding PGTK, high-dpi font-rendering, new X11-Warning

[Po Lu]

xenodasein@tutanota.de writes:

> Okay, I won't continue.  I can't help myself from asking though:
> Which build target is it that have enough RAM to run Emacs but will
> require implementing an X color table exactly?

What is an "X color table"?

Anyway, Emacs runs on all X11R6 servers, and most R5 and R4 ones.
Memory is not an issue because Emacs can run on some other machine.

Re: Questions regarding PGTK, high-dpi font-rendering, new X11-Warning

[Eli Zaretskii]

> Date: Wed, 30 Nov 2022 12:51:07 +0100 (CET)
> Cc: Björn Bidar <bjorn.bidar@thaodan.de>, emacs-devel@gnu.org
> From: xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
> 
> You must keep in mind that big contributions like this must have a
> foundation if there will be any hope of them even happening.  For
> example I can almost imagine the answers if I suggested separating
> some translation units instead of using #ifdef's every five lines,
> so I won't don't worry.  Or take as example the recent discussion on
> macros.  It won't make much of a difference indeed if some line is
> a function or a macro, issue is the resistance to even simple changes
> like that; it implies the impossibility of something not as simple.
> You can say no it doesn't, regardless that is the picture it paints.
> I remember Eli requesting not to change the location of some function
> on the grounds that it will now be harder to find where it is.

I don't understand how separating some translation units or
changing/replacing macros are related to development of any significant
feature in Emacs.  Any such significant new feature will have tons of new
code which you can factor as you see fit; if you do a clean job, no one will
argue with how you define functions and macros.  And in any such new code, I
don't see how it matters whether, say, MATRIX_ROW_BOTTOM_Y is a macro or a
function: you just use it and that's it.

IOW, adding important new features to Emacs doesn't need to change how we
use our infrastructure and whether something is a macro or not.  They are
completely orthogonal issues.  Our low-level functions and macros don't
prevent anyone from adding features, and in case a function or a macro
really needs to be refactored or accept additional arguments to enable a new
feature, no one will object (again, provided that you do a clean job).  For
a recent example, see treesit.c.

So this rant of your is completely unclear to me.

Re: Questions regarding PGTK, high-dpi font-rendering, new X11-Warning

[xenodasein--- via Emacs development discussions.]

Nov 30, 2022, 16:23 by eliz@gnu.org:

> I don't understand how separating some translation units or
> changing/replacing macros are related to development of any significant
> feature in Emacs.  Any such significant new feature will have tons of new
> code which you can factor as you see fit; if you do a clean job, no one will
> argue with how you define functions and macros.  And in any such new code, I
> don't see how it matters whether, say, MATRIX_ROW_BOTTOM_Y is a macro or a
> function: you just use it and that's it.
>
> IOW, adding important new features to Emacs doesn't need to change how we
> use our infrastructure and whether something is a macro or not.  They are
> completely orthogonal issues.  Our low-level functions and macros don't
> prevent anyone from adding features, and in case a function or a macro
> really needs to be refactored or accept additional arguments to enable a new
> feature, no one will object (again, provided that you do a clean job).  For
> a recent example, see treesit.c.
>
> So this rant of your is completely unclear to me.
>

I also repeatedly say adding completely new things like treesitter
is encouraged, because someone(tm) will maintain them supposedly.
Problem is tackling what's already in there, which happens almost
never compared the former.  Overhauling display is going to require
that, I'd love to see how it would go without touching the
infrastructure or without the friction I've seen with simple mention
of it before even changing code.  If someone attempts that it would
make it simpler to believe you, because I am discouraged to take
the first step.

Re: Questions regarding PGTK, high-dpi font-rendering, new X11-Warning

[Eli Zaretskii]

> Date: Wed, 30 Nov 2022 17:56:39 +0100 (CET)
> From: xenodasein@tutanota.de
> Cc: luangruo@yahoo.com, bjorn.bidar@thaodan.de, emacs-devel@gnu.org
> 
> I also repeatedly say adding completely new things like treesitter
> is encouraged, because someone(tm) will maintain them supposedly.
> Problem is tackling what's already in there, which happens almost
> never compared the former.

What do you mean by "tackling"? what is its purpose?

> Overhauling display is going to require that, I'd love to see how it would
> go without touching the infrastructure or without the friction I've seen
> with simple mention of it before even changing code.  If someone attempts
> that it would make it simpler to believe you, because I am discouraged to
> take the first step.

If someone redesigns and reimplements the display engine (which, btw, will
be very welcome from where I stand), the result will be a complete rewrite
of the relevant files, i.e. addition of new files and an almost total
tossing of the old files.  I know that because I was there when Gerd did
that the last time.

IOW, making such changes has very little to do with what is present, it has
everything to do with introducing new files, functions, macros, and bugs.

Of course, even writing completely new code needs to observe our conventions
and coding style: Lisp primitives are defined using DEFUN, variables using
DEFVAR_LISP etc., symbols are defined using DEFSYM, and there are protocols
for initializing variables during the dumping and at startup etc.  And your
code and its design must be clean.  But show me a project that doesn't have
such conventions, and I will show you a dead project.

Re: Questions regarding PGTK, high-dpi font-rendering, new X11-Warning

[Björn Bidar]

Po Lu <luangruo@yahoo.com> writes:

>> Which clipboard issues? It's working just fine for me.
>
> Try copying a large file into Emacs.  One such file would be
> src/xterm.c.

Just did that C-w from one buffer and then C-y into the other,
everything worked as expect no issues.

GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.35,
cairo version 1.17.6) of 2022-12-05

C-h v system-configuration-features RET:
"ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON LCMS2 LIBOTF LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PGTK PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM GTK3 ZLIB"

Re: Questions regarding PGTK, high-dpi font-rendering, new X11-Warning

[Po Lu]

Björn Bidar <bjorn.bidar@thaodan.de> writes:

> Just did that C-w from one buffer and then C-y into the other,
> everything worked as expect no issues.

That doesn't utilize the clipboard at all.  Try copying the file from
Emacs into gedit, and then vice versa.

Re: Re: Questions regarding PGTK, high-dpi font-rendering, new X11-Warning

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 642 bytes --]

Po Lu <luangruo@yahoo.com> writes:

> Why? There is already a perfectly good X build, so doing so would be a
> waste of our energy.

Let's say it's a "reasonable" build. The N times the Emacs window is
resized and moved around before it lands where you want it to be is
something that should be looked into. And that doesn't happen on the pgtk
build (at least for me-TM).

My .2 cents, /PA

-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

[-- Attachment #2: Type: text/html, Size: 1055 bytes --]

Re: Questions regarding PGTK, high-dpi font-rendering, new X11-Warning

[Po Lu]

Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:

> Let's say it's a "reasonable" build. The N times the Emacs window is
> resized and moved around before it lands where you want it to be is
> something that should be looked into. And that doesn't happen on the
> pgtk build (at least for me-TM).

That's a bug in Cairo.  GTK works around it by using a completely
different settings mechanism that AFAIK only works on GNOME.

Re: Questions regarding PGTK, high-dpi font-rendering, new X11-Warning

[Björn Bidar]

Po Lu <luangruo@yahoo.com> writes:

> Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:
>
>> Let's say it's a "reasonable" build. The N times the Emacs window is
>> resized and moved around before it lands where you want it to be is
>> something that should be looked into. And that doesn't happen on the
>> pgtk build (at least for me-TM).
>
> That's a bug in Cairo.  GTK works around it by using a completely
> different settings mechanism that AFAIK only works on GNOME.

Did you test Kwin? I'm not sure if the bug happens on my devices but I
haven't experienced it.

Br,

Björn