[PATCH] Add make target to ease creating reproducers and testing them

[PATCH] Add make target to ease creating reproducers and testing them

[Ihor Radchenko]

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

Hi,

In the Feedback section of the manual, we provide instructions on how to
create reproducers: https://orgmode.org/manual/Feedback.html

The instructions are nice, but I was thinking to simplify things for the
users further.

I propose a new make target: make repro
It will run the commands we already suggest, but without a need to
create minimal file, pass all that arguments to emacs, etc

WDYT?

Best,
Ihor


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-mk-Add-make-target-repro-for-easy-bug-testing.patch --]
[-- Type: text/x-patch, Size: 3492 bytes --]

From 8d5f9f023af18828656df85a0ce4069e004dbf5d Mon Sep 17 00:00:00 2001
Message-Id: <8d5f9f023af18828656df85a0ce4069e004dbf5d.1651373896.git.yantar92@gmail.com>
From: Ihor Radchenko <yantar92@gmail.com>
Date: Sun, 1 May 2022 10:44:10 +0800
Subject: [PATCH] mk: Add make target "repro" for easy bug testing

* mk/default.mk (REPRO_DEBUG): New custom variable enabling extra
debugging facilities in Emacs instance open by make repro.
(REPRO_ARGS): Extra arguments passed to Emacs by make repro.
(REPRO_INIT):
(REPRO): Define Emacs cmd for testing.
* mk/targets.mk (.PHONY):
(repro): Add new target.
* doc/org-manual.org (Feedback): Describe the new make target.
---
 doc/org-manual.org |  8 ++++++++
 mk/default.mk      | 21 +++++++++++++++++++++
 mk/targets.mk      |  5 ++++-
 3 files changed, 33 insertions(+), 1 deletion(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index c0bd853ca..6a574977e 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -269,6 +269,14 @@ ** Feedback
 (add-to-list 'load-path (expand-file-name "/path/to/org-mode/lisp"))
 #+end_src
 
+If you are using Org mode version from Git repository, you can start
+minimal session using make.
+
+: # Bare Emacs
+: make repro
+: # or pass extra arguments
+: make repro REPRO_ARGS="-l /path/to/minimal/config.el /tmp/bug.org"
+
 If an error occurs, a "backtrace" can be very useful---see below on
 how to create one.  Often a small example file helps, along with clear
 information about:
diff --git a/mk/default.mk b/mk/default.mk
index 804089280..33e737da3 100644
--- a/mk/default.mk
+++ b/mk/default.mk
@@ -59,6 +59,11 @@ BTEST_OB_LANGUAGES = awk C fortran maxima lilypond octave perl python
 # extra packages to require for testing
 BTEST_EXTRA =
               # ess-site  # load ESS for R tests
+# Whether to activate extra debugging facilities for make repro.
+REPRO_DEBUG ?= yes
+# Extra arguments passed to Emacs for make repro.
+# e.g. -l config.el /tmp/bug.org
+REPRO_ARGS ?=
 ##->8-------------------------------------------------------------------
 ## YOU MAY NEED TO ADAPT THESE DEFINITIONS
 ##----------------------------------------------------------------------
@@ -93,6 +98,22 @@ BTEST = $(BATCH) $(BTEST_INIT) \
 # should be useful for manual testing and verification of problems.
 NOBATCH = $(EMACSQ) $(BTEST_INIT) -l org -f org-version
 
+ifeq ($(REPRO_DEBUG), yes)
+REPRO_INIT = --eval "(setq \
+	debug-on-error t\
+	debug-on-signal nil\
+	debug-on-quit nil\
+	org-element--cache-self-verify 'backtrace\
+	org-element--cache-self-verify-frequency 1.0\
+	org-element--cache-map-statistics t)"
+else
+REPRO_INIT =
+endif
+
+# Running a plain emacs with no config, this Org mode loaded, and
+# debugging facilities activated.
+REPRO = $(NOBATCH) $(REPRO_INIT) $(REPRO_ARGS)
+
 # start Emacs with no user and site configuration
 # EMACSQ = -vanilla # XEmacs
 EMACSQ  = $(EMACS)  -Q
diff --git a/mk/targets.mk b/mk/targets.mk
index 6de77b1e6..5cba63e21 100644
--- a/mk/targets.mk
+++ b/mk/targets.mk
@@ -41,7 +41,7 @@ endif
 	cleanlisp cleandoc cleandocs cleantest \
 	compile compile-dirty uncompiled \
 	config config-test config-exe config-all config-eol config-version \
-	vanilla
+	vanilla repro
 
 CONF_BASE = EMACS DESTDIR ORGCM ORG_MAKE_DOC
 CONF_DEST = lispdir infodir datadir testdir
@@ -132,6 +132,9 @@ $(INSTSUB):
 autoloads: lisp
 	$(MAKE) -C $< $@
 
+repro: cleanall autoloads
+	-@$(REPRO) &
+
 cleandirs:
 	$(foreach dir, $(SUBDIRS), $(MAKE) -C $(dir) cleanall;)
 
-- 
2.35.1

Re: [PATCH] Add make target to ease creating reproducers and testing them

[Samuel Wales]

quicker repro is a great idea.  long ago i created a test file that
serves a similar purpose and some shell functions for variations.  i
have to try to reacquaint with all of that each time, which can be
enough of a barrier to not repro.

coupld of questions.  first, is there accommodation for accessibility?
 e.g. if a user needs a setting for large fonts, small window size to
not be larger than monitor size, any emacs args, black bg.

for these reasons, and because setup of agenda etc. takes a bit of
code, my test file is not tiny.  but maybe it is good enough to
combine user setup with the code that triggers the issue.  for
simplicity.  [in my case by variations i mean e.g. which version of
emacs, which version of org, whether my .emacs is loaded.  i doubt
this is needed, but some users might want to set such things sometimes
for comparison.  probably simplicity should be a higher priority.]

second, this is for which instantiations of org?  git yes, what about
package managers?  built-in org??


On 4/30/22, Ihor Radchenko <yantar92@gmail.com> wrote:
> Hi,
>
> In the Feedback section of the manual, we provide instructions on how to
> create reproducers: https://orgmode.org/manual/Feedback.html
>
> The instructions are nice, but I was thinking to simplify things for the
> users further.
>
> I propose a new make target: make repro
> It will run the commands we already suggest, but without a need to
> create minimal file, pass all that arguments to emacs, etc
>
> WDYT?
>
> Best,
> Ihor
>
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: [PATCH] Add make target to ease creating reproducers and testing them

[Ihor Radchenko]

Samuel Wales <samologist@gmail.com> writes:

> coupld of questions.  first, is there accommodation for accessibility?
>  e.g. if a user needs a setting for large fonts, small window size to
> not be larger than monitor size, any emacs args, black bg.

There is REPRO_ARGS variable. It can be used to pass any extra args to
Emacs. I provided relevant example in the manual (see the patch).

As for accessibility, I doubt that we can provide something that fits
all people. Not to mention that accessibility settings themselves can
affect reproducer.

> for these reasons, and because setup of agenda etc. takes a bit of
> code, my test file is not tiny.  but maybe it is good enough to
> combine user setup with the code that triggers the issue.  for
> simplicity.  [in my case by variations i mean e.g. which version of
> emacs, which version of org, whether my .emacs is loaded.  i doubt
> this is needed, but some users might want to set such things sometimes
> for comparison.  probably simplicity should be a higher priority.]

We cannot expect users to do anything more than reporting their system,
Emacs, and Org mode versions. If desired, our Makefile provides EMACS
variable to control which Emacs executable to use.

> second, this is for which instantiations of org?  git yes, what about
> package managers?  built-in org??

This is for git and assumes that git version of Org is already
downloaded (how would you run make repro otherwise?).

For built-in Org, manual just says emacs -Q. Nothing much to simplify.
For package managers, users need to provide the load-path. Again,
details are already covered in the manual.

Best,
Ihor

Re: [PATCH] Add make target to ease creating reproducers and testing them

[Samuel Wales]

thanks for reply.  merely pointing out that: some users, myself
included, need settings to make the system work at all.  that is, it
is impossible to use emacs.  this is solved in some cases by .emacs
settings and command line args.

for example, just today i clicked on a download link --- for your
patch, now that i think about it --- and firefox suggested emacs as an
alternative to saving.  so i tried it, and emacs came up completely
unusable.  i was able to save using the firefox dialog box, then open
with my regular emacs, but wasn't able to determine much from the
patch in my case.

[firefox did not offer to allow a command line to run my shell script
which sets up emacs correctly, and idk if it even ran with my .emacs.
does it do -q?  not sure because emacs is too unusable to even find
that out.  so firefox fails to be accessible in that dialog box.  they
probably never thought anybody would need to run a command line
instead of choosing from some "applications" list.  whereas i never
thought major free software would /not/ provide for a command line.
different perspective i guess.]

if those users are not anticpated by the make target, perhaps a line
indicating something like that [idk what as i didn't understand the
patch] in the description would be useful so that they do not have to
follow a false trail?


On 4/30/22, Ihor Radchenko <yantar92@gmail.com> wrote:
> Samuel Wales <samologist@gmail.com> writes:
>
>> coupld of questions.  first, is there accommodation for accessibility?
>>  e.g. if a user needs a setting for large fonts, small window size to
>> not be larger than monitor size, any emacs args, black bg.
>
> There is REPRO_ARGS variable. It can be used to pass any extra args to
> Emacs. I provided relevant example in the manual (see the patch).
>
> As for accessibility, I doubt that we can provide something that fits
> all people. Not to mention that accessibility settings themselves can
> affect reproducer.
>
>> for these reasons, and because setup of agenda etc. takes a bit of
>> code, my test file is not tiny.  but maybe it is good enough to
>> combine user setup with the code that triggers the issue.  for
>> simplicity.  [in my case by variations i mean e.g. which version of
>> emacs, which version of org, whether my .emacs is loaded.  i doubt
>> this is needed, but some users might want to set such things sometimes
>> for comparison.  probably simplicity should be a higher priority.]
>
> We cannot expect users to do anything more than reporting their system,
> Emacs, and Org mode versions. If desired, our Makefile provides EMACS
> variable to control which Emacs executable to use.
>
>> second, this is for which instantiations of org?  git yes, what about
>> package managers?  built-in org??
>
> This is for git and assumes that git version of Org is already
> downloaded (how would you run make repro otherwise?).
>
> For built-in Org, manual just says emacs -Q. Nothing much to simplify.
> For package managers, users need to provide the load-path. Again,
> details are already covered in the manual.
>
> Best,
> Ihor
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: [PATCH] Add make target to ease creating reproducers and testing them

[Samuel Wales]

i took another look.

repro args might be enough for most users.

> As for accessibility, I doubt that we can provide something that fits all people. Not to mention that accessibility settings themselves can
affect reproducer.

i don't think anybody is asking for the first point.  if something is
unusable at all, it won't be reproed, so the second point is sort of,
either it gets reported along with the settings as a heads up, or it
doesn't get reproed.


On 4/30/22, Samuel Wales <samologist@gmail.com> wrote:
> thanks for reply.  merely pointing out that: some users, myself
> included, need settings to make the system work at all.  that is, it
> is impossible to use emacs.  this is solved in some cases by .emacs
> settings and command line args.
>
> for example, just today i clicked on a download link --- for your
> patch, now that i think about it --- and firefox suggested emacs as an
> alternative to saving.  so i tried it, and emacs came up completely
> unusable.  i was able to save using the firefox dialog box, then open
> with my regular emacs, but wasn't able to determine much from the
> patch in my case.
>
> [firefox did not offer to allow a command line to run my shell script
> which sets up emacs correctly, and idk if it even ran with my .emacs.
> does it do -q?  not sure because emacs is too unusable to even find
> that out.  so firefox fails to be accessible in that dialog box.  they
> probably never thought anybody would need to run a command line
> instead of choosing from some "applications" list.  whereas i never
> thought major free software would /not/ provide for a command line.
> different perspective i guess.]
>
> if those users are not anticpated by the make target, perhaps a line
> indicating something like that [idk what as i didn't understand the
> patch] in the description would be useful so that they do not have to
> follow a false trail?
>
>
> On 4/30/22, Ihor Radchenko <yantar92@gmail.com> wrote:
>> Samuel Wales <samologist@gmail.com> writes:
>>
>>> coupld of questions.  first, is there accommodation for accessibility?
>>>  e.g. if a user needs a setting for large fonts, small window size to
>>> not be larger than monitor size, any emacs args, black bg.
>>
>> There is REPRO_ARGS variable. It can be used to pass any extra args to
>> Emacs. I provided relevant example in the manual (see the patch).
>>
>> As for accessibility, I doubt that we can provide something that fits
>> all people. Not to mention that accessibility settings themselves can
>> affect reproducer.
>>
>>> for these reasons, and because setup of agenda etc. takes a bit of
>>> code, my test file is not tiny.  but maybe it is good enough to
>>> combine user setup with the code that triggers the issue.  for
>>> simplicity.  [in my case by variations i mean e.g. which version of
>>> emacs, which version of org, whether my .emacs is loaded.  i doubt
>>> this is needed, but some users might want to set such things sometimes
>>> for comparison.  probably simplicity should be a higher priority.]
>>
>> We cannot expect users to do anything more than reporting their system,
>> Emacs, and Org mode versions. If desired, our Makefile provides EMACS
>> variable to control which Emacs executable to use.
>>
>>> second, this is for which instantiations of org?  git yes, what about
>>> package managers?  built-in org??
>>
>> This is for git and assumes that git version of Org is already
>> downloaded (how would you run make repro otherwise?).
>>
>> For built-in Org, manual just says emacs -Q. Nothing much to simplify.
>> For package managers, users need to provide the load-path. Again,
>> details are already covered in the manual.
>>
>> Best,
>> Ihor
>>
>
>
> --
> The Kafka Pandemic
>
> A blog about science, health, human rights, and misopathy:
> https://thekafkapandemic.blogspot.com
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Emacs launched from Firefox

[Max Nikulin]

On 01/05/2022 11:53, Samuel Wales wrote:
> 
> [firefox did not offer to allow a command line to run my shell script
> which sets up emacs correctly, and idk if it even ran with my .emacs.
> does it do -q?  not sure because emacs is too unusable to even find
> that out.  so firefox fails to be accessible in that dialog box.

Samuel, I think, firefox does exactly what it can find in MIME 
associations (e.g. ~/.config/mimeapps.list) and in the .desktop file of 
the selected application.

There is an emacsclient.desktop file in Emacs git master that tries to 
connect to the existing Emacs session. It is a relatively new addition, 
so packages for Linux distributions may miss it.

You can either use standard Emacs initialization to get all your 
customization available through default emacs.desktop or create a custom 
.desktop file that contain all CLI options specific to your setup.

Re: Emacs launched from Firefox

[Samuel Wales]

thank you.  there is no emacs in my ~/.config/mimeapps.list.  where
are those desktop files found or put?  i use fluxbox.
[i realize this is not org related.  non-list email ok.]


On 5/1/22, Max Nikulin <manikulin@gmail.com> wrote:
> On 01/05/2022 11:53, Samuel Wales wrote:
>>
>> [firefox did not offer to allow a command line to run my shell script
>> which sets up emacs correctly, and idk if it even ran with my .emacs.
>> does it do -q?  not sure because emacs is too unusable to even find
>> that out.  so firefox fails to be accessible in that dialog box.
>
> Samuel, I think, firefox does exactly what it can find in MIME
> associations (e.g. ~/.config/mimeapps.list) and in the .desktop file of
> the selected application.
>
> There is an emacsclient.desktop file in Emacs git master that tries to
> connect to the existing Emacs session. It is a relatively new addition,
> so packages for Linux distributions may miss it.
>
> You can either use standard Emacs initialization to get all your
> customization available through default emacs.desktop or create a custom
> .desktop file that contain all CLI options specific to your setup.
>
>
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: Emacs launched from Firefox

[Max Nikulin]

On 02/05/2022 09:03, Samuel Wales wrote:
> thank you.  there is no emacs in my ~/.config/mimeapps.list.  where
> are those desktop files found or put?  i use fluxbox.
> [i realize this is not org related.  non-list email ok.]

Perhaps emacs-help is more suitable for this discussion, but I do not 
read that mail list due to rather high traffic there. On the other hand 
I do not know if there is a resource describing such configuration 
taking into account details specific to Emacs (I have not tried to find 
it though).

I am not sure from which site you downloaded that attachment, MIME type 
may vary depending on the HTTP server configuration. You yay check 
Content-Type response header in the browser development tools or using

     curl -I '<URL>'

command. It may be "text/plain", "text/x-patch", "application/x-patch", etc.

In Firefox settings (about:preferences page) check that "Applications" 
section either does not contain an entry for the MIME type (is unlikely 
in your case since you already opened a file) or its handler is 
configured to "Always ask" till you select your new handler.

System-wide .desktop file may reside e.g. in 
"/usr/share/applications/emacs.desktop". You can put your customized 
file in e.g. "~/.local/share/applications/" directory 
("$XDG_DATA_HOME/applications/") or into "applications" subdirectory of 
"$XDG_DATA_DIRS" entry. For details see
https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

Customize "Exec" entry in the .desktop file to add your options, e.g. 
create "emacs-a11y.desktop"

---- >8 ----
[Desktop Entry]
Version=1.0
Name=Accessible Emacs (GUI)
GenericName=Text Editor
Comment=GNU Emacs is an extensible, customizable text editor - and more
MimeType=text/english;text/plain;text/x-makefile;text/x-c++hdr;text/x-c++src;text/x-chdr;text/x-csrc;text/x-java;text/x-moc;text/x-pascal;text/x-tcl;text/x-tex;application/x-shellscript;text/x-c;text/x-c++;
TryExec=/usr/bin/emacs
Exec=/usr/bin/emacs %F
Icon=emacs
Type=Application
Terminal=false
Categories=Utility;Development;TextEditor;
StartupWMClass=Emacs
Keywords=Text;Editor;
---- 8< ----

It is better to set unique "Name" to distinguish it from the default 
Emacs launcher. Desktop file format reference:
https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html

Notice that browser launcher script may reset PATH environment to some 
safe value, so executables from custom directories may be unavailable 
without specifying of the full path.

MIME type should be among the values of the MimeType field inside the 
".desktop" file or in the "mimeapps.list" file. In the former case run 
(with proper directory)

     update-desktop-database ~/.local/share/applications

In the latter case add to "~/config/mimeapps.list" mapping from the MIME 
type to your .desktop file

---- >8 ----
[Added Associations]
text/plain=emacs-a11y.desktop;
---- 8< ----

And maybe

---- >8 ----
[Default Applications]
text/plain=emacs-a11y.desktop;
---- 8< ----

With such recipe a new instance of Emacs will be launched for each 
downloaded file. Likely you would prefer to use you main Emacs session 
or a special session of Emacs for untrusted content fetched from web. In 
such case you can use "emacsclient" command in the ".desktop" file and 
maybe systemd user socket+service units pair to run Emacs on demand.

If you are still using emacs-25 then e.g. "--fg-daemon" option is 
unavailable and related files are not included in the package. For 
inspiration you may check
http://git.savannah.gnu.org/cgit/emacs.git/tree/etc/emacsclient.desktop
http://git.savannah.gnu.org/cgit/emacs.git/tree/etc/emacs.service
https://www.gnu.org/software/emacs/manual/html_node/emacs/Emacs-Server.html

Finally a rather unrelated question. Do you find accessibility tools in 
Gnome or KDE inconvenient? I believed that it should be more difficult 
to arrange setup from scratch for fluxbox. However I never tried any of 
these options.

> On 5/1/22, Max Nikulin wrote:
>> On 01/05/2022 11:53, Samuel Wales wrote:
>>>
>>> [firefox did not offer to allow a command line to run my shell script
>>> which sets up emacs correctly, and idk if it even ran with my .emacs.
>>> does it do -q?  not sure because emacs is too unusable to even find
>>> that out.  so firefox fails to be accessible in that dialog box.
>>
>> Samuel, I think, firefox does exactly what it can find in MIME
>> associations (e.g. ~/.config/mimeapps.list) and in the .desktop file of
>> the selected application.
>>
>> There is an emacsclient.desktop file in Emacs git master that tries to
>> connect to the existing Emacs session. It is a relatively new addition,
>> so packages for Linux distributions may miss it.
>>
>> You can either use standard Emacs initialization to get all your
>> customization available through default emacs.desktop or create a custom
>> .desktop file that contain all CLI options specific to your setup.

Re: Emacs launched from Firefox

[Samuel Wales]

thank you for that /very/ useful information.  cannot seem to
reproduce at this time as i'd have to narrow down the dialog box in
which this occurs [i think on a save link in gmail with some
extensions or so is one place] for haelth reasons but i think part of
the problem is that .emacs is not called, and/or that a tiny little
unreadable xterm is launched and emacs is run in it.  why firefox
would do that, idk.

i will quite likely need the information in your post if the .emacs
and/or xterm thing gets solved.  but it turns out that with
/usr/bin/emacs in normal use [no personal script needed] everything is
accessible.  my path doesn't override that.

so idk why ff makes emacs not load .emacs or does an xterm.
/usr/bin/emacs results in indeed emacs25 atm.

gnome and kde are too heavy for my computer, and they can't do
everything fluxbox can, and fluxbox mostly wfm.  i don't get what
things de's do that i need, but perhaps setting default fonts/colors
for various toolkits is one of them.


On 5/2/22, Max Nikulin <manikulin@gmail.com> wrote:
> I am not sure from which site you downloaded that attachment, MIME type
> may vary depending on the HTTP server configuration. You yay check
> Content-Type response header in the browser development tools or using
>
>      curl -I '<URL>'
>
> command. It may be "text/plain", "text/x-patch", "application/x-patch",
> etc.
>
> In Firefox settings (about:preferences page) check that "Applications"
> section either does not contain an entry for the MIME type (is unlikely
> in your case since you already opened a file) or its handler is
> configured to "Always ask" till you select your new handler.
>
> System-wide .desktop file may reside e.g. in
> "/usr/share/applications/emacs.desktop". You can put your customized
> file in e.g. "~/.local/share/applications/" directory
> ("$XDG_DATA_HOME/applications/") or into "applications" subdirectory of
> "$XDG_DATA_DIRS" entry. For details see
> https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
>
> Customize "Exec" entry in the .desktop file to add your options, e.g.
> create "emacs-a11y.desktop"
>
> ---- >8 ----
> [Desktop Entry]
> Version=1.0
> Name=Accessible Emacs (GUI)
> GenericName=Text Editor
> Comment=GNU Emacs is an extensible, customizable text editor - and more
> MimeType=text/english;text/plain;text/x-makefile;text/x-c++hdr;text/x-c++src;text/x-chdr;text/x-csrc;text/x-java;text/x-moc;text/x-pascal;text/x-tcl;text/x-tex;application/x-shellscript;text/x-c;text/x-c++;
> TryExec=/usr/bin/emacs
> Exec=/usr/bin/emacs %F
> Icon=emacs
> Type=Application
> Terminal=false
> Categories=Utility;Development;TextEditor;
> StartupWMClass=Emacs
> Keywords=Text;Editor;
> ---- 8< ----
>
> It is better to set unique "Name" to distinguish it from the default
> Emacs launcher. Desktop file format reference:
> https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html
>
> Notice that browser launcher script may reset PATH environment to some
> safe value, so executables from custom directories may be unavailable
> without specifying of the full path.
>
> MIME type should be among the values of the MimeType field inside the
> ".desktop" file or in the "mimeapps.list" file. In the former case run
> (with proper directory)
>
>      update-desktop-database ~/.local/share/applications
>
> In the latter case add to "~/config/mimeapps.list" mapping from the MIME
> type to your .desktop file
>
> ---- >8 ----
> [Added Associations]
> text/plain=emacs-a11y.desktop;
> ---- 8< ----
>
> And maybe
>
> ---- >8 ----
> [Default Applications]
> text/plain=emacs-a11y.desktop;
> ---- 8< ----
>
> With such recipe a new instance of Emacs will be launched for each
> downloaded file. Likely you would prefer to use you main Emacs session
> or a special session of Emacs for untrusted content fetched from web. In
> such case you can use "emacsclient" command in the ".desktop" file and
> maybe systemd user socket+service units pair to run Emacs on demand.
>
> If you are still using emacs-25 then e.g. "--fg-daemon" option is
> unavailable and related files are not included in the package. For
> inspiration you may check
> http://git.savannah.gnu.org/cgit/emacs.git/tree/etc/emacsclient.desktop
> http://git.savannah.gnu.org/cgit/emacs.git/tree/etc/emacs.service
> https://www.gnu.org/software/emacs/manual/html_node/emacs/Emacs-Server.html
>
> Finally a rather unrelated question. Do you find accessibility tools in
> Gnome or KDE inconvenient? I believed that it should be more difficult
> to arrange setup from scratch for fluxbox. However I never tried any of
> these options.
>
>> On 5/1/22, Max Nikulin wrote:
>>> On 01/05/2022 11:53, Samuel Wales wrote:
>>>>
>>>> [firefox did not offer to allow a command line to run my shell script
>>>> which sets up emacs correctly, and idk if it even ran with my .emacs.
>>>> does it do -q?  not sure because emacs is too unusable to even find
>>>> that out.  so firefox fails to be accessible in that dialog box.
>>>
>>> Samuel, I think, firefox does exactly what it can find in MIME
>>> associations (e.g. ~/.config/mimeapps.list) and in the .desktop file of
>>> the selected application.
>>>
>>> There is an emacsclient.desktop file in Emacs git master that tries to
>>> connect to the existing Emacs session. It is a relatively new addition,
>>> so packages for Linux distributions may miss it.
>>>
>>> You can either use standard Emacs initialization to get all your
>>> customization available through default emacs.desktop or create a custom
>>> .desktop file that contain all CLI options specific to your setup.
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: Emacs launched from Firefox

[Ihor Radchenko]

Samuel Wales <samologist@gmail.com> writes:

> so idk why ff makes emacs not load .emacs or does an xterm.
> /usr/bin/emacs results in indeed emacs25 atm.
>
> gnome and kde are too heavy for my computer, and they can't do
> everything fluxbox can, and fluxbox mostly wfm.  i don't get what
> things de's do that i need, but perhaps setting default fonts/colors
> for various toolkits is one of them.

You may find https://wiki.gentoo.org/wiki/Default_applications useful. I
also don't use desktop environment and had to setup defaults manually.

Best,
Ihor

Re: Emacs launched from Firefox

[Max Nikulin]

On 26/05/2022 09:59, Ihor Radchenko wrote:
> Samuel Wales writes:
> 
>> so idk why ff makes emacs not load .emacs or does an xterm.
>> /usr/bin/emacs results in indeed emacs25 atm.

Since you have not found a way to reproduce the issue in a month, I 
assume that you do not severely suffer from the problem.

>> gnome and kde are too heavy for my computer, and they can't do
>> everything fluxbox can, and fluxbox mostly wfm.

An advantage of KDE is that with some tuning it may be made more 
lightweight, while Gnome is less configurable. I do not consider a 8 
year old laptop with i5 CPU and integrated graphics adapter as a high 
performance unit (it never was it). While Gnome makes the fan annoyingly 
noisy, there is no such problem in KDE with disabled desktop effects. I 
admit that the laptop is neither a low end one, and I was lucky with a 
Chinese SSD put into modem slot, the cost of upgrade was less than $100 
and it improved startup time significantly. Maybe you are overestimating 
hardware requirements of desktop environments. While sometimes it is 
hard to control precise behavior of DE, some features (hard to configure 
from scratch) works out of the box, so it is a trade-off.

> You may find https://wiki.gentoo.org/wiki/Default_applications useful. I
> also don't use desktop environment and had to setup defaults manually.

I can not say that this page is enlightening. In particular I do not 
like that it does not describe mimeapps.list files in more details. 
Various tool actually update this file. I have not summarized my 
bookmarks and notes on MIME and scheme handlers, but the following link 
may be useful even when gnome specific stuff is ignored:
https://help.gnome.org/admin/system-admin-guide/stable/mime-types-custom-user.html.en

Re: [PATCH] Add make target to ease creating reproducers and testing them

[Christopher M. Miles]

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


I agree this idea, this could unify the reproduce steps and help some user save time and help
org-mode maintainer get information they want.

Ihor Radchenko <yantar92@gmail.com> writes:

> Hi,
>
> In the Feedback section of the manual, we provide instructions on how to
> create reproducers: https://orgmode.org/manual/Feedback.html
>
> The instructions are nice, but I was thinking to simplify things for the
> users further.
>
> I propose a new make target: make repro
> It will run the commands we already suggest, but without a need to
> create minimal file, pass all that arguments to emacs, etc
>
> WDYT?
>
> Best,
> Ihor
>
> From 8d5f9f023af18828656df85a0ce4069e004dbf5d Mon Sep 17 00:00:00 2001
> Message-Id: <8d5f9f023af18828656df85a0ce4069e004dbf5d.1651373896.git.yantar92@gmail.com>
> From: Ihor Radchenko <yantar92@gmail.com>
> Date: Sun, 1 May 2022 10:44:10 +0800
> Subject: [PATCH] mk: Add make target "repro" for easy bug testing
>
> * mk/default.mk (REPRO_DEBUG): New custom variable enabling extra
> debugging facilities in Emacs instance open by make repro.
> (REPRO_ARGS): Extra arguments passed to Emacs by make repro.
> (REPRO_INIT):
> (REPRO): Define Emacs cmd for testing.
> * mk/targets.mk (.PHONY):
> (repro): Add new target.
> * doc/org-manual.org (Feedback): Describe the new make target.
> ---
>  doc/org-manual.org |  8 ++++++++
>  mk/default.mk      | 21 +++++++++++++++++++++
>  mk/targets.mk      |  5 ++++-
>  3 files changed, 33 insertions(+), 1 deletion(-)
>
> diff --git a/doc/org-manual.org b/doc/org-manual.org
> index c0bd853ca..6a574977e 100644
> --- a/doc/org-manual.org
> +++ b/doc/org-manual.org
> @@ -269,6 +269,14 @@ ** Feedback
>  (add-to-list 'load-path (expand-file-name "/path/to/org-mode/lisp"))
>  #+end_src
>  
> +If you are using Org mode version from Git repository, you can start
> +minimal session using make.
> +
> +: # Bare Emacs
> +: make repro
> +: # or pass extra arguments
> +: make repro REPRO_ARGS="-l /path/to/minimal/config.el /tmp/bug.org"
> +
>  If an error occurs, a "backtrace" can be very useful---see below on
>  how to create one.  Often a small example file helps, along with clear
>  information about:
> diff --git a/mk/default.mk b/mk/default.mk
> index 804089280..33e737da3 100644
> --- a/mk/default.mk
> +++ b/mk/default.mk
> @@ -59,6 +59,11 @@ BTEST_OB_LANGUAGES = awk C fortran maxima lilypond octave perl python
>  # extra packages to require for testing
>  BTEST_EXTRA =
>                # ess-site  # load ESS for R tests
> +# Whether to activate extra debugging facilities for make repro.
> +REPRO_DEBUG ?= yes
> +# Extra arguments passed to Emacs for make repro.
> +# e.g. -l config.el /tmp/bug.org
> +REPRO_ARGS ?=
>  ##->8-------------------------------------------------------------------
>  ## YOU MAY NEED TO ADAPT THESE DEFINITIONS
>  ##----------------------------------------------------------------------
> @@ -93,6 +98,22 @@ BTEST = $(BATCH) $(BTEST_INIT) \
>  # should be useful for manual testing and verification of problems.
>  NOBATCH = $(EMACSQ) $(BTEST_INIT) -l org -f org-version
>  
> +ifeq ($(REPRO_DEBUG), yes)
> +REPRO_INIT = --eval "(setq \
> +	debug-on-error t\
> +	debug-on-signal nil\
> +	debug-on-quit nil\
> +	org-element--cache-self-verify 'backtrace\
> +	org-element--cache-self-verify-frequency 1.0\
> +	org-element--cache-map-statistics t)"
> +else
> +REPRO_INIT =
> +endif
> +
> +# Running a plain emacs with no config, this Org mode loaded, and
> +# debugging facilities activated.
> +REPRO = $(NOBATCH) $(REPRO_INIT) $(REPRO_ARGS)
> +
>  # start Emacs with no user and site configuration
>  # EMACSQ = -vanilla # XEmacs
>  EMACSQ  = $(EMACS)  -Q
> diff --git a/mk/targets.mk b/mk/targets.mk
> index 6de77b1e6..5cba63e21 100644
> --- a/mk/targets.mk
> +++ b/mk/targets.mk
> @@ -41,7 +41,7 @@ endif
>  	cleanlisp cleandoc cleandocs cleantest \
>  	compile compile-dirty uncompiled \
>  	config config-test config-exe config-all config-eol config-version \
> -	vanilla
> +	vanilla repro
>  
>  CONF_BASE = EMACS DESTDIR ORGCM ORG_MAKE_DOC
>  CONF_DEST = lispdir infodir datadir testdir
> @@ -132,6 +132,9 @@ $(INSTSUB):
>  autoloads: lisp
>  	$(MAKE) -C $< $@
>  
> +repro: cleanall autoloads
> +	-@$(REPRO) &
> +
>  cleandirs:
>  	$(foreach dir, $(SUBDIRS), $(MAKE) -C $(dir) cleanall;)


-- 
[ stardiviner ]
       I try to make every word tell the meaning that I want to express.

       Blog: https://stardiviner.github.io/
       IRC(freenode): stardiviner, Matrix: stardiviner
       GPG: F09F650D7D674819892591401B5DF1C95AE89AC3

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: [PATCH] Add make target to ease creating reproducers and testing them

[Ihor Radchenko]

Ihor Radchenko <yantar92@gmail.com> writes:

> I propose a new make target: make repro
> It will run the commands we already suggest, but without a need to
> create minimal file, pass all that arguments to emacs, etc

Applied onto main via b713b9afa.

Best,
Ihor

Re: [PATCH] Add make target to ease creating reproducers and testing them

[Max Nikulin]

On 22/07/2022 20:37, Ihor Radchenko wrote:
> Ihor Radchenko writes:
> 
>> I propose a new make target: make repro
>> It will run the commands we already suggest, but without a need to
>> create minimal file, pass all that arguments to emacs, etc
> 
> Applied onto main via b713b9afa.

I have realized that the new target is not documented in
https://orgmode.org/worg/dev/org-build-system.html
and in the top-level Org Makefile.

P.S. I am unsure whether I have ever seen a convention suggesting to 
implement "make targets" or "make help". The following threads have no 
links:

Jude DaShiell. org-mode documentation question. Thu, 23 Jun 2011 
23:56:46 -0400 (EDT)
https://list.orgmode.org/alpine.BSF.2.00.1106232347590.38595@freire1.furyyjbeyq.arg/T/#u

Jude DaShiell. Makefile patch to show targets.  Mon, 4 Jul 2011 18:12:15 
-0400 (EDT)
https://list.orgmode.org/alpine.BSF.2.00.1107041810590.26958@freire1.furyyjbeyq.arg/T/#u

and "targets … mandated by GNU Makefile conventions" appeared on worg a 
year later:
8ebdc15f 2012-08-19 12:21:33 +0200 Achim Gratz: Build System: add target 
descriptions