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