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

[Sven Bretfeld]

Hi Tim 

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

Greetings,

Sven

Tim X <timx@nospam.dev.null> writes:

> "Sven Bretfeld" <sven.bretfeld@gmx.ch> 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