Hi Alan,
Alan Schmitt writes:
>>> I tried to fix it in the updated attached patch. I set a default value
>>> of "foldmarks-not-set" to the predicate that detects if it is set in the
>>> file, then I compare its contents. This assumes that the user will not
>>> give this literal value to the opt
Hi Rasmus,
alan.schm...@polytechnique.org writes:
> alan.schm...@polytechnique.org writes:
>
>> I tried to fix it in the updated attached patch. I set a default value
>> of "foldmarks-not-set" to the predicate that detects if it is set in the
>> file, then I compare its contents. This assumes tha
ras...@gmx.us writes:
> As Viktor argues, mainly ugly and fragile solutions exist to check the
> LCO file (e.g. find the file with kpsewhich in texlive). Yet, it
> doesn't matter, as all you care about it the location of the variable
> /depending/ on whether it's set in the buffer.
>
> E.g.
>
>
Alan Schmitt writes:
>>> I could not find a way to do it another way, but I'll gladly take any
>>> suggestion. What we want is:
>>> - if email is set in the file, use it;
>>> - otherwise, use the one from the lco;
>>> - otherwise, use the default one.
>>
>> (PREAMBLE-STRINGDEFAULT-VALUES
Hi Rasmus,
ras...@gmx.us writes:
>>> I also find something like this ghastly:
>>>
>>> But perhaps it is the only way to get what you want.
>>
>> I could not find a way to do it another way, but I'll gladly take any
>> suggestion. What we want is:
>> - if email is set in the file, use it;
>> - oth
Alan,
> Sorry for the delay, I was in vacations with tethering-only internet
> access.
No worries. A tethering-only vacation sounds great!
>> I spoke too early. For example this letter no longer works as usual:
>>
>> #+TITLE: test
>> #+OPTIONS: foldmarks:nil
>> * Letter
>> my letter
>> ** TO
alan.schm...@polytechnique.org writes:
> I tried to fix it in the updated attached patch. I set a default value
> of "foldmarks-not-set" to the predicate that detects if it is set in the
> file, then I compare its contents. This assumes that the user will not
> give this literal value to the optio
Hello Rasmus,
Sorry for the delay, I was in vacations with tethering-only internet
access.
ras...@gmx.us writes:
> The following message is a courtesy copy of an article
> that has been posted to gmane.emacs.orgmode as well.
>
> Rasmus writes:
>
>> Alan,
>>
>>> alan.schm...@polytechnique.org wr
Rasmus writes:
> Alan,
>
>> alan.schm...@polytechnique.org writes:
>>
>>> Yes, this is not satisfactory (and the email and author is also
>>> problematic in this regard). We need to know whether an option was set
>>> in the file, independently of its default value. Is there a way to do
>>> this?
Alan,
> alan.schm...@polytechnique.org writes:
>
>> Yes, this is not satisfactory (and the email and author is also
>> problematic in this regard). We need to know whether an option was set
>> in the file, independently of its default value. Is there a way to do
>> this?
>
> Thanks to Nicolas, I'v
alan.schm...@polytechnique.org writes:
> Yes, this is not satisfactory (and the email and author is also
> problematic in this regard). We need to know whether an option was set
> in the file, independently of its default value. Is there a way to do
> this?
Thanks to Nicolas, I've been able to cr
n.goaz...@gmail.com writes:
> Alan Schmitt writes:
>
>> This is a promising approach. Unfortunately I cannot make it work:
>> email-changed-in-buffer-p is always equal to nil, even with an EMAIL in
>> the buffer (which I see picked up during export).
>>
>> Here is what I have. This is the code to
Alan Schmitt writes:
> This is a promising approach. Unfortunately I cannot make it work:
> email-changed-in-buffer-p is always equal to nil, even with an EMAIL in
> the buffer (which I see picked up during export).
>
> Here is what I have. This is the code to set up the EMAIL keyword:
>
> (:
Hello Nicolas,
n.goaz...@gmail.com writes:
> Hello,
>
> Alan Schmitt writes:
>
>> Yes, this is not satisfactory (and the email and author is also
>> problematic in this regard). We need to know whether an option was set
>> in the file, independently of its default value. Is there a way to do
>>
Hello,
Alan Schmitt writes:
> Yes, this is not satisfactory (and the email and author is also
> problematic in this regard). We need to know whether an option was set
> in the file, independently of its default value. Is there a way to do
> this?
I didn't follow this thread closely, but to answ
Hi Rasmus and Viktor,
listuse...@gmail.com writes:
> Hi,
>
> Alan Schmitt wrote:
>
>> - (format "\\KOMAoption{backaddress}{%s}\n" (if with-backaddress "true"
>> "false"))
>> - (format "\\KOMAoption{foldmarks}{%s}\n" (if with-foldmarks
>> with-foldmarks "false"))
>> - (format "\\K
Hi Viktor and Allan,
>> I think we need to treat koma variables more generally (I have some
>> sketches locally) if anything. Not make their behavior more
>> specialized.
>
> Could you elaborate on what you mean by this?
I want to be able to generate and set /any/ Koma variable from emacs,
incl
Hi,
Rasmus wrote:
> I think we need to treat koma variables more generally (I have some
> sketches locally) if anything. Not make their behavior more
> specialized.
Could you elaborate on what you mean by this?
> But you'd still end up with
> two emails in your file, and if you lost the LCO f
Hi,
Alan Schmitt wrote:
> - (format "\\KOMAoption{backaddress}{%s}\n" (if with-backaddress "true"
> "false"))
> - (format "\\KOMAoption{foldmarks}{%s}\n" (if with-foldmarks
> with-foldmarks "false"))
> - (format "\\KOMAoption{fromphone}{%s}\n" (if with-phone "true" "false"))
> -
Alan Schmitt writes:
> I did some experiments and it seems that by default "foldmarks" is
> true. The idea behind the patch is that, if we don't change the default
> values, then things are not output. Let me know if this is fine with you
> and I'll commit this. (I'll also edit the work with the
Hello,
ras...@gmx.us writes:
> Viktor Rosenfeld writes:
>
>>> ,
>>> | \KOMAoption{backaddress}{true}
>>> | \KOMAoption{foldmarks}{true}
>>> | \KOMAoption{fromphone}{true}
>>> | \KOMAoption{fromemail}{true}
>>> `
>>
>> Perhaps the best option would be to change the default value of these
Viktor Rosenfeld writes:
>> ,
>> | \KOMAoption{backaddress}{true}
>> | \KOMAoption{foldmarks}{true}
>> | \KOMAoption{fromphone}{true}
>> | \KOMAoption{fromemail}{true}
>> `
>
> Perhaps the best option would be to change the default value of these
> variables to nil? We have almost every o
Viktor Rosenfeld writes:
> Hi Alan,
>
> Alan Schmitt wrote:
>
>> Hello,
>>
>> I just had to write a new letter with a fresh LCO file, and I would like
>> to propose to change the priority of options. The current priority is:
>> local options > emacs variables > lco file.
>>
>> Unfortunately emac
Hi Alan,
Alan Schmitt wrote:
> Hello,
>
> I just had to write a new letter with a fresh LCO file, and I would like
> to propose to change the priority of options. The current priority is:
> local options > emacs variables > lco file.
>
> Unfortunately emacs variables have a default value, which
24 matches
Mail list logo
