[Top][All Lists]

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

Re: emacs --batch and --geometry (no joke)

From: Sven Bretfeld
Subject: Re: emacs --batch and --geometry (no joke)
Date: 16 Mar 2011 13:33:08 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux)

Hi Tim 

Yes, that's strange. I have solved the problem with some sed operations
now. But it's only a workaround.



Tim X <address@hidden> writes:

> "Sven Bretfeld" <address@hidden> writes:
>> Hi to all
>> This might seem an absurd question. I'm looking for a possibility to
>> start emacs --batch with geometry parameters. Of course, I know that
>> emacs --batch will have no frame.
>> The reason is this: I start emacs --batch as a cronjob to regularly
>> create some html files of org-agenda-views (org-export-as-html). How the
>> html files look like is dependent on the frame-size in which the export
>> is done. So, in batch-mode there are many line-breaks and the output
>> looks ugly. The default frame-size set in a load-file is ignored, as
>> well as a --geometry option.
>> It would be an option to execute the export function with run-at-time
>> within my always running Emacs session (daemon), but since the function
>> needs some time to finish, my workflow would be interrupted for about 20
>> seconds.
>> The only workaround I can imagine, is an always running independent
>> Emacs session which runs the function regularly via run-at-time. 
> I must be missing something, but I would suggest something is very wrong
> with the HTML generation if it depends on the size of the frame/window
> it will be browsed in at a later time or even worse, the size of the
> window/frame at the time it is generated. A major aim of HTML was/is to
> provide a markup language that can be rendered by clients using
> different display parameters (i.e. window size, font size, etc).
> As far as I know, there is no way of having both -batch and -geometry
> mean something at the same time. Part of the rationale behaind batch is
> to speed things up by not having to worry about all the display stuff.
> I'd be looking at the html generation to find out what it is doing that
> 'hard codes' display sizes and remove that. Such formatting should be
> left to the client, not the generator of the HTML (yes, you may need to
> use additional techniques, such as CSS div etc and provide enough
> details to the client so that it will render appropriately). 
> Tim

reply via email to

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