Rob,

I made a couple of false starts on merging master into utf8, but I think I k=
now how to do it now.

The awkward bits are where .pp files involve edits in areas which previously=
 contained ext characters, because the merge would re-introduce the ext char=
acters into a utf8 file.=20
So I asked grok to make a command to fix those edits and it came up with thi=
s.

(defun my/pipe-pp-file-conv ()
  "Pipe the selected region through pp_file_conv and replace the region with=
 the output."
  (interactive)
  (if (use-region-p)
      (shell-command-on-region
       (region-beginning)
       (region-end)
       "pp_file_conv"
       t t)
    (message "No region selected")))

;; Bind to a key, e.g., C-c p
(global-set-key (kbd "C-c p") #'my/pipe-pp-file-conv)

(Not tried it yet.)

If you could decide whether the xpp changes will be better done by you than b=
y the git merge I'll hold off till you reach a verdict.

I think the build issues I was thinking of include the C compilers getting m=
ore picky.

Roger

> On 16 Apr 2025, at 23:29, Rob Arthan <[email protected]> wrote:
>=20
> =EF=BB=BFRoger,
>=20
> The main changes I am aware of on master are:
>=20
> (1) some updates to xpp to add a bracket matching capability. It would pro=
bably be best if I merged those into the utf8 branch via the utf8xpp branch,=
 as I now the xpp code.
> (2) Some small additions to the proof support for Z that D-RisQ needed. Yo=
u would probably be best placed to merge those, as you know more about the c=
onversion from EXT to UTF8.
>=20
> I don=E2=80=99t know what you mean by the commits that "address problems a=
rising in the build". Which commits did you have in mind?
>=20
> It would be good at least to keep the utf8 work in sync with other develop=
ments, so I=E2=80=99d be very grateful if you did spend some time on this. I=
f you feel really keen, would you be able to set up a Linux environment so t=
hat we could try to make some progress on the issues with sieve? (If you rem=
ember, when I tried to build our utf8 work on Linux, the utf8 support in gcc=
 on Linux turned out to martinetishly reject code and data that was OK on Ma=
c OS).
>=20
> Regards,
>=20
> Rob.
>=20
>> On 14 Apr 2025, at 23:08, Roger Jones <[email protected]> wrote:
>>=20
>> Rob,
>>=20
>> The master branch of ProofPower is 35 commits ahead of utf8, and some of t=
hose commits address problems arising in the build which now prevent the utf=
8 branch from building.
>>=20
>> Do you have any sense of how much of it might need to be retrofitted for u=
tf8 to build?
>>=20
>> Is it likely that a pull request would facilitate applying those commits t=
o the utf8 branch, or is might there be a better way to approach it?
>>=20
>> This is not a big issue for me, but if it can be sorted without too much e=
ffort I=E2=80=99m willing to put a bit of time in, I converted all my ProofP=
ower scripts to utf8 back in the day.
>>=20
>> Roger
>=20


_______________________________________________
Proofpower mailing list
[email protected]
http://lemma-one.com/mailman/listinfo/proofpower_lemma-one.com

Reply via email to