* bug#58459: Getting a fresh emacs session with no customisation
@ 2022-10-12 0:09 uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-12 9:51 ` Stefan Kangas
0 siblings, 1 reply; 34+ messages in thread
From: uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-12 0:09 UTC (permalink / raw)
To: 58459
I am finding it extremely difficult to get a fresh emacs configuration. Even after removing
my "~/.emacs" file and even with "emacs -q" which should not load any init file, I get a black
background when I do "emacs -q". With customize-themes not showing that any theme is selected.
Even the command
emacs -q --no-site-file --no-splash
gives me a black background.
But "emacs -Q" gives me a white background.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#58459: Getting a fresh emacs session with no customisation
2022-10-12 0:09 bug#58459: Getting a fresh emacs session with no customisation uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-10-12 9:51 ` Stefan Kangas
2022-10-12 12:52 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 34+ messages in thread
From: Stefan Kangas @ 2022-10-12 9:51 UTC (permalink / raw)
To: uzibalqa, 58459
tags 58459 notabug
close 58459
thanks
uzibalqa via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@gnu.org> writes:
> I am finding it extremely difficult to get a fresh emacs configuration. Even after removing
> my "~/.emacs" file and even with "emacs -q" which should not load any init file, I get a black
> background when I do "emacs -q". With customize-themes not showing that any theme is selected.
>
> Even the command
>
> emacs -q --no-site-file --no-splash
>
> gives me a black background.
>
> But "emacs -Q" gives me a white background.
So you have some X resources that are causing you trouble. See the
documentation for the -Q flag.
Try this to see:
xrdb -query -all|grep -i emacs
And then unset those resources.
This is a support question and not a bug, so I'm closing this.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#58459: Getting a fresh emacs session with no customisation
2022-10-12 9:51 ` Stefan Kangas
@ 2022-10-12 12:52 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-12 12:56 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 34+ messages in thread
From: uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-12 12:52 UTC (permalink / raw)
To: Stefan Kangas; +Cc: 58459
------- Original Message -------
On Wednesday, October 12th, 2022 at 9:51 AM, Stefan Kangas <stefankangas@gmail.com> wrote:
> tags 58459 notabug
> close 58459
> thanks
>
> uzibalqa via "Bug reports for GNU Emacs, the Swiss army knife of text
> editors" bug-gnu-emacs@gnu.org writes:
>
> > I am finding it extremely difficult to get a fresh emacs configuration. Even after removing
> > my "~/.emacs" file and even with "emacs -q" which should not load any init file, I get a black
> > background when I do "emacs -q". With customize-themes not showing that any theme is selected.
> >
> > Even the command
> >
> > emacs -q --no-site-file --no-splash
> >
> > gives me a black background.
> >
> > But "emacs -Q" gives me a white background.
>
>
> So you have some X resources that are causing you trouble. See the
> documentation for the -Q flag.
>
> Try this to see:
>
> xrdb -query -all|grep -i emacs
>
> And then unset those resources.
>
> This is a support question and not a bug, so I'm closing this.
Why is emacs not taking care of these EMACS generated X-Resources?
You may claim it is not a bug, but what would be the usefelness when
user wants a fresh restart but has to go through all this torture
to find out what is going on. It is definitely not for the novice
to fix this.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#58459: Getting a fresh emacs session with no customisation
2022-10-12 12:52 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-10-12 12:56 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-12 16:23 ` Stefan Kangas
0 siblings, 1 reply; 34+ messages in thread
From: uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-12 12:56 UTC (permalink / raw)
To: uzibalqa; +Cc: 58459, Stefan Kangas
------- Original Message -------
On Wednesday, October 12th, 2022 at 12:52 PM, uzibalqa via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org> wrote:
> ------- Original Message -------
> On Wednesday, October 12th, 2022 at 9:51 AM, Stefan Kangas stefankangas@gmail.com wrote:
>
>
>
> > tags 58459 notabug
> > close 58459
> > thanks
> >
> > uzibalqa via "Bug reports for GNU Emacs, the Swiss army knife of text
> > editors" bug-gnu-emacs@gnu.org writes:
> >
> > > I am finding it extremely difficult to get a fresh emacs configuration. Even after removing
> > > my "~/.emacs" file and even with "emacs -q" which should not load any init file, I get a black
> > > background when I do "emacs -q". With customize-themes not showing that any theme is selected.
> > >
> > > Even the command
> > >
> > > emacs -q --no-site-file --no-splash
> > >
> > > gives me a black background.
> > >
> > > But "emacs -Q" gives me a white background.
> >
> > So you have some X resources that are causing you trouble. See the
> > documentation for the -Q flag.
> >
> > Try this to see:
> >
> > xrdb -query -all|grep -i emacs
> >
> > And then unset those resources.
> >
> > This is a support question and not a bug, so I'm closing this.
>
>
> Why is emacs not taking care of these EMACS generated X-Resources?
> You may claim it is not a bug, but what would be the usefelness when
> user wants a fresh restart but has to go through all this torture
> to find out what is going on. It is definitely not for the novice
> to fix this.
How can one unset those resources?
--------------------------------------
This is the result of xrdb
xrdb -query -all | grep -i emacs
Emacs*Background: #000000
Emacs*Dialog*background: #000000
Emacs*Dialog*foreground: #ffffff
Emacs*Foreground: #ffffff
Emacs*XlwScrollBar.Background: #000000
Emacs*XlwScrollBar.Foreground: #ffffff
Emacs*backgroundToolBarColor: #000000
Emacs*bottomToolBarShadowColor: #000000
Emacs*menubar*background: #000000
Emacs*menubar*foreground: #ffffff
Emacs*popup*Background: #000000
Emacs*popup*Foreground: #ffffff
Emacs*topToolBarShadowColor: #000000
Emacs.default.attributeBackground: #000000
Emacs.default.attributeForeground: #ffffff
Emacs.mode-line.attributeForeground: #ffffff
Emacs.scroll-bar.attributeBackground: #000000
Emacs.scroll-bar.attributeForeground: #ffffff
Emacs.tool-bar.attributeBackground: #000000
Emacs.tool-bar.attributeForeground: #ffffff
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#58459: Getting a fresh emacs session with no customisation
2022-10-12 12:56 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-10-12 16:23 ` Stefan Kangas
2022-10-12 17:30 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 34+ messages in thread
From: Stefan Kangas @ 2022-10-12 16:23 UTC (permalink / raw)
To: uzibalqa; +Cc: 58459
uzibalqa <uzibalqa@proton.me> writes:
>> Why is emacs not taking care of these EMACS generated X-Resources?
I don't think Emacs would set these resources. My guess it's specific
to your setup, or your GNU/Linux distribution or something.
>> You may claim it is not a bug, but what would be the usefelness when
>> user wants a fresh restart but has to go through all this torture
>> to find out what is going on. It is definitely not for the novice
>> to fix this.
It's a general feature on X that we happen to support. It's not a bug.
> How can one unset those resources?
If you read `man xrdb', you will find:
xrdb -remove
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#58459: Getting a fresh emacs session with no customisation
2022-10-12 16:23 ` Stefan Kangas
@ 2022-10-12 17:30 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-12 21:11 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 34+ messages in thread
From: uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-12 17:30 UTC (permalink / raw)
To: Stefan Kangas; +Cc: 58459
------- Original Message -------
On Wednesday, October 12th, 2022 at 4:23 PM, Stefan Kangas <stefankangas@gmail.com> wrote:
> uzibalqa uzibalqa@proton.me writes:
>
> > > Why is emacs not taking care of these EMACS generated X-Resources?
>
>
> I don't think Emacs would set these resources. My guess it's specific
> to your setup, or your GNU/Linux distribution or something.
>
> > > You may claim it is not a bug, but what would be the usefelness when
> > > user wants a fresh restart but has to go through all this torture
> > > to find out what is going on. It is definitely not for the novice
> > > to fix this.
>
>
> It's a general feature on X that we happen to support. It's not a bug.
>
> > How can one unset those resources?
>
>
> If you read `man xrdb', you will find:
>
> xrdb -remove
Fine, let me agree it is not a bug. Because emacs supports some general features on X,
and we know that this problem might occur, could emacs also support the clearance of
EMACS X-Resources. Particularly for those not technically aware, it will solve them a
whole lot of problems.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#58459: Getting a fresh emacs session with no customisation
2022-10-12 17:30 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-10-12 21:11 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-12 22:47 ` Phil Sainty
0 siblings, 1 reply; 34+ messages in thread
From: uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-12 21:11 UTC (permalink / raw)
To: uzibalqa; +Cc: 58459, Stefan Kangas
------- Original Message -------
On Wednesday, October 12th, 2022 at 5:30 PM, uzibalqa via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org> wrote:
> ------- Original Message -------
> On Wednesday, October 12th, 2022 at 4:23 PM, Stefan Kangas stefankangas@gmail.com wrote:
>
>
>
> > uzibalqa uzibalqa@proton.me writes:
> >
> > > > Why is emacs not taking care of these EMACS generated X-Resources?
> >
> > I don't think Emacs would set these resources. My guess it's specific
> > to your setup, or your GNU/Linux distribution or something.
> >
> > > > You may claim it is not a bug, but what would be the usefelness when
> > > > user wants a fresh restart but has to go through all this torture
> > > > to find out what is going on. It is definitely not for the novice
> > > > to fix this.
> >
> > It's a general feature on X that we happen to support. It's not a bug.
> >
> > > How can one unset those resources?
> >
> > If you read `man xrdb', you will find:
> >
> > xrdb -remove
>
>
> Fine, let me agree it is not a bug. Because emacs supports some general features on X,
> and we know that this problem might occur, could emacs also support the clearance of
> EMACS X-Resources. Particularly for those not technically aware, it will solve them a
> whole lot of problems.
I an using Trisquel 9. I have not personally added the Emacs X-Resourses. I do not even have
the files "~/.Xresources" or "~/.Xdefaults". "xrdb -remove" gets rid of the entire RESOURCE
string, ignoring any input or arguments.
I am continually amazed how unreactive emacs maintainers can be to users. Either shaming them,
make them look stupid, but then months or years later, it gets recognised they were right all along.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#58459: Getting a fresh emacs session with no customisation
2022-10-12 21:11 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-10-12 22:47 ` Phil Sainty
2022-10-12 23:16 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 34+ messages in thread
From: Phil Sainty @ 2022-10-12 22:47 UTC (permalink / raw)
To: uzibalqa; +Cc: 58459, Stefan Kangas
On 2022-10-13 10:11, uzibalqa wrote:
> I am continually amazed how unreactive emacs maintainers can be to
> users. Either shaming them, make them look stupid
Wow? This discussion has been between you and Stefan Kangas, and at
no point has Stefan been anything other than polite and informative!
> but then months or years later, it gets recognised they were right
> all along.
This is how X resources have always worked (for decades) -- I can't
imagine them changing, and Emacs provides ways for you to inhibit
them (or indeed add to them).
You said you saw the problem with this:
emacs -q --no-site-file --no-splash
but not with "emacs -Q".
The documentation says:
‘-Q’
‘--quick’
Start Emacs with minimum customizations. This is similar to using
‘-q’, ‘--no-site-file’, ‘--no-site-lisp’, ‘--no-x-resources’, and
‘--no-splash’ together.
So the difference that using -Q made was equivalent to adding these:
--no-site-lisp
--no-x-resources
And as discussed, it's specifically this:
‘--no-x-resources’
Do not load X resources. You can also achieve this effect by
setting the variable ‘inhibit-x-resources’ to ‘t’ in your
initialization file (*note Resources::).
So you can use either of those solutions if you don't wish to change
the X resources configured on your system.
-Phil
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#58459: Getting a fresh emacs session with no customisation
2022-10-12 22:47 ` Phil Sainty
@ 2022-10-12 23:16 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-13 1:14 ` Stefan Kangas
2022-10-13 10:30 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 2 replies; 34+ messages in thread
From: uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-12 23:16 UTC (permalink / raw)
To: Phil Sainty; +Cc: 58459, Stefan Kangas
------- Original Message -------
On Wednesday, October 12th, 2022 at 10:47 PM, Phil Sainty <psainty@orcon.net.nz> wrote:
> On 2022-10-13 10:11, uzibalqa wrote:
>
> > I am continually amazed how unreactive emacs maintainers can be to
> > users. Either shaming them, make them look stupid
>
>
> Wow? This discussion has been between you and Stefan Kangas, and at
> no point has Stefan been anything other than polite and informative!
Early on in the discussion, the response was immediately "notabug
close thanks". But perhaps you are right and I am being excessive.
Nevertheless, I am yet to be convinced how this resource thing is
straightforward.
> > but then months or years later, it gets recognised they were right
> > all along.
>
>
> This is how X resources have always worked (for decades) -- I can't
> imagine them changing, and Emacs provides ways for you to inhibit
> them (or indeed add to them).
Looks that "internal-set-lisp-face-attribute-from-resource" is doing the work.
So if emacs does not not even find an emacs init file, why does it start launching
them.
> You said you saw the problem with this:
>
> emacs -q --no-site-file --no-splash
>
> but not with "emacs -Q".
>
> The documentation says:
>
> ‘-Q’
> ‘--quick’
> Start Emacs with minimum customizations. This is similar to using
> ‘-q’, ‘--no-site-file’, ‘--no-site-lisp’, ‘--no-x-resources’, and
> ‘--no-splash’ together.
>
> So the difference that using -Q made was equivalent to adding these:
>
> --no-site-lisp
> --no-x-resources
>
> And as discussed, it's specifically this:
>
> ‘--no-x-resources’
> Do not load X resources. You can also achieve this effect by
> setting the variable ‘inhibit-x-resources’ to ‘t’ in your
> initialization file (*note Resources::).
>
> So you can use either of those solutions if you don't wish to change
> the X resources configured on your system.
>
> -Phil
Something must be going on, perhaps in the distro or desktop environment that could be
using something outside the traditional X11 approach to loading Xresources. Or something
else.
I am using one of the Official Gnu Distributions (Trisquel 9). These systems should work
well together with Gnu Programs. At least, it is always said things are planned to be this
way.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#58459: Getting a fresh emacs session with no customisation
2022-10-12 23:16 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-10-13 1:14 ` Stefan Kangas
2022-10-13 2:02 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-13 10:30 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 1 reply; 34+ messages in thread
From: Stefan Kangas @ 2022-10-13 1:14 UTC (permalink / raw)
To: uzibalqa, Phil Sainty; +Cc: 58459
uzibalqa <uzibalqa@proton.me> writes:
>> > I am continually amazed how unreactive emacs maintainers can be to
>> > users. Either shaming them, make them look stupid
>>
>> Wow? This discussion has been between you and Stefan Kangas, and at
>> no point has Stefan been anything other than polite and informative!
>
> Early on in the discussion, the response was immediately "notabug
> close thanks". But perhaps you are right and I am being excessive.
> Nevertheless, I am yet to be convinced how this resource thing is
> straightforward.
Please do not take us closing bugs personally. We have thousands of
open bugs, and we try to handle them based on objective criteria.
>> > but then months or years later, it gets recognised they were right
>> > all along.
X resources are of course a rather esoteric feature these days, to most
users. There's a reason they're not used all that often any more. But
we will never stop supporting them, as this stuff has been that way for
decades.
> Looks that "internal-set-lisp-face-attribute-from-resource" is doing the work.
> So if emacs does not not even find an emacs init file, why does it start launching
> them.
Again, I think Emacs behaves correctly here. It's good to hear that
using `inhibit-x-resources' fixes your problem.
> Something must be going on, perhaps in the distro or desktop environment that could be
> using something outside the traditional X11 approach to loading Xresources. Or something
> else.
>
> I am using one of the Official Gnu Distributions (Trisquel 9). These systems should work
> well together with Gnu Programs. At least, it is always said things are planned to be this
> way.
Then you should investigate why this happens in your environment.
If you find any bugs, you should report them to the appropriate people.
If you find that it is indeed a bug in Trisquel, then it is not correct
to report it here, as we can't do anything about it.
But note that it is good form to make sure that there is a bug before
reporting one. I would ask in some support forum first.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#58459: Getting a fresh emacs session with no customisation
2022-10-13 1:14 ` Stefan Kangas
@ 2022-10-13 2:02 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-13 3:01 ` Stefan Kangas
2022-10-13 10:22 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 2 replies; 34+ messages in thread
From: uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-13 2:02 UTC (permalink / raw)
To: Stefan Kangas; +Cc: Phil Sainty, 58459
------- Original Message -------
On Thursday, October 13th, 2022 at 1:14 AM, Stefan Kangas <stefankangas@gmail.com> wrote:
> uzibalqa uzibalqa@proton.me writes:
>
> > > > I am continually amazed how unreactive emacs maintainers can be to
> > > > users. Either shaming them, make them look stupid
> > >
> > > Wow? This discussion has been between you and Stefan Kangas, and at
> > > no point has Stefan been anything other than polite and informative!
> >
> > Early on in the discussion, the response was immediately "notabug
> > close thanks". But perhaps you are right and I am being excessive.
> > Nevertheless, I am yet to be convinced how this resource thing is
> > straightforward.
>
>
> Please do not take us closing bugs personally. We have thousands of
> open bugs, and we try to handle them based on objective criteria.
Fine, but when this happens on Trisquel, then it is a topic of concern. Aren't
maintainers supposed to work together? Most times everybody works independently
with almost no concern or collaboration.
> > > > but then months or years later, it gets recognised they were right
> > > > all along.
>
>
> X resources are of course a rather esoteric feature these days, to most
> users. There's a reason they're not used all that often any more. But
> we will never stop supporting them, as this stuff has been that way for
> decades.
>
> > Looks that "internal-set-lisp-face-attribute-from-resource" is doing the work.
> > So if emacs does not not even find an emacs init file, why does it start launching
> > them.
>
>
> Again, I think Emacs behaves correctly here. It's good to hear that
> using `inhibit-x-resources' fixes your problem.
I wonder the rational behind considering x-resources as authoritative.
As you mentioned, these days x-resources are a rather esoteric feature.
Your design should be the other way round. With a flag `enforce-x-resources'.
So one always gets vanilla emacs with no init file, or when the init file
does nothing, or something goes wrong. It is very easy to make an init file
fail when one is writing emacs functionalities and packages.
> > Something must be going on, perhaps in the distro or desktop environment that could be
> > using something outside the traditional X11 approach to loading Xresources. Or something
> > else.
> >
> > I am using one of the Official Gnu Distributions (Trisquel 9). These systems should work
> > well together with Gnu Programs. At least, it is always said things are planned to be this
> > way.
>
>
> Then you should investigate why this happens in your environment.
> If you find any bugs, you should report them to the appropriate people.
> If you find that it is indeed a bug in Trisquel, then it is not correct
> to report it here, as we can't do anything about it.
Will inform Ruben about it.
> But note that it is good form to make sure that there is a bug before
> reporting one. I would ask in some support forum first.
It is also an emacs bug from my point of view. Especially when you confirm
that x-resources are not used all that often anymore.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#58459: Getting a fresh emacs session with no customisation
2022-10-13 2:02 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-10-13 3:01 ` Stefan Kangas
2022-10-13 15:48 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-13 10:22 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 1 reply; 34+ messages in thread
From: Stefan Kangas @ 2022-10-13 3:01 UTC (permalink / raw)
To: uzibalqa; +Cc: Phil Sainty, 58459
uzibalqa <uzibalqa@proton.me> writes:
> Fine, but when this happens on Trisquel, then it is a topic of concern. Aren't
> maintainers supposed to work together? Most times everybody works independently
> with almost no concern or collaboration.
That's an unfair assessment. This is not a bug in Emacs, so there is no
need for us to collaborate with anyone.
Bugs should obviously be reported to the people that can fix them,
that's all.
> It is also an emacs bug from my point of view. Especially when you confirm
> that x-resources are not used all that often anymore.
I think we will have to agree to disagree, then.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#58459: Getting a fresh emacs session with no customisation
2022-10-13 3:01 ` Stefan Kangas
@ 2022-10-13 15:48 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 34+ messages in thread
From: uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-13 15:48 UTC (permalink / raw)
To: Stefan Kangas; +Cc: Phil Sainty, 58459
------- Original Message -------
On Thursday, October 13th, 2022 at 3:01 AM, Stefan Kangas <stefankangas@gmail.com> wrote:
> uzibalqa uzibalqa@proton.me writes:
>
> > Fine, but when this happens on Trisquel, then it is a topic of concern. Aren't
> > maintainers supposed to work together? Most times everybody works independently
> > with almost no concern or collaboration.
>
>
> That's an unfair assessment. This is not a bug in Emacs, so there is no
> need for us to collaborate with anyone.
>
> Bugs should obviously be reported to the people that can fix them,
> that's all.
>
> > It is also an emacs bug from my point of view. Especially when you confirm
> > that x-resources are not used all that often anymore.
>
>
> I think we will have to agree to disagree, then.
I have now done
xrdb -query -all | grep -i emacs
Which gives no matches. I also introduced an empty ~/.Xresources
Yet I still do not get Vanilla Emacs.
You continue to disagree ???
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#58459: Getting a fresh emacs session with no customisation
2022-10-13 2:02 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-13 3:01 ` Stefan Kangas
@ 2022-10-13 10:22 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-13 12:09 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 1 reply; 34+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-13 10:22 UTC (permalink / raw)
To: uzibalqa; +Cc: Phil Sainty, 58459, Stefan Kangas
uzibalqa <uzibalqa@proton.me> writes:
> Fine, but when this happens on Trisquel, then it is a topic of concern. Aren't
> maintainers supposed to work together? Most times everybody works independently
> with almost no concern or collaboration.
Users actually want the desktop environment to set resources that make
applications match the system stylesheet.
If you don't, remove the resources. We cannot make decisions for the
Trisquel developers.
> I wonder the rational behind considering x-resources as authoritative.
> As you mentioned, these days x-resources are a rather esoteric feature.
> Your design should be the other way round. With a flag `enforce-x-resources'.
> So one always gets vanilla emacs with no init file, or when the init file
> does nothing, or something goes wrong. It is very easy to make an init file
> fail when one is writing emacs functionalities and packages.
Emacs is an X program, and good X programs respect resources set in the
usual locations. It is a decades old convention.
> It is also an emacs bug from my point of view. Especially when you confirm
> that x-resources are not used all that often anymore.
No.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#58459: Getting a fresh emacs session with no customisation
2022-10-13 10:22 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-10-13 12:09 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-13 12:19 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-13 15:47 ` Eli Zaretskii
0 siblings, 2 replies; 34+ messages in thread
From: uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-13 12:09 UTC (permalink / raw)
To: Po Lu; +Cc: Phil Sainty, 58459, Stefan Kangas
------- Original Message -------
On Thursday, October 13th, 2022 at 10:22 AM, Po Lu <luangruo@yahoo.com> wrote:
> uzibalqa uzibalqa@proton.me writes:
>
> > Fine, but when this happens on Trisquel, then it is a topic of concern. Aren't
> > maintainers supposed to work together? Most times everybody works independently
> > with almost no concern or collaboration.
>
>
> Users actually want the desktop environment to set resources that make
> applications match the system stylesheet.
>
> If you don't, remove the resources. We cannot make decisions for the
> Trisquel developers.
>
> > I wonder the rational behind considering x-resources as authoritative.
> > As you mentioned, these days x-resources are a rather esoteric feature.
> > Your design should be the other way round. With a flag `enforce-x-resources'.
> > So one always gets vanilla emacs with no init file, or when the init file
> > does nothing, or something goes wrong. It is very easy to make an init file
> > fail when one is writing emacs functionalities and packages.
>
>
> Emacs is an X program, and good X programs respect resources set in the
> usual locations. It is a decades old convention.
You can't even tell me which process is producing them and where.
> > It is also an emacs bug from my point of view. Especially when you confirm
> > that x-resources are not used all that often anymore.
> No.
Emacs should take the user's setting in the init file rather than override them
with bullshit that you reckon has authority.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#58459: Getting a fresh emacs session with no customisation
2022-10-13 12:09 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-10-13 12:19 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-13 12:52 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-13 15:47 ` Eli Zaretskii
1 sibling, 1 reply; 34+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-13 12:19 UTC (permalink / raw)
To: uzibalqa; +Cc: Phil Sainty, 58459, Stefan Kangas
uzibalqa <uzibalqa@proton.me> writes:
> You can't even tell me which process is producing them and where.
Because I don't know? How would I know what is installed on your
system?
> Emacs should take the user's setting in the init file rather than override them
> with bullshit that you reckon has authority.
Did you bother to read the X(7) manual page at all? If not, I suggest
grabbing a copy off here:
https://www.x.org/archive/X11R7.7/doc/man/man7/X.7.xhtml#heading14
When you run Emacs with _nothing_ in your init file, there will be
nothing there to take priority over X resources.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#58459: Getting a fresh emacs session with no customisation
2022-10-13 12:19 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-10-13 12:52 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-13 13:14 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 34+ messages in thread
From: uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-13 12:52 UTC (permalink / raw)
To: Po Lu; +Cc: Phil Sainty, 58459, Stefan Kangas
------- Original Message -------
On Thursday, October 13th, 2022 at 12:19 PM, Po Lu <luangruo@yahoo.com> wrote:
> uzibalqa uzibalqa@proton.me writes:
>
> > You can't even tell me which process is producing them and where.
>
>
> Because I don't know? How would I know what is installed on your
> system?
Right. And I do not know either whatever my system has done to impose
some x-resources that emacs is taking as authority. Suppose I had set
some of those resources myself and want to use them, then I should specify
them like I do with my init file.
But things are working the other way round. Things get messed up, then have
to figure out what produced it, thing gets too complicated beyond what I consciously
did, then emacs uses them. Does a user have control this way? Of course not.
> > Emacs should take the user's setting in the init file rather than override them
> > with bullshit that you reckon has authority.
>
>
> Did you bother to read the X(7) manual page at all? If not, I suggest
> grabbing a copy off here:
>
> https://www.x.org/archive/X11R7.7/doc/man/man7/X.7.xhtml#heading14
>
> When you run Emacs with nothing in your init file, there will be
> nothing there to take priority over X resources.
My challenge in why emacs is taking authority from x-resources. Rather than
firing vanilla emacs with some properly defined face with good accessibility.
If one is sure that he has set x-resources as he want, one can specify either
in the init file or in the command line where that information is. Currently
something sets the x-resources, nobody knows what (certainly not the user in
this case), and then emacs imposes whatever there is. It is a bad strategy.
If emacs maintainers are actually so smart, how long is it going to take exactly
for vanilla emacs to start using some well defined accessibility metrics such
as modus-themes, so that the maximum number of users can comfortably use it.
I want you to look at this as a subject, not as an emotional thing. Because then
you will not look at it the right way. Which people have already started doing.
The end seems to be always the same. Statements that I am this bad man, and this
other one, and so forth.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#58459: Getting a fresh emacs session with no customisation
2022-10-13 12:52 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-10-13 13:14 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-13 13:27 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-13 13:56 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 2 replies; 34+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-13 13:14 UTC (permalink / raw)
To: uzibalqa; +Cc: Phil Sainty, 58459, Stefan Kangas
uzibalqa <uzibalqa@proton.me> writes:
> But things are working the other way round. Things get messed up, then have
> to figure out what produced it, thing gets too complicated beyond what I consciously
> did, then emacs uses them. Does a user have control this way? Of course not.
You have control: inhibit-x-resources.
> My challenge in why emacs is taking authority from x-resources. Rather than
> firing vanilla emacs with some properly defined face with good accessibility.
[...]
> If emacs maintainers are actually so smart, how long is it going to take exactly
> for vanilla emacs to start using some well defined accessibility metrics such
> as modus-themes, so that the maximum number of users can comfortably use it.
Take the complaint to the Trisquel or MATE developers.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#58459: Getting a fresh emacs session with no customisation
2022-10-13 13:14 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-10-13 13:27 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-13 14:19 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-13 13:56 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 1 reply; 34+ messages in thread
From: uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-13 13:27 UTC (permalink / raw)
To: Po Lu; +Cc: Phil Sainty, 58459, Stefan Kangas
------- Original Message -------
On Thursday, October 13th, 2022 at 1:14 PM, Po Lu <luangruo@yahoo.com> wrote:
> uzibalqa uzibalqa@proton.me writes:
>
> > But things are working the other way round. Things get messed up, then have
> > to figure out what produced it, thing gets too complicated beyond what I consciously
> > did, then emacs uses them. Does a user have control this way? Of course not.
>
>
> You have control: inhibit-x-resources.
Sure, but do you realise how long it took to identify the culprit after the
enforced settings did not even allow me to see the mode-line because of
terrible contrast. Make things easy for users, rather than even more difficult.
Who understands how Xresources works when a user does not even have a user-level
configuration dotfile in "~/.Xresources".
> > My challenge in why emacs is taking authority from x-resources. Rather than
> > firing vanilla emacs with some properly defined face with good accessibility.
>
>
> [...]
>
> > If emacs maintainers are actually so smart, how long is it going to take exactly
> > for vanilla emacs to start using some well defined accessibility metrics such
> > as modus-themes, so that the maximum number of users can comfortably use it.
>
>
> Take the complaint to the Trisquel or MATE developers.
The complaint is about the problems associated from taking instructions from x-resources.
The problem is simply shifted around to the Trisquel or MATE developers, rather than
continuing to rely on a likely broken x-resource database.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#58459: Getting a fresh emacs session with no customisation
2022-10-13 13:27 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-10-13 14:19 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-13 14:36 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 34+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-13 14:19 UTC (permalink / raw)
To: uzibalqa; +Cc: Phil Sainty, 58459, Stefan Kangas
uzibalqa <uzibalqa@proton.me> writes:
> Sure, but do you realise how long it took to identify the culprit after the
> enforced settings did not even allow me to see the mode-line because of
> terrible contrast. Make things easy for users, rather than even more difficult.
It is easy enough. It is documented in the Emacs manual and in
countless pieces of system documentation.
> Who understands how Xresources works when a user does not even have a user-level
> configuration dotfile in "~/.Xresources".
Everyone who uses X is expected to have read the relevant documentation.
What resources are, and where they are found, is even explained in the
comp.windows.x FAQ, which is where you should look first for help with
any problems.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#58459: Getting a fresh emacs session with no customisation
2022-10-13 14:19 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-10-13 14:36 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 34+ messages in thread
From: uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-13 14:36 UTC (permalink / raw)
To: Po Lu; +Cc: Phil Sainty, 58459, Stefan Kangas
Sent with Proton Mail secure email.
------- Original Message -------
On Thursday, October 13th, 2022 at 2:19 PM, Po Lu <luangruo@yahoo.com> wrote:
> uzibalqa uzibalqa@proton.me writes:
>
> > Sure, but do you realise how long it took to identify the culprit after the
> > enforced settings did not even allow me to see the mode-line because of
> > terrible contrast. Make things easy for users, rather than even more difficult.
>
>
> It is easy enough. It is documented in the Emacs manual and in
> countless pieces of system documentation.
>
> > Who understands how Xresources works when a user does not even have a user-level
> > configuration dotfile in "~/.Xresources".
>
>
> Everyone who uses X is expected to have read the relevant documentation.
> What resources are, and where they are found, is even explained in the
> comp.windows.x FAQ, which is where you should look first for help with
> any problems.
However, it has been recommended to users for ages that customizing faces should be done
from within Emacs, instead of using X resources. I am trying to get you to follow this
school of thought. Instead we are trying to push even more stuff, requiring users
to also read the relevant documentation for x-resources. All this and more, the Emacs
Manual, The Emacs Lisp Reference, The Emacs source code as not everything in documented,
and so on. If it has been recommended to customise faces from within Emacs, then why
have by default the capture of settings from things not recommended. This kind of design
ideas is winding up people something awful. Emacs cannot even agree with itself.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#58459: Getting a fresh emacs session with no customisation
2022-10-13 13:14 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-13 13:27 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-10-13 13:56 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-13 14:15 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 1 reply; 34+ messages in thread
From: uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-13 13:56 UTC (permalink / raw)
To: Po Lu; +Cc: Phil Sainty, 58459, Stefan Kangas
------- Original Message -------
On Thursday, October 13th, 2022 at 1:14 PM, Po Lu <luangruo@yahoo.com> wrote:
> uzibalqa uzibalqa@proton.me writes:
>
> > But things are working the other way round. Things get messed up, then have
> > to figure out what produced it, thing gets too complicated beyond what I consciously
> > did, then emacs uses them. Does a user have control this way? Of course not.
>
>
> You have control: inhibit-x-resources.
The sensible way is to have the user exactly specify the file he wants for setting
the resource parameters. This would avoid picking up settings that only the gods
know where they are, and what had set them up in the first place.
What could happen if the actual x-resource settings are removed from the system?
Would it be detrimental to users in unknown ways?
> > My challenge in why emacs is taking authority from x-resources. Rather than
> > firing vanilla emacs with some properly defined face with good accessibility.
>
>
> [...]
>
> > If emacs maintainers are actually so smart, how long is it going to take exactly
> > for vanilla emacs to start using some well defined accessibility metrics such
> > as modus-themes, so that the maximum number of users can comfortably use it.
>
>
> Take the complaint to the Trisquel or MATE developers.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#58459: Getting a fresh emacs session with no customisation
2022-10-13 13:56 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-10-13 14:15 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 34+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-13 14:15 UTC (permalink / raw)
To: uzibalqa; +Cc: Phil Sainty, 58459, Stefan Kangas
uzibalqa <uzibalqa@proton.me> writes:
> The sensible way is to have the user exactly specify the file he wants for setting
> the resource parameters. This would avoid picking up settings that only the gods
> know where they are, and what had set them up in the first place.
Emacs does not control where Xt gets its resources.
> What could happen if the actual x-resource settings are removed from the system?
> Would it be detrimental to users in unknown ways?
It would become impossible to set the input method style reliably, for
one.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#58459: Getting a fresh emacs session with no customisation
2022-10-13 12:09 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-13 12:19 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-10-13 15:47 ` Eli Zaretskii
2022-10-13 16:06 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-13 16:36 ` Christopher Dimech
1 sibling, 2 replies; 34+ messages in thread
From: Eli Zaretskii @ 2022-10-13 15:47 UTC (permalink / raw)
To: uzibalqa; +Cc: luangruo, psainty, 58459, stefankangas
> Cc: Phil Sainty <psainty@orcon.net.nz>, 58459@debbugs.gnu.org,
> Stefan Kangas <stefankangas@gmail.com>
> Date: Thu, 13 Oct 2022 12:09:02 +0000
> From: uzibalqa via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>
> Emacs should take the user's setting in the init file rather than override them
> with bullshit that you reckon has authority.
Language!
And X resources are as much user settings as what the user sets on the
init files. So Emacs cannot but obey them. It is user's
responsibility to set up his/her settings according to his/her
preferences.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#58459: Getting a fresh emacs session with no customisation
2022-10-13 15:47 ` Eli Zaretskii
@ 2022-10-13 16:06 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-13 16:20 ` Eli Zaretskii
2022-10-13 16:36 ` Christopher Dimech
1 sibling, 1 reply; 34+ messages in thread
From: uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-13 16:06 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: luangruo, psainty, 58459, stefankangas
------- Original Message -------
On Thursday, October 13th, 2022 at 3:47 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> > Cc: Phil Sainty psainty@orcon.net.nz, 58459@debbugs.gnu.org,
> > Stefan Kangas stefankangas@gmail.com
> > Date: Thu, 13 Oct 2022 12:09:02 +0000
> > From: uzibalqa via "Bug reports for GNU Emacs,
> > the Swiss army knife of text editors" bug-gnu-emacs@gnu.org
> >
> > Emacs should take the user's setting in the init file rather than override them
> > with bullshit that you reckon has authority.
>
> Language!
Because with an empty "~/.Xresources" emacs fills the customisations with whatever
the database decides.
> And X resources are as much user settings as what the user sets on the
> init files. So Emacs cannot but obey them. It is user's
> responsibility to set up his/her settings according to his/her
> preferences.
Untrue again. Emacs obeys them because it decided to obey them. If a user
wants to obey them, let him specify the file or the database directly.
But no, emacs wants to take them, whatever they are by default. Emacs
can just fire vanilla emacs if it wants to, but it does not want to.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#58459: Getting a fresh emacs session with no customisation
2022-10-13 16:06 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-10-13 16:20 ` Eli Zaretskii
2022-10-13 17:51 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 34+ messages in thread
From: Eli Zaretskii @ 2022-10-13 16:20 UTC (permalink / raw)
To: uzibalqa; +Cc: luangruo, psainty, 58459, stefankangas
> Date: Thu, 13 Oct 2022 16:06:21 +0000
> From: uzibalqa <uzibalqa@proton.me>
> Cc: luangruo@yahoo.com, psainty@orcon.net.nz, 58459@debbugs.gnu.org, stefankangas@gmail.com
>
> > And X resources are as much user settings as what the user sets on the
> > init files. So Emacs cannot but obey them. It is user's
> > responsibility to set up his/her settings according to his/her
> > preferences.
>
> Untrue again. Emacs obeys them because it decided to obey them.
No, Emacs obeys them because programs on X obey them. And because
Emacs obeyed them since time immemoriam.
Any further argument is really futile, because we will not stop
supporting X resources. It is your responsibility as the user to set
up the X resources on your system, or invoke Emacs in a way that
instructs Emacs to ignore those resources.
Please, just accept our position on this, even if you disagree,
because it will not change.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#58459: Getting a fresh emacs session with no customisation
2022-10-13 16:20 ` Eli Zaretskii
@ 2022-10-13 17:51 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-13 18:35 ` Christopher Dimech
0 siblings, 1 reply; 34+ messages in thread
From: uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-13 17:51 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: luangruo, psainty, 58459, stefankangas
------- Original Message -------
On Thursday, October 13th, 2022 at 4:20 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> > Date: Thu, 13 Oct 2022 16:06:21 +0000
> > From: uzibalqa uzibalqa@proton.me
> > Cc: luangruo@yahoo.com, psainty@orcon.net.nz, 58459@debbugs.gnu.org, stefankangas@gmail.com
> >
> > > And X resources are as much user settings as what the user sets on the
> > > init files. So Emacs cannot but obey them. It is user's
> > > responsibility to set up his/her settings according to his/her
> > > preferences.
> >
> > Untrue again. Emacs obeys them because it decided to obey them.
>
>
> No, Emacs obeys them because programs on X obey them. And because
> Emacs obeyed them since time immemoriam.
You know they can be incorrect because any program can set them up,
rather than entirely by the user. Even when my x-resources files are
empty, emacs goes out of its ways to get them from who knows where.
"Because emacsn obeyed them since time immemoriam" has always been
the standard response, rather than employing a rational and conscious
approach.
> Any further argument is really futile, because we will not stop
> supporting X resources. It is your responsibility as the user to set
> up the X resources on your system, or invoke Emacs in a way that
> instructs Emacs to ignore those resources.
It is not the responsibility to set up the X resources. Most times users
do not configure x-resources for emacs, as has been stated. It only offers
limitless amount of confusion.
Have never asked to stop supporting x-resources, but to support them differently.
> Please, just accept our position on this, even if you disagree,
> because it will not change.
Of course, I knew that all along. Nothing changes.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#58459: Getting a fresh emacs session with no customisation
2022-10-13 17:51 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-10-13 18:35 ` Christopher Dimech
2022-10-14 8:14 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 34+ messages in thread
From: Christopher Dimech @ 2022-10-13 18:35 UTC (permalink / raw)
To: uzibalqa; +Cc: luangruo, psainty, Eli Zaretskii, 58459, stefankangas
> Sent: Friday, October 14, 2022 at 5:51 AM
> From: "uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> To: "Eli Zaretskii" <eliz@gnu.org>
> Cc: luangruo@yahoo.com, psainty@orcon.net.nz, 58459@debbugs.gnu.org, stefankangas@gmail.com
> Subject: bug#58459: Getting a fresh emacs session with no customisation
>
>
> ------- Original Message -------
> On Thursday, October 13th, 2022 at 4:20 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>
>
> > > Date: Thu, 13 Oct 2022 16:06:21 +0000
> > > From: uzibalqa uzibalqa@proton.me
> > > Cc: luangruo@yahoo.com, psainty@orcon.net.nz, 58459@debbugs.gnu.org, stefankangas@gmail.com
> > >
> > > > And X resources are as much user settings as what the user sets on the
> > > > init files. So Emacs cannot but obey them. It is user's
> > > > responsibility to set up his/her settings according to his/her
> > > > preferences.
> > >
> > > Untrue again. Emacs obeys them because it decided to obey them.
> >
> >
> > No, Emacs obeys them because programs on X obey them. And because
> > Emacs obeyed them since time immemoriam.
>
> You know they can be incorrect because any program can set them up,
> rather than entirely by the user. Even when my x-resources files are
> empty, emacs goes out of its ways to get them from who knows where.
> "Because emacsn obeyed them since time immemoriam" has always been
> the standard response, rather than employing a rational and conscious
> approach.
>
> > Any further argument is really futile, because we will not stop
> > supporting X resources. It is your responsibility as the user to set
> > up the X resources on your system, or invoke Emacs in a way that
> > instructs Emacs to ignore those resources.
>
> It is not the responsibility to set up the X resources. Most times users
> do not configure x-resources for emacs, as has been stated. It only offers
> limitless amount of confusion.
>
> Have never asked to stop supporting x-resources, but to support them differently.
>
> > Please, just accept our position on this, even if you disagree,
> > because it will not change.
>
> Of course, I knew that all along. Nothing changes.
Stallman has said that there are some technical barriers in finding someone interested
in and capable of doing the work needed, but there is an overarching problem that needs
to be addressed first: The code to interface Emacs to X-based GUIs needs rewriting by an
expert, and has needed it for decades. Until it gets that rewrite, changes in it are likely
to break something.
The appeal of an editor that can be extended using the Lisp language is somewhat limited.
Because it means spending a bunch of time and energy to change it. Although it is true
that few important changes can ever happen due to the friction with old users.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#58459: Getting a fresh emacs session with no customisation
2022-10-13 18:35 ` Christopher Dimech
@ 2022-10-14 8:14 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-14 19:40 ` Christopher Dimech
0 siblings, 1 reply; 34+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-14 8:14 UTC (permalink / raw)
To: Christopher Dimech; +Cc: psainty, Eli Zaretskii, uzibalqa, 58459, stefankangas
Christopher Dimech <dimech@gmx.com> writes:
> The code to interface Emacs to X-based GUIs needs rewriting by an
> expert, and has needed it for decades.
Such a hypothetical rewrite (who wants to rewrite the 100,000-odd lines
of code that are needed to work with modern X systems?) will probably
not happen, given the amount of manpower we currently have at hand.
Even if it does, it will not affect whether or not Emacs understands X
resources.
> Until it gets that rewrite, changes in it are likely to break
> something.
This was almost certainly taken out of context.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#58459: Getting a fresh emacs session with no customisation
2022-10-14 8:14 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-10-14 19:40 ` Christopher Dimech
0 siblings, 0 replies; 34+ messages in thread
From: Christopher Dimech @ 2022-10-14 19:40 UTC (permalink / raw)
To: Po Lu; +Cc: psainty, Eli Zaretskii, uzibalqa, 58459, stefankangas
> Sent: Friday, October 14, 2022 at 8:14 PM
> From: "Po Lu" <luangruo@yahoo.com>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: uzibalqa@proton.me, "Eli Zaretskii" <eliz@gnu.org>, psainty@orcon.net.nz, 58459@debbugs.gnu.org, stefankangas@gmail.com
> Subject: Re: bug#58459: Getting a fresh emacs session with no customisation
>
> Christopher Dimech <dimech@gmx.com> writes:
>
> > The code to interface Emacs to X-based GUIs needs rewriting by an
> > expert, and has needed it for decades.
>
> Such a hypothetical rewrite (who wants to rewrite the 100,000-odd lines
> of code that are needed to work with modern X systems?) will probably
> not happen, given the amount of manpower we currently have at hand.
> Even if it does, it will not affect whether or not Emacs understands X
> resources.
The same conditions occur within the scientific community. Almost
nobody is willing to perform serious work. For instance, many things
considered modern today, if you look under the hood, you will find everything
is basically a wrapper around fortran work from the 60s. Not much innovation
or scientific value since then. Most work is cosmetic and mainly for entertainment.
The 60s and 70s were much more productive.
Have organised quite a few projects where the path was to rewrite. But this does
not really fit in well these days, so unless things are marshaled by appropriate
individuals, it will continue be to as you say.
> > Until it gets that rewrite, changes in it are likely to break
> > something.
>
> This was almost certainly taken out of context.
>
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#58459: Getting a fresh emacs session with no customisation
2022-10-13 15:47 ` Eli Zaretskii
2022-10-13 16:06 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-10-13 16:36 ` Christopher Dimech
2022-10-13 19:13 ` Eli Zaretskii
1 sibling, 1 reply; 34+ messages in thread
From: Christopher Dimech @ 2022-10-13 16:36 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: luangruo, psainty, uzibalqa, 58459, stefankangas
> Sent: Friday, October 14, 2022 at 3:47 AM
> From: "Eli Zaretskii" <eliz@gnu.org>
> To: "uzibalqa" <uzibalqa@proton.me>
> Cc: luangruo@yahoo.com, psainty@orcon.net.nz, 58459@debbugs.gnu.org, stefankangas@gmail.com
> Subject: bug#58459: Getting a fresh emacs session with no customisation
>
> > Cc: Phil Sainty <psainty@orcon.net.nz>, 58459@debbugs.gnu.org,
> > Stefan Kangas <stefankangas@gmail.com>
> > Date: Thu, 13 Oct 2022 12:09:02 +0000
> > From: uzibalqa via "Bug reports for GNU Emacs,
> > the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> >
> > Emacs should take the user's setting in the init file rather than override them
> > with bullshit that you reckon has authority.
>
> Language!
>
> And X resources are as much user settings as what the user sets on the
> init files. So Emacs cannot but obey them. It is user's
> responsibility to set up his/her settings according to his/her
> preferences.
The user makes a good point. When a user want emacs to obey x-resources,
the user specify the x-resources in their init file. Rather than obey them
when a user did not specifically ask for that to happen. Vanilla Emacs should
load modus-themes, then users can change that if they do not like the theme.
>
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#58459: Getting a fresh emacs session with no customisation
2022-10-13 16:36 ` Christopher Dimech
@ 2022-10-13 19:13 ` Eli Zaretskii
2022-10-13 19:20 ` Christopher Dimech
0 siblings, 1 reply; 34+ messages in thread
From: Eli Zaretskii @ 2022-10-13 19:13 UTC (permalink / raw)
To: Christopher Dimech; +Cc: luangruo, psainty, uzibalqa, 58459, stefankangas
> From: Christopher Dimech <dimech@gmx.com>
> Cc: uzibalqa <uzibalqa@proton.me>, luangruo@yahoo.com, psainty@orcon.net.nz,
> 58459@debbugs.gnu.org, stefankangas@gmail.com
> Date: Thu, 13 Oct 2022 18:36:43 +0200
>
> > And X resources are as much user settings as what the user sets on the
> > init files. So Emacs cannot but obey them. It is user's
> > responsibility to set up his/her settings according to his/her
> > preferences.
>
> The user makes a good point. When a user want emacs to obey x-resources,
> the user specify the x-resources in their init file. Rather than obey them
> when a user did not specifically ask for that to happen.
That's not how X applications work, and that's not how Emacs has
worked since day one on X.
So please stop arguing, this is not going to change.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#58459: Getting a fresh emacs session with no customisation
2022-10-13 19:13 ` Eli Zaretskii
@ 2022-10-13 19:20 ` Christopher Dimech
0 siblings, 0 replies; 34+ messages in thread
From: Christopher Dimech @ 2022-10-13 19:20 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: luangruo, psainty, uzibalqa, 58459, stefankangas
> Sent: Friday, October 14, 2022 at 7:13 AM
> From: "Eli Zaretskii" <eliz@gnu.org>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: uzibalqa@proton.me, luangruo@yahoo.com, psainty@orcon.net.nz, 58459@debbugs.gnu.org, stefankangas@gmail.com
> Subject: Re: bug#58459: Getting a fresh emacs session with no customisation
>
> > From: Christopher Dimech <dimech@gmx.com>
> > Cc: uzibalqa <uzibalqa@proton.me>, luangruo@yahoo.com, psainty@orcon.net.nz,
> > 58459@debbugs.gnu.org, stefankangas@gmail.com
> > Date: Thu, 13 Oct 2022 18:36:43 +0200
> >
> > > And X resources are as much user settings as what the user sets on the
> > > init files. So Emacs cannot but obey them. It is user's
> > > responsibility to set up his/her settings according to his/her
> > > preferences.
> >
> > The user makes a good point. When a user want emacs to obey x-resources,
> > the user specify the x-resources in their init file. Rather than obey them
> > when a user did not specifically ask for that to happen.
>
> That's not how X applications work, and that's not how Emacs has
> worked since day one on X.
>
> So please stop arguing, this is not going to change.
It is my prerogative to state my outlook. And that also is not going
to change.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#58459: Getting a fresh emacs session with no customisation
2022-10-12 23:16 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-13 1:14 ` Stefan Kangas
@ 2022-10-13 10:30 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 0 replies; 34+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-13 10:30 UTC (permalink / raw)
To: uzibalqa; +Cc: Phil Sainty, 58459, Stefan Kangas
uzibalqa <uzibalqa@proton.me> writes:
> Early on in the discussion, the response was immediately "notabug
> close thanks". But perhaps you are right and I am being excessive.
"notabug close thanks" is a series of commands for our bug tracking
system.
> Nevertheless, I am yet to be convinced how this resource thing is
> straightforward.
Perhaps you have not read the X(7) manual page?
^ permalink raw reply [flat|nested] 34+ messages in thread
end of thread, other threads:[~2022-10-14 19:40 UTC | newest]
Thread overview: 34+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-10-12 0:09 bug#58459: Getting a fresh emacs session with no customisation uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-12 9:51 ` Stefan Kangas
2022-10-12 12:52 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-12 12:56 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-12 16:23 ` Stefan Kangas
2022-10-12 17:30 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-12 21:11 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-12 22:47 ` Phil Sainty
2022-10-12 23:16 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-13 1:14 ` Stefan Kangas
2022-10-13 2:02 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-13 3:01 ` Stefan Kangas
2022-10-13 15:48 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-13 10:22 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-13 12:09 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-13 12:19 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-13 12:52 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-13 13:14 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-13 13:27 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-13 14:19 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-13 14:36 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-13 13:56 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-13 14:15 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-13 15:47 ` Eli Zaretskii
2022-10-13 16:06 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-13 16:20 ` Eli Zaretskii
2022-10-13 17:51 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-13 18:35 ` Christopher Dimech
2022-10-14 8:14 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-14 19:40 ` Christopher Dimech
2022-10-13 16:36 ` Christopher Dimech
2022-10-13 19:13 ` Eli Zaretskii
2022-10-13 19:20 ` Christopher Dimech
2022-10-13 10:30 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).