On 5/28/2020 5:59 PM, Marco Patzer wrote:

On Thu, 28 May 2020 17:33:19 +0200 Hans Hagen wrote:

...

On 5/28/2020 2:49 PM, Marco Patzer wrote:

...

Hi!

LMTX and MkIV behave differently if dots are used in the file name. Example:

printf '%s\n' '\starttext\null\stoptext' > foo.10.tex && context foo.10.tex

MkIV: → foo.10.pdf LMTX: → foo.pdf

Is this intentional?

consider it to be so

That's unfortunate.

1) The editor workflow with simple suffix replacement .tex → .pdf to open the corresponding PDF file doesn't work any more with lmtx. New logic is needed to find the correct pdf file name.

2) A project (of mine) that uses item numbers as file names (containing dots) compile to the same pdf:

MkIV (everything's predictable and fine): 10.10.10.tex → 10.10.10.pdf 10.10.11.tex → 10.10.11.pdf 11.10.11.tex → 11.10.11.pdf

LMTX: 10.10.10.tex → 10.10 (not even a PDF suffix) 10.10.11.tex → 10.10 (file 10.10 is over-written) 11.10.11.tex → 11.10 (no suffix)

MkIV is way more predictable and consistent in that regard. I'll look at it but not today ... first I need to play with some other (neat) stuff and run tests.

Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------

On 5/28/2020 8:31 PM, Marco Patzer wrote:

On Thu, 28 May 2020 18:18:51 +0200 Hans Hagen wrote:

...

...

MkIV (everything's predictable and fine): 10.10.10.tex → 10.10.10.pdf 10.10.11.tex → 10.10.11.pdf 11.10.11.tex → 11.10.11.pdf

LMTX: 10.10.10.tex → 10.10 (not even a PDF suffix) 10.10.11.tex → 10.10 (file 10.10 is over-written) 11.10.11.tex → 11.10 (no suffix)

MkIV is way more predictable and consistent in that regard.

I'll look at it but not today ... first I need to play with some other (neat) stuff and run tests.

OK, thanks. No hurry. The production projects run on some oldish 2019 MkIVs anyway. I'm trying to get my feet wet with lmtx and run it on some projects to check how usable and compatible it is. It should be compatible, although at some point there will be functionality that is only in lmtx. Okay, metapost is an exception, because there is a lot in lmtx that is not in mkiv, but that's a separate subsystem anyway.

Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------

This is something that has caused me problems in the past, too. On Tue, Jul 6, 2021 at 4:51 PM Marco Patzer wrote:

On Thu, 28 May 2020 18:18:51 +0200 Hans Hagen wrote:

...

...

LMTX: 10.10.10.tex → 10.10 (not even a PDF suffix) 10.10.11.tex → 10.10 (file 10.10 is over-written) 11.10.11.tex → 11.10 (no suffix)

I've checked again with 2021.07.06 18:49 LMTX

10.10.10.tex → 10.10.pdf + 10.log 10.10.11.tex → 10.10.pdf (file 10.10.pdf and 10.log are over-written) 11.10.11.tex → 11.10.pdf

...

...

MkIV is way more predictable and consistent in that regard. I'll look at it but not today ... first I need to play with some other (neat) stuff and run tests.

A gentle reminder.

As by my tests, something has changed in the last months, but the behaviour is still weird (e.g. log files differ from pdf file or 10.10.10.tex results in 10.10.pdf).

Is there a chance you can look at that at some point?

Marco

___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net

___________________________________________________________________________________

-- T. Kurt Bond, tkurtbond@gmail.com, https://tkurtbond.github.io

Am Wed, 7 Jul 2021 12:25:29 -0600 schrieb Alan Braslau:

Windows, I believe, does not take kindly to filenames containing multiple dots.

Therefore, Hans never uses such filenames and does not expect them, either, so I am not surprised that this yields unpredictable results.

An unfortunate side-effect of dealing with Windows.

Sorry but this is nonsense. I have seen many files with lots of dots in windows and it works fine. I wouldn't do it in tex, but not because of the OS but because until a few years you could run into problems with some tex applications or macros which didn't expect many dots. -- Ulrike Fischer https://www.troubleshooting-tex.de/

On 7/8/2021 8:13 PM, Alan Braslau wrote:

(and for Hans, the VMS ";" version specification is a different feature). Sure, one being that one ran out of disk space (but there were enough unused accounts with simple passwords to take care of backups) but it would add an interesting challenge (probably some extra parameter in opening a file).

(btw, no tex on these vax machines, pretty unknown at that time so we rolled out our own ascii-art formatting / pagination) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------

On 7/7/2021 10:13 PM, Marco Patzer wrote:

But maybe Hans can chime in and clarify. I have to check it but syffixes and tex are kind of special. It has nothing to do with operating systems (sorry for those who love to bash windows for it). Personally I always use a suffix and don't look into files without them. (On VMS we even had version numbers with the name, which was also nice.) That said:

- tex needs to make a log file and an output file (.log, .pdf and maybe more like .tuc) - so, it determines a jobname, which is the input file with the suffix removed - actually it adds a suffix .tex when there is none and then looks for that file - in that respect, .10 is a suffix as is .foo or .pointless - in tds/kpse/web2c there were flags for 'multiple suffixes' (which of course also introduces compatibility issues) - as a side note: filenames are case sensitive unless the operating system makes them insensitive; this has long been yet another reason for bashing windows, but it looks like kpse/web2c now decided it's a good idea so there's also a flag (i think itis true by default) that enables insentivity (context always tried to be insensitive and mkiv/lmtx definitely is) Now, to the issue of names like 10.11.12.13 ... here .13 is the suffix, like it or not, so in principle we then get 10.11.12.log 10.11.12.tuc 10.11.12.pdf if not then indeed there is some issue. Now, although it's quite some work, one can think of seeing .13 as part of the filename, in which case the lookupe becomes 10.11.12.13.tex but we can optionally first check for 10.11.12.13 ... however, because there are many possibel suffixes (.tex being one of them) we then get 10.11.12.13.log 10.11.12.13.tuc 10.11.12.13.pdf but in the case of 10.11.12.13.tex we get 10.11.12.13.tex.log 10.11.12.13.tex.tuc 10.11.12.13.tex.pdf because there is no way to determine any longer that .tex is special (one can argue that .mk* also qualifies but what about .xml and all variants on that). Al this means that personally I always stick to (1) lowercase filenames (2) with no spaces (3) only a-z, A-Z, 0-9, and - (4) always with a suffix ... it never gives issues. (If you ever had to deal with third party files, especially graphics made by third parties, you'd know that most problems come from bad filenames where for instance a single space or multiple spaces and/or funny mixes in case get unnoticed.) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------

On 7/8/2021 3:38 PM, Marco Patzer wrote:

On Thu, 8 Jul 2021 10:34:32 +0200 Hans Hagen wrote:

...

Now, to the issue of names like 10.11.12.13 ... here .13 is the suffix, like it or not, so in principle we then get

10.11.12.log 10.11.12.tuc 10.11.12.pdf

It's not that I use files without (.tex, .mkiv, ...) suffixes, but your 10.11.12.13 example is processed by MkIV without problems:

10.11.12.pdf 10.11.12.tua 10.11.12.log

actually that's also not ok as it should be a .tuc file

LMTX, however doesn't like it:

10.11.pdf 10.11.tua 10.log

...

if not then indeed there is some issue.

According to my tests LMTX doesn't work like you describe it should. i'll check it

(in retrospect tex could better have enforced a suffix and not fallback on .tex but i suppose the usage scenarios were hard to foresee let alone the restart-the-program-time-penalty when you forgot to add .tex) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------

On Thu, 28 May 2020 17:33:19 +0200 Hans Hagen wrote:

On 5/28/2020 2:49 PM, Marco Patzer wrote:

...

Hi!

LMTX and MkIV behave differently if dots are used in the file name. Example:

printf '%s\n' '\starttext\null\stoptext' > foo.10.tex && context foo.10.tex

MkIV: → foo.10.pdf LMTX: → foo.pdf

Is this intentional?

consider it to be so

That's unfortunate. 1) The editor workflow with simple suffix replacement .tex → .pdf to open the corresponding PDF file doesn't work any more with lmtx. New logic is needed to find the correct pdf file name. 2) A project (of mine) that uses item numbers as file names (containing dots) compile to the same pdf: MkIV (everything's predictable and fine): 10.10.10.tex → 10.10.10.pdf 10.10.11.tex → 10.10.11.pdf 11.10.11.tex → 11.10.11.pdf LMTX: 10.10.10.tex → 10.10 (not even a PDF suffix) 10.10.11.tex → 10.10 (file 10.10 is over-written) 11.10.11.tex → 11.10 (no suffix) MkIV is way more predictable and consistent in that regard. Marco