texmacs-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Texmacs-dev] Absolute versus relative file:... paths


From: David Allouche
Subject: Re: [Texmacs-dev] Absolute versus relative file:... paths
Date: Mon, 9 Feb 2004 14:20:50 +0100
User-agent: Mutt/1.5.5.1+cvs20040105i

On Thu, Feb 05, 2004 at 11:50:39AM -0700, Nix wrote:
> On Thu, 2004-02-05 at 02:06, David Allouche wrote:
> > This kind of problem has been known for a long time, if that really
> > bothers you, you should scratch your own itch and submit a patch.
> 
> LOL :o)
> 
> Unfortunately, this sounds like a really sticky problem.  It also sounds
> like the following logic might be something we need:
> 
> upon linking a new image:
> if unnamed document then
>   use absolute paths
> else
>   use relative paths

That's more or less what is done currently, modulo the (maybe already
fixed) problem that the first-time saving may not be correctly recorded
so subsequent image links are created relative.

> upon saving:
> if save-for-the-first-time then
>   convert-all-paths-to-relative
> save

Currently, texmacs never modifies the document contents in the back of
the user. I agree that, most of the time, this logic would yield the
expected result.

In my opinion, the case where some images were intentionally linked with
an absolute path before the initial save is not important enough to
warrant preserving that rule or adding an interaction step saying
"preserve links to images with absolute file names?".

So, all things considered, I think that would be the best thing to do.

> Unfortunately this implies one of 2 things:
> 
> Either modify the save operation to also change absolute paths into
> relative paths based on the value of a boolean
> 
> void save_the_buffer (int bConvertPaths, rest_of_the_parameters)
> 
> or write a new function which traverses the document prior to saving
> it.  This would make saving-for-the-first-time a two-pass process.

First of all, texmacs c++ source does not use mixedCase variable names.
Instead it follows the standard GNU naming_style_with_underscores.
Scheme code uses conventional dash-separated-names.

I do not see how points 1 (modifying the buffer saving routine) and 2
(making first-time-save a two-pass process) are exclusive. Anyhow you'll
be doing it, you will need to modify the document saving process and to
use a procedure to convert the absolute paths to relative paths.

The conversion procedure should be written in scheme, by iterating over
the buffer's tree and modifying it with tm-assign (on the file-name part
of "postscript" nodes). Be careful, tm-assign and similar functions are
all but foolproof, using a wrong path will cause an instant crash. This
will preserve the caret and saved positions and minimize retypesetting
time. The code should likely go in the "convert/tmtm" directory.

I have just been writing some plugin code to make this kind of
conservative buffer transformation easy. I think I will submit it as a
patch, because it is such a fundamental facility.

You should first investigate whether the first-time saving logic can be
added by only editing the Scheme code. The policy is that all such
application logic should be written in Scheme.

> Another weakness I see with this logic is that it creates coupling
> between the process of saving a file and the process of linking in
> images.  Such coupling may be undesired.

As I exposed, this would only be problematic in an IMHO unimportant
corner case.

-- 
                                                            -- ddaa




reply via email to

[Prev in Thread] Current Thread [Next in Thread]