Display ellipsis at end of headline instead of after tags

2021-01-10 Thread Stefan Nobis
Hi.

I would prefer to see headline ellipsis always at the end of the
headline, but if tags are present, the ellipsis is drawn after the
tags.

So currently I have something like this:

#+begin_example
,* Headline One...
,* Another Headline  :tag:another:...
,* Third Headline...
#+end_example

But I would prefer this:

#+begin_example
,* Headline One...
,* Another Headline...   :tag:another:
,* Third Headline...
#+end_example

I skimmed through available variables and the code, but I found
nothing to configure this kind of behaviour. Is there an easy way to
accomplish this?

-- 
Until the next mail...,
Stefan.



Re: Microsoft Excel spreadsheet editing directly from within emacs.

2020-12-31 Thread Stefan Nobis
Jean Louis  writes:

> You speak of a programming language and what is possible with
> programming language.

That's not the point. Org table is integrated with Calc and Calc is a
Computer Algebra System. That is something like Excel combined with
Mathematica (with a little less GUI stuff) - that is powerful
integration to me.

Lisp is nice and for me as a programmer a helpful tool. But the main
point is Calc.

Just putting data in a tabulated form is seldom the interesting part.
It starts to get interesting when you try to do something with the
data, e.g. make some calculations. At this point it is significant,
how many calculations you can do out-of-the box (without much
programming). I did not count, but I assume that Calc has more
calculations to offer than Excel and even for a wider range of topics
(even symbolic math).

Therefore, from this point of view of core functionality, I would say
Org tables with Calc are more powerful that MS Excel. And thinking of
the many quirks and bugs in MS Excel, I still say: Excel is the toy
software and Emacs + Org + Calc is more mature and more professional
and the file format much more future proof (yes, nowadays Excel uses
XML, but the definition and documentation is lacking and too complex;
it seems not possible to re-implement it fully).

I emphasize this, because you wrote: "In comparison to all major known
spreadsheets Org tables is not powerful and not even comparable."

And "powerful" for me means core features, i.e. calculations. And in
this respect, I think the statement is wrong.

> In a spreadsheet program I may visually and nicely presented see a
> slice of a whole table. I may move from slice to slice to other
> pieces of the whole table of data. Moving from cell to cell is
> pretty easy and there are no screen distortions.

If your point of view is, that the main feature are the visual
interactions (hiding/revealing rows/columns, sorting, filtering data
etc.) then yes, maybe Org lacks a bit in these areas (but I think not
quite as much, as you imply; e.g. Org can show labels for rows and
columns and there are ways for hiding, sorting and filtering).

On the other hand: I do find GUI spreadsheets also quite lacking in
this regard (e.g. regex pattern are seldom easy to use). If I need to
tinker with data, explore it, I would put it into a database (or into
R or Julia or - depending on the size of the data - using R/Julia from
within Emacs via Org tables). That's much faster, maintainable and
reproducible.

> Spreadsheet user interface is integrated, it does not require user
> to remember much, or maybe nothing, just use a mouse.

Nice try: There are tons of books about the question what are the best
user interfaces. I have seen people working with computers with
exactly this mindset: "I do not need to learn/remember anything, it
should be easy, just clicking a bit with my mouse". At this level, it
just does not work.

So, yes, a very text-oriented UI is not the best solution for every
task. But then a GUI is also not the best solution for every task.

> Org mode is bringing us back into the era before Doug Engelbart.
> Back to history.

That's IMHO a very simplistic and ignorant view on UX. The problem is
much more complex and yes, in quite some cases are text-based
interfaces even one of the best solutions (and next to never exists a
single best solution, UX always depends very strongly on context and
details).

> Combining various sheets is standard spreadsheet feature. Examples
> you have shown are cryptic for spreadsheet users.

I once showed rather simple Excel sheet to an Excel user and he was
overwhelmed and did not understand how to create such a structure (2-3
tables with formulas across tables). So Excel is cryptic for
spreadsheet users, too. :)

With other words: No tool is simple, you need to learn at least a
little bit - in all cases. I only showed the final result, not the way
how it has been created. Emacs and Org have ways to ease some of the
seemingly complicated parts, just as Excel tries to help formulate
complicated calculations. And then comes habit.

I fully understand that a tool like Excel at least seems to be easier
for the first steps. But that does not mean that it is a given fact,
that it is easier and better suited for any task that is spreadsheet
like (you already mentioned databases - I would say for the typical
spreadsheet users databases are even more cryptic that Emacs and Org).

>> Maybe advanced visual presentation of the data is easier with GUI
>> Spreadsheets -- then again, it is so easy to combine Org tables with
>> the power of Gnuplot, R, Python, Julia, TeX etc. to create
>> astonishing visuals, that I prefer this way in many situations.

> That is like saying to a user to switch from Emacs to C programming
> language as it gives user far more capabilities

No, quite the contrary. I think, this is the main point, you seem not
to understand. Emacs with Elisp is much more expressive than C. Org
with Calc is (for 

Re: Microsoft Excel spreadsheet editing directly from within emacs.

2020-12-29 Thread Stefan Nobis
Jean Louis  writes:

> I find Org tables useful for small reports. Just as table mode is
> also useful within Emacs. Org tables are primitives that are not
> comparable to spreadsheet software.

It might be a difficult question, whether Org tables are the best
solution in a given situation or whether it is the best interchange
format to use with arbitrary people (but I also doubt that MS Excel is
a good way - I have seen really nasty and expensive problems caused by
the use of Excel to move data around).

But Org tables are very powerful and in many cases even far superior
than most other spreadsheet software (especially MS Excel - I can't
count the number of times that Excel tried to be smart and made a
total mess of my data).

Here is a short example of what is possible with Org tables:

#+begin_src org
,* Org Spreadsheet

,** Example from the Manual

See [[https://orgmode.org/manual/Advanced-features.html#Advanced-features][The 
Spreadsheet - Advanced features]].

|---+-+---+-+--|
|   | Func| n | x   | Result   |
|---+-+---+-+--|
| # | exp(x)  | 1 | x   | 1 + x|
| # | exp(x)  | 2 | x   | 1 + x + x^2 / 2  |
| # | exp(x)  | 3 | x   | 1 + x + x^2 / 2 + x^3 / 6|
| # | x^2+sqrt(x) | 2 | x=0 | x*(0.5 / 0) + x^2 (2 - 0.25 / 0) / 2 |
| # | x^2+sqrt(x) | 2 | x=1 | 2 + 2.5 x - 2.5 + 0.875 (x - 1)^2|
| * | tan(x)  | 3 | x   | x pi / 180 + 5.72e-8 x^3 pi^3|
|---+-+---+-+--|
,#+TBLFM: $5=taylor($2,$4,$3);n3

,** Even symbolic math

|-++---|
| Func| Derivative | Integral (over [a, b])|
|-++---|
| x^2 | 2 x| x^3 / 3   |
| exp(x^2)| 2 x exp(x^2)   | erf(i x) sqrt(pi) / (2 i) |
| ln(x^2) | 2 / x  | 2 x ln(x) - 2 x   |
| sqrt(x) | 0.5 / sqrt(x)  | 2:3 sqrt(x^3) |
| 2x + sin(y) | 2  | x^2 + x sin(y)|
| sin(1/x)| cos(1 / x) pi / (-180 x^2) | integ(sin(1 / x), x)  |
|-++---|
,#+TBLFM: $2=deriv($1, x);S::$3=integ($1, x);S

,** Combine data from different tables
,*** Some special expenses
,#+NAME: tab-special
| Position | Amount |
|--+|
| Abo part 1   | 299.22 |
| Abo part 2   | 299.22 |
| Some random item | 210.83 |
|--+|
| Sum  | 809.27 |
,#+TBLFM: @>$2=vsum(@I..II)
,*** Tax calculation for my room
,#+NAME: tab-room
|   | Position   |   Amount |
|---++--|
|   | Area Room  |11.00 |
|   | Area Flat  |77.42 |
|   | Costs per year | 12000.00 |
|   | Some insurance |   300.00 |
|   | Electricity|   700.00 |
|---++--|
| _ ||A |
|   | Area fraction  |  0.14208 |
|   | tax-deductible Rent|  1747.58 |
|   | tax-deductible Electricity |99.46 |
,#+TBLFM: $A=@2$3/@3$3;%.5f::@>>$3=$A*@4$3+$A*@5$3;%.2f::@>$3=$A*@6$3;%.2f
,*** Summary
,#+NAME: tab-summary
| Position   |  Amount | Comment |
|+-+-|
| Special costs  |  809.27 | |
| Deductible Rent| 1747.58 | put in form field A |
| Deductible Electricity |   99.46 | put in form field B |
| Something else | 1234.56 | very special|
|+-+-|
| Sum| 3890.87 | |
,#+TBLFM: @2$2=remote(tab-special,@>$2)
,#+TBLFM: @3$2=remote(tab-room,@>>$3)
,#+TBLFM: @4$2=remote(tab-room,@>$3)
,#+TBLFM: @>$2=vsum(@I..II)
#+end_src

In respect to core features (listing data, using formulas for
calculation) I doubt that Emacs with Org tables and Calc is missing
anything. Maybe advanced visual presentation of the data is easier
with GUI Spreadsheets -- then again, it is so easy to combine Org
tables with the power of Gnuplot, R, Python, Julia, TeX etc. to create
astonishing visuals, that I prefer this way in many situations.

>From my point of view, MS Excel is the toy (I have not too much
experience with the other GUI spreadsheet programs). In Emacs I have
the power of Calc (a complete computer algebra system) and Lisp (the
best programming language, even if Elisp is not Common Lisp) at my
fingertips. 

Re: Changed list indentation behavior: how to revert?

2020-11-17 Thread Stefan Nobis
"Dr. Arne Babenhauserheide"  writes:

> Sad story short:...

I'm with you - last weekend I upgrade my OS and had quite some trouble
to get everything working again and still have some nasty hoops to
jump through.

But on the other side: What are we talking about?

Org had a given default configuration for quite some time. To be
clear: THIS DID NOT CHANGE!

But some people are upset now. Why? Because the emergent behaviour
changed. Not the underlying default configuration, but in the context
and details of how each individual uses Org for some users the default
configuration was emergent and evident, but some other users did not
perceive this default configuration.

Now a simple setting, syncing Org with the defaults of Emacs and other
modes with respect to RET and electric-indent-mode, make the OLD,
UNCHANGED default configuration emergent for almost all users.

These are very subtle effects inside a very complex environment.

How should maintainers be able to foresee all possible environments
and use cases and the resulting emergent behaviour?

I'm really surprised that such a simple and insignificant breaking
change results in such a uproar. If a new Org version make all old
files completely unusable or a bunch of important features is totally
broken, say nothing of babel works anymore - yes, is such a case I
would understand the uproar.

But ranting so loudly and insistent and continuously over such a minor
details is really beyond me.

And nobody has to read all NEWS and Changelogs for every single peace
of software they are using. If nothing breaks maybe there is nothing
to worry about. If some minor detail like the new emergent indentation
behaviour annoys you - just have a quick look in the NEWS file of the
new version. Is this really that hard?

On the other hand: What's the alternative? Never change anything
again? Maybe some users rely on the emergent behaviour of some bad
bug (that has bad consequences for some other users). Should it never
be changed, because it may annoy some users and they could be forced
to read the NEWS file?

You cannot have the cookie and eat it!

So, everyone, please calm down and try not to overreact over really
simple, negligible details.

-- 
Until the next mail...,
Stefan.



Re: New website - back to the old unicorn!

2020-10-29 Thread Stefan Nobis
TEC  writes:

> This seems very suspicious for one reason. I cannot see "Canvas"
> anywhere in the entire codebase of the website, or any loaded
> resources. So I have no idea where on earth the JS you're finding
> has come from - I'm guessing it's improperly injected by a
> extension. FWIW I also run Decentraleyes in Firefox and fail to see
> your issue.

Thanks for your response. So maybe a local error (I think I deactivate
all plugins bug Decentraleyes, but maybe its the combination of
Decentraleyes with Vivaldi or I made another mistake). I will
investigate further when I have a bit more time. For now please assume
this issue as resolved. :)

-- 
Until the next mail...,
Stefan.



Re: New website - back to the old unicorn!

2020-10-28 Thread Stefan Nobis
Hi.

Thanks for your great work and the wonderful new page!

A minor detail: I use the plugin "Decentraleyes" and with this
activated there is quite a bit JavaScript garbage at the end of the
page (below the "Created by" footer). The part below the footer is
this:

#+begin_src js
{ const iframes = window.top.document.querySelectorAll("iframe[sandbox]"); for 
(var i = 0; i < iframes.length; i++) { if (iframes[i].contentWindow) { if 
(iframes[i].contentWindow.CanvasRenderingContext2D) { 
iframes[i].contentWindow.CanvasRenderingContext2D.prototype.getImageData = 
CanvasRenderingContext2D.prototype.getImageData; } if 
(iframes[i].contentWindow.HTMLCanvasElement) { 
iframes[i].contentWindow.HTMLCanvasElement.prototype.toBlob = 
HTMLCanvasElement.prototype.toBlob; 
iframes[i].contentWindow.HTMLCanvasElement.prototype.toDataURL = 
HTMLCanvasElement.prototype.toDataURL; } } } }{ const iframes = 
window.top.document.querySelectorAll("iframe[sandbox]"); for (var i = 0; i < 
iframes.length; i++) { if (iframes[i].contentWindow) { if 
(iframes[i].contentWindow.CanvasRenderingContext2D) { 
iframes[i].contentWindow.CanvasRenderingContext2D.prototype.getImageData = 
CanvasRenderingContext2D.prototype.getImageData; } if 
(iframes[i].contentWindow.HTMLCanvasElement) { 
iframes[i].contentWindow.HTMLCanvasElement.prototype.toBlob = 
HTMLCanvasElement.prototype.toBlob; 
iframes[i].contentWindow.HTMLCanvasElement.prototype.toDataURL = 
HTMLCanvasElement.prototype.toDataURL; } } } }{ const iframes = 
window.top.document.querySelectorAll("iframe[sandbox]"); for (var i = 0; i < 
iframes.length; i++) { if (iframes[i].contentWindow) { if 
(iframes[i].contentWindow.CanvasRenderingContext2D) { 
iframes[i].contentWindow.CanvasRenderingContext2D.prototype.getImageData = 
CanvasRenderingContext2D.prototype.getImageData; } if 
(iframes[i].contentWindow.HTMLCanvasElement) { 
iframes[i].contentWindow.HTMLCanvasElement.prototype.toBlob = 
HTMLCanvasElement.prototype.toBlob; 
iframes[i].contentWindow.HTMLCanvasElement.prototype.toDataURL = 
HTMLCanvasElement.prototype.toDataURL; } } } }{ const iframes = 
window.top.document.querySelectorAll("iframe[sandbox]"); for (var i = 0; i < 
iframes.length; i++) { if (iframes[i].contentWindow) { if 
(iframes[i].contentWindow.CanvasRenderingContext2D) { 
iframes[i].contentWindow.CanvasRenderingContext2D.prototype.getImageData = 
CanvasRenderingContext2D.prototype.getImageData; } if 
(iframes[i].contentWindow.HTMLCanvasElement) { 
iframes[i].contentWindow.HTMLCanvasElement.prototype.toBlob = 
HTMLCanvasElement.prototype.toBlob; 
iframes[i].contentWindow.HTMLCanvasElement.prototype.toDataURL = 
HTMLCanvasElement.prototype.toDataURL; } } } }
#+end_src

When I deactivate Decentraleyes and reload the page, the above code
snippet vanishes. This glitch is present both on the official page and
on https://orgmode.tecosaur.com. It seems, there is some weird
interaction with some script from a CDN (maybe loaded partially due to
constraints from the plugin) or something like that.

-- 
Until the next mail...,
Stefan.



Re: The Website Revamp: The final stretch

2020-09-22 Thread Stefan Nobis
TEC  writes:

> 2. Picking the best 'Hero banner' on the home page ::

I like Variant 1-1 the most - all other variants are a bit too big and
yelling for my eyes.

Maybe use size and layout of Variant 1-1 with colors of the last
variant (page 9, gray background)?

-- 
Until the next mail...,
Stefan.



Re: basic org questions

2020-09-17 Thread Stefan Nobis
"Thomas S. Dye"  writes:

> There are many pieces of software that will allow the user to the
> violate best typesetting practices easily. LaTeX is not one of them.

Not quite right. I have seen people create really ugly source code
*and* ugly output with LaTeX with ease. You can create garbage with
any kind of software. :)

-- 
Until the next mail...,
Stefan.



Re: basic org questions

2020-09-17 Thread Stefan Nobis
Emanuel Berg via "General discussions about Org-mode."
 writes:

>> #+attr_latex: :center nil :booktabs t
>> | My | Columns |
>> |+-|
>> |  1 |   2 |
>> |  3 |   4 |

> "PDF file produced with errors."

Sorry that I try to make more general examples that are not exactly
tailored to your use case. As I said in the paragraph above that
example, the package "booktabs" is needed (it is one of my default
packages, so in my config it will always be added to LaTeX code
generated by Org). So either add "#+latex_header:
\usepackage{booktabs}" or remove the ":booktabs t" part.

-- 
Until the next mail...,
Stefan.



Re: basic org questions

2020-09-17 Thread Stefan Nobis
Emanuel Berg via "General discussions about Org-mode."
 writes:

> OK, but the values still ned to be specified, right?

No, just use the package - it sets the relevant lengths to change the
style of marking paragraphs and tries hard to also reset every other
length that depends on the original values of these variables.

Here is an example of a quite minimal LaTeX document that should show
the effect:

#+begin_src latex
\documentclass{article}
\usepackage{blindtext}
\usepackage{parskip}
\begin{document}
\Blinddocument
\end{document}
#+end_src

As I said: The lengths parskip and parindent are very far-reaching,
fundamental variables in LaTeX. They are used in many places and
globally setting them may lead to unexpected side-effects.

If you just look at a couple of paragraphs you won't see any problems.
But if you write more complex documents, using packages like listings to
display code, use other environments mixed with paragraphs and lists,
there will occur problems with the spacing.

I don't remember all the details, I just always remember to use either
the package parskip or (in most of my use-cases) the documentclass
option "parskip=full" from the Koma script classes (that I use nearly
exclusively) - when I... consider to use this style of marking
paragraphs. :)

--
Until the next mail...,
Stefan.



Re: basic org questions

2020-09-17 Thread Stefan Nobis
Samuel Wales  writes:

> for my part, i appreciate your using the "wrong" style for your
> email message

A plain text document presented in a monospaced font is quite a
different thing than a (longer) PDF with a plethora of layout and
micro-typographic options.

Do you also appreciate the workarounds to represent complex math
formulas in plain text and do you prefer these workarounds to a nicely
set formula in e.g. a PDF?

So I would say everything depends on the context. In books I very much
prefer the usual style of marking paragraphs by indenting the first
line and no extra space between paragraphs. IMHO much easier to read
(and in case of books with many special elements like formulas also
much less ambiguous).

But in other contexts (even when producing PDFs via LaTeX) other
styles may be preferable. I just add my remarks because I just too
often see the "mail style" marking of paragraphs in longer texts
(reports etc.) where the usual "book style" would be much more
friendly to at least my eyes. Just be aware of the options and try to
find a style that is pleasant to most of your readers. :)

-- 
Until the next mail...,
Stefan.



Re: basic org questions

2020-09-16 Thread Stefan Nobis
Eric S Fraga  writes:

> #+latex_header: \setlength{\parindent}{0pt}
> #+latex_header: \setlength{\parskip}{\baselineskip}

Better use

#+latex_header: \usepackage{parskip}

as this package has less bad side-effects on other parts of the
document than setting these far-reaching lengths directly.

But otherwise I second your recommendation to not use this style of
marking paragraphs if not absolutely required.

-- 
Until the next mail...,
Stefan.



Re: "text mode" org mode

2020-09-16 Thread Stefan Nobis
Emanuel Berg via "General discussions about Org-mode."
 writes:

> Thanks, I wonder tho if all this

>   (setq org-descriptive-links  nil)
>   (setq org-hide-emphasis-markers  nil)
>   (setq org-startup-folded'showeverything)

> is implied, with `visual-mode'?

Beware: =visible-mode= not "visual"!

As far as I understand the internal of Org an Emacs, some of the
visual features of Org are implemented with overlays, some are
implemented with text properties. Disabling visible-mode just makes
invisible text visible - but I do not fully understand whether this
affects really all kinds of "invisibility" or just some.

So I for myself prefer to say Org explicitly what I want instead of
trying to take advantage of an indirect effect that may disturb Orgs
internal state (or not; I just do not understand enough of Org and
Emacs internals to really judge this).

-- 
Until the next mail...,
Stefan.



Re: basic org questions

2020-09-16 Thread Stefan Nobis
Emanuel Berg via "General discussions about Org-mode."
 writes:

> Tim Cross wrote:

>> #+latex_class: korma-article

> user-error: Unknown LaTeX class ‘korma-article’

>> #+latex_header:  \setlength{\parindent}{0pt}

> Yes, that's removed the indentation but didn't insert
> a blank line...

First of all: You don't want this. :)

Marking paragraphs by blank lines and without indentation is deemed
less readable (see for example section 3.10 "Marking Paragraphs" in
https://komascript.de/~mkohm/scrguien.pdf).

But if you really insist on using this style, still the variant of
setting the length parindent and parskip is considered bad practise.
These are very fundamental values for LaTeX and influence a lot more
that just the space between paragraphs. A much better solution would
be to use the package =parskip= (just add "\usepackage{parskip}" to
the preamble of the LaTeX document or add "#+LATEX_HEADER:
\usepackage{parskip}" to the preamble of the Org document).

If you want to customize the Org LaTeX export more globally, you can
put something like this in your Emacs init.el:

#+begin_src elisp
(add-to-list 'org-latex-classes
   '("koma-article"
 "\\documentclass[a4paper, pagesize, headings=normal, 
version=last]{scrartcl}"
 ("\\section{%s}" . "\\section*{%s}")
 ("\\subsection{%s}" . "\\subsection*{%s}")
 ("\\subsubsection{%s}" . "\\subsubsection*{%s}")
 ("\\paragraph{%s}" . "\\paragraph*{%s}")
 ("\\subparagraph{%s}" . "\\subparagraph*{%s}")))

(setq org-latex-default-class "koma-article")

(setq org-latex-packages-alist
'(("" "unicode-math" t ("lualatex" "xelatex"))
  ("" "caption" nil)
  ("" "booktabs" t)))
#+end_src

In the case of the document classes of the Koma world, you have quite
some options for paragraph formatting. If you still insist on your
style of paragraph markings, you may add "parskip=full" to the
global options of the documentclass.

With the above settings, you globally define your preferred LaTeX
documentclass and some global settings as well as add some additionals
packages that are used on every LaTeX export done via Org. So you do
not have to put anything special in the individual Org documents but
the pure content (at the cost that the same Org document may produce a
different output on other Emacs installations with different global
settings).

For more details on what can be configured see
https://orgmode.org/manual/Exporting.html#Exporting. The options there
are mostly presented as in-document settings but most if not all of
them may also be set in some way globally via Emacs init.

-- 
Until the next mail...,
Stefan.



Re: basic org questions

2020-09-16 Thread Stefan Nobis
Hi.

Details about Org tables are to be found in the manual at different
places (maybe not optimal, but that's the current structure). First of
all, aspects of tables inside Emacs and Org are discussed here:

   https://orgmode.org/manual/Tables.html#Tables

But everything about exporting (generating PDF via LaTeX, HTML, etc.)
is discussed in the export sections. So details about exporting Org
tables to LaTeX can be found here:

   https://orgmode.org/manual/Tables-in-LaTeX-export.html#Tables-in-LaTeX-export

Here you can find the relevant option ":center". For example the
following Org table will be exported to LaTeX without centering and
using the booktabs package to nicely format the table:

--8<---cut here---start->8---

#+attr_latex: :center nil :booktabs t
| My | Columns |
|+-|
|  1 |   2 |
|  3 |   4 |

--8<---cut here---end--->8---


Generally, you have the option to just let Org handle all of the LaTeX
details. In this case, in most cases you do not even need to know
anything about LaTeX - that's what some people are excited about. On
the other hand, in this case you get what Org thinks is good enough
for you. If you want to fine-tune every detail about the resulting
PDF, you have no choice but to know LaTeX and use the options and
hooks to sprinkle your fine-tuning in the document.

BTW: I'm a long-time LaTeX user and a big fan of LaTeX. If I want to
typeset a document and tune any detail of it, in most cases I use
LaTeX and not try to modify Org to generate my hand-optimized LaTeX
code. On the other hand nowadays in many cases I just do not need to
control every little aspect of my final documents or the LaTeX code.
In these cases Org helps a lot to speed up creating simple, small
documents. I customized some aspects once globally and have to type
less (but still know LaTeX and sprinkle a few fine-tunings here and
there). So sometimes I view Org as a kind of very flexible LaTeX
template engine. :)

-- 
Until the next mail...,
Stefan.



Re: "text mode" org mode

2020-09-15 Thread Stefan Nobis
Emanuel Berg via "General discussions about Org-mode."
 writes:

> Stefan Nobis wrote:

>> (setq org-link-descriptive nil)

> I don't have org-link-descriptive, it seems...

No problem, the old name is =org-descriptive-links= (this name has
been deprecated in Org 9.3, but it is still working in 9.4).

-- 
Until the next mail...,
Stefan.



Re: "text mode" org mode

2020-09-15 Thread Stefan Nobis
Emanuel Berg via "General discussions about Org-mode."
 writes:

> Can I tell Org mode to don't change editing back and
> forth, also don't collapse items in and out, i.e.
> virtually text mode

I did not test it to every detail, but the following two settings may
be a good starting point:

#+begin_src elisp
(setq org-startup-folded 'showeverything)
(setq org-link-descriptive nil)
#+end_src

Also have a look at all the ~org-toggle-*~ commands like
~org-toggle-link-display~ and ~org-toggle-pretty-entities~ (the source
of these commands should reveal the associated variable that can be
set globally to the desired start value).

--
Until the next mail...,
Stefan.



Re: org-time-stamp in German or Spanish or....

2020-09-06 Thread Stefan Nobis
Uwe Brauer  writes:

> But it still inserts <2020-09-06 Sun>

What's the value of `system-time-locale'?

In a shell (like Bash), is there a difference between the following
two commands:

#+begin_src bash
LC_TIME=C date
#+end_src

#+begin_src bash
LC_TIME=de_DE date
#+end_src

-- 
Until the next mail...,
Stefan.



Re: org-time-stamp in German or Spanish or....

2020-09-06 Thread Stefan Nobis
Uwe Brauer  writes:

> But is inserts the name of the days in English

The format and language of the time-stamps is controlled by the
function format-time-string (the docstring of this function shows all
the available placeholders, including "%a" for the locale's
abbreviated name of the day of week).

So the name of the days should be controlled by the locale Emacs is
running in (or the relevant language settings inside Emacs).

For example I want to enforce English names, so I have in my init.el:

#+begin_src elisp
(set-language-environment "English")
(set-locale-environment "en_US.UTF-8")
#+end_src

You can check what locale Emacs is using by inspecting the variables
`current-language-environment', and especially `system-time-locale'
(for the case that LC_TIME is set differently than other locale
settings).

-- 
Until the next mail...,
Stefan.



Re: issue tracker?

2020-05-20 Thread Stefan Nobis
Detlef Steuer  writes:

> I would go as far as saying *this list* is one of the fastest
> reacting amd friendliest communities I have been part of. The job
> Nicolas does is just awesome.

+1!

-- 
Until the next mail...,
Stefan.



Re: wip-cite status question and feedback

2020-04-13 Thread Stefan Nobis
Joost Kremers  writes:

> I don't think it's necessary to use a dash (or any other character)
> in longer cite commands, though. =citeintext= isn't that much more
> difficult to read than =cite-intext=. (Biblatex does just fine
> without dashes, and there's always camelCase if you're so inclined.)

It is not necessary, but it may be an opportunity to introduce
namespaces. For example cite and citeX (with a single letter) is
strictly reserved for Org core. Package may introduce new commands
like "cite-subcommand" with a single dash and something like
"cite--subcommand" or "cite/subcommand" is reserved for local use by
users and should not be used by packages.

I think citation needs are quite manifold and thus there might be many
upcoming packages each supporting some special needs. Therefore it
would be nice to a some simple kind of namespaces for commands to
avoid name clashes when using multiple specialised support packages at
the same time.

-- 
Until the next mail...,
Stefan.



Re: wip-cite status question and feedback

2020-04-13 Thread Stefan Nobis
Nicolas Goaziou  writes:

> Alphanumeric suffix provides 62 combinations, which should hopefully
> be enough for any citation back-end out there (I'm looking at you
> biblatex). It's not terribly readable, tho, as you point out.

I second that. Some of the many BibLaTeX commands are due to
compatibility with other (older) packages and to ease transitions.

Another aspect: Maybe it would be a good idea to reserve some chars
(e.g. the numeric ones) for user defined citation commands (a
minimalistic reserved namespace).


[Placing bibliography with "#+bibliography: here"]
> It is smart, but I'm not sure I like using the same keyword for two
> different things. OTOH, I don't have a better idea.

I personally also dislike one keyword for completely different
purposes. Therefore I suggest to take the idea from BibLaTeX and use a
keyword like "printbibliography" the mark the place where the
bibliography should be output.

This command may also have parameters like filtering options (maybe
depending on the backend processor; I only know BibLaTeX so I can't
say if it would be easy to abstract away differences between different
engines). In the case of BiBLaTeX the printbibliography command
optionally accepts multiple key-value parameters. Some examples for
the keys are "heading" for the chapter/section heading, "type" to
output/print only entries of a certain type (like "book"; or type
"online" and with the additional key "nottype" separate non-online and
online sources), "keyword" to filter entries with the associated
keyword etc.

Another nice feature of BibLaTeX is the possibility to generate
bibliography per chapter/section (e.g. setting conference
proceedings). In the simplest case each chapter/section is marked, in
the case of LaTeX/BibLaTeX it is wrapped with "\begin{refsection}" and
"\end{refsection}" and the printbibliography command occurs inside
this refsection block. In this case BibLaTeX defaults to output only
references used inside the marked block.

[Style selection]
> I think this part is out of Org's scope. Since values between
> various citation back-ends are probably not compatible, e.g., some
> may require a file, others a style name, normalization is not useful
> here. They can use whatever keyword they fancy.

Yes, I second that. But it may be worth thinking a second about using
one Org document to generate output with different backends (e.g. PDF
via LaTeX and BibLaTeX, HTML, and ASCII). It would be nice, to have
some way to configure each citation engine form the same document.
Either use different keywords like "#+CSL_STYLE" and
"#+BIBLATEX_STYLE" or we use your original suggestion of a ":style"
parameter to the "#+BIBLIOGRAPHY" keyword and provide some means to
translate its value individually for each engine - e.g. an alist or
some function provided by the user. And if no translation is provided,
just give the value verbatim to the engine, thus if a user only
targets a single backend, he does not need to provide any
extra configuration.

Just my 2¢.

-- 
Until the next mail...,
Stefan.



Re: Bug or not a bug? dot expansion in ob-shell

2020-02-23 Thread Stefan Nobis
Bastien  writes:

> I agree we should have a discussion on whether :results value is a
> good default.

What about a third collection option 'none' and make this the default?

This would emphasize that there is no sensible default for all babel
languages, users and use cases. Users would be forced to explicitly
select either the 'value' or 'output' option, which also helps
reproducibility a little bit (explicit is better than implicit).

The downside would be that many existing Org documents needs to be
fixed (but maybe it would be not too hard to automate the adjustments)
and some source blocks may become a little more verbose.

Just my 2¢.

-- 
Until the next mail...,
Stefan.



Re: emacs build command for org-files

2020-01-27 Thread Stefan Nobis
John Kitchin  writes:

> Hi everyone,

> This is only semi-on-topic. I am looking for something like M-x compile for
> my org-files, but I don't want it to necessarily use Makefiles. I am
> looking for suggestions of existing solutions to this, or thoughts on how
> to implement this.

This may not be the solution you are looking for, but maybe a good
source of ideas:

   https://github.com/doublep/eldev

Another idea: Just use a (configurable) function name or source block
name to look for in a document. Then some magic function (say
org-compile-document) can look for a custom function/block inside the
document (e.g. look for a marked source block) and execute it, if
found. If no custom function/block is found, some default action will
be executed (e.g. ask user what to do, run pre-configured default
export action etc.).

-- 
Until the next mail...,
Stefan.



Re: very strange LaTeX error

2019-12-20 Thread Stefan Nobis
"Fraga, Eric"  writes:

> However, it seems that simply adding \relax does not work if there
> is an \hline immediately following so the solution is not that
> straightforward.

Hmmm... but it should be solvable. Maybe something along the lines of
this (rough sketch, I have next to no experience with the org code
base):

#+begin_src emacs-lisp
(defun org-latex--table-newline (table-row info)
  (let ((next-el (org-export-get-next-element table-row info)))
(concat ""
(when (and next-el
   (not (eq (org-element-property :type next-el) 'rule)))
  "\\relax")
"\n")))
#+end_src

-- 
Until the next mail...,
Stefan.



Re: very strange LaTeX error

2019-12-20 Thread Stefan Nobis
"Joost Kremers"  writes:

> The solution I usually opt for is to enclose the brackets in an
> additional set of braces: `{[...]}`. Whether Org export can and
> should automate that, I can't say.

In the generated LaTeX adding a '\relax' (so each line ends with
'\\\relax') would be a another solution. The \relax ends the
macro-expansion and thus '\\' does not look further for optional
arguments.

As the org-table does not support all the fancy features of LaTeX
tables and the LaTeX row/line break is generated implicitly, I would
say the LaTeX export should always emit the additional \relax.

-- 
Until the next mail...,
Stefan.



Re: Finally figuring out some ob-sqlite stuff -- for worg?

2019-11-10 Thread Stefan Nobis
Eric Abrahamsen  writes:

> I was confused in part because the "where exists (select *..." looks
> like its main purpose is to return rows.

Indeed that's the purpose: Restrict the set of rows upon which update
acts on. Here I tried to reformat the statement a bit in order to
emphasize its structure:

#+begin_src sql
  UPDATE bookreview
  SET rating = (select rating from updates
where bookreview.id = updates.id)
  WHERE EXISTS (select * from updates
where updates.id = bookreview.id);
#+end_src

The subselect of the "SET rating" part is a correlated subquery. So if
you imagine UPDATE as a kind of loop over the table, the subquery of
the SET part is executed once for every row UPDATE acts on (maybe the
SQL execution engine optimizes this in some kind, but the mental model
here is: run the subquery for every row we visit on our journey
throught the table).

Only the WHERE EXISTS clause belonging directly to the UPDATE
statement will reduce the set of rows to act on.

> Will the select subquery actually restrict the values that are
> available for updating/comparison in the update statement?

No.

> Or does the "exists" mean the subquery is treated as a plain yes/no
> boolean, and the update still has access to anything it likes? We
> could write "where exists (select " to the same effect?

Yes. The SELECT clause of an EXISTS subquery (as in the above example)
is rather meaningless. So somethimes you see constructs like "where
exists (select 1 from ...)". Some SQL engines are not very clever and
execute the subquery of such an EXISTS clause unchanged - meaning that
way too much data is fetched for the intermediate result (unnecessary
IO and maybe polluting caches). Thus the "select 1" as a workaround
for those unclever engines. But current engines should have no
problems with optimizing these EXISTS subqueries and in that case it
does not matter how the select clause looks like - it will be ignored.

> In essence, the "where exists" is acting as an "inner join"...

Yes, effectively we are simulating an inner join at this point. Sadly,
many SQL engines are not able to update rows of join constructs (or at
least have quite severe constraints in these cases). Thus we need to
build these kinds of workarounds to change data in more complex cases.

SQL is quite a capable language, but it has also has some rough edges.
:)

-- 
Until the next mail...,
Stefan.



Re: Finally figuring out some ob-sqlite stuff -- for worg?

2019-11-09 Thread Stefan Nobis
Eric Abrahamsen  writes:

> Okay, it's up. If anyone wants to explain to me the point of the
> "where exists" clause in the SQL, I would be interested to hear. It
> works as expected this way, but is that clause necessary?

Yes, very necessary. Without it, all ratings would be changed - the
two example rows without ratings (ids 5 and 12) would get the values
from the intermediary org table, every other row in table bookreview
would get its rating attribute set to null (because there is no
matching entry in the temporary updates table).

Remember: update without a where clause always touches every single
row of the complete table.

The "where exists" clause ensures that only those rows of bookreviews
are touched that are present in the intermediary org table. If you do
not like "where exists" you could say "where bookreview.id in (select
id from udpates)".

-- 
Until the next mail...,
Stefan.



[O] Clocktable creates superfluous columns

2017-02-18 Thread Stefan Nobis
Hi.

In version 9.0.5 Org (Emacs 25.1) seems to generate too many columns
in some situations. I'm not quite sure since which version this
happens, in Org 8.x I have not seen this behaviour.

Here is a small example:

--8<---cut here---start->8---
#+BEGIN: clocktable :maxlevel 3 :scope file :narrow 80! :compact
#+CAPTION: Clock summary at [2017-02-18 Sat 12:37], for February 2017.
| Headline  |   Time |   |   |
|---++---+---|
| *Total time*  | *0:15* |   |   |
|---++---+---|
| Some Tasks|   0:15 |   |   |
| \_  STARTED Task1 |   0:15 |   |   |
#+END:

* Some Tasks
** STARTED Task1
   :CLOCK:
   CLOCK: [2017-02-18 Sat 12:00]--[2017-02-18 Sat 12:15] =>  0:15
   :END:
--8<---cut here---end--->8---

It seems that the iteration over the items generates to many "|". And
top level headlines (e.g. "Some Tasks") each generate one more "|"
than their children (but even those seem to generate to many "|").

I did not fully understand the function org-clocktable-write-default,
so I'm not quite sure how to best fix this.

-- 
Until the next mail...,
Stefan.



Re: [O] Clocking work time vs. office time

2016-04-29 Thread Stefan Nobis
Marcin Borkowski  writes:

> No, you're not - this is one possible solution.  I'm curious about other
> ones.

If tracking the time you're at a specific location is your main
objective (and if you own a Smartphone), I would say: Geofencing. Let
your Smartphone track when you enter/leave the specific location. With
todays tools and apps it should be (easily?) possible to capture the
events/times and for example automatically send an E-Mail. This mail
may go to a special accounting address and maybe even automatically
processed - from this information you may create Org entries to be
appended to a special Org file.

-- 
Until the next mail...,
Stefan.



Re: [O] using vref in latex export, and normal links in html export

2016-03-12 Thread Stefan Nobis
Alan Schmitt  writes:

> I'm converting a latex document into org-mode to easily export it both
> to latex and html. I've just encountered something that I don't know how
> to do: export a \vref reference. I would like to have something that
> exports to \vref in latex, and to a normal link in html.

I solve this with the help of an export filter:

--8<---cut here---start->8---
(defun sn/ox-latex-filter-varioref (text backend info)
  (when (org-export-derived-backend-p backend 'latex)
(replace-regexp-in-string "ref{" "vref{" text)))

(eval-after-load "ox-latex"
  '(progn
 (add-to-list 'org-export-filter-link-functions 
'sn/ox-latex-filter-varioref)))
--8<---cut here---end--->8---

-- 
Until the next mail...,
Stefan.



[O] Bug in table formular - last column specifier broken

2015-12-17 Thread Stefan Nobis
Hi.

With the last update to Org-mode version 8.3.2
(8.3.2-48-g700b8e-elpaplus) the following table formular breaks:

--8<---cut here---start->8---

  | |  Mon |  Tue |  Wed | Thu | Fri | Sat | Sun |  Sum |
  |-+--+--+--+-+-+-+-+--|
  | |  | 1:30 | 2:00 | | | | | 03:30:00 |
  |-+--+--+--+-+-+-+-+--|
  | Sum |  |  |  | | | | | 00:00:00 |
  #+TBLFM: $>=vsum($<<..$>>);T

--8<---cut here---end--->8---

The error message is: Invalid table range specifier `9'.

When I change the "$>" to "$9" the formula works as expected.

-- 
Until the next mail...,
Stefan.



Re: [O] Merge branch 'maint'

2015-09-11 Thread Stefan Nobis
Oleh Krehel  writes:

> Would it be so hard for Git to perform a single merge of master into
> maint on release, while keeping them separate and cherry-picking
> in-between for the sake of a clean linear history?

The question is not whether git is capable of doing this (there are
ways to accomplish this goal). The true question is: Do you really
want a linear history?

A linear history may look pretty, but at the same time you loose
information. In a big complex project that is also a dependency to
another complex project, a bit more ugly bookeeping may make
maintenance easier.

-- 
Until the next mail...,
Stefan.



Re: [O] Babel and R: Call code block and output plot

2015-07-28 Thread Stefan Nobis
Andreas Leha andreas.l...@med.uni-goettingen.de writes:

 You still have to specify the format of the results of the #+CALL
 line, as in #+CALL: myplot[:exports results]() :results file

Works like a charm, thank you very much.

-- 
Until the next mail...,
Stefan.



[O] Babel and R: Call code block and output plot

2015-07-27 Thread Stefan Nobis
Hi.

I'm playing a little bit with R code blocks in babel and calling them
in different parts of my document (e.g. showing output in the main
part and the code in the appendix).

With most code blocks (e.g. setting some variables or outputting a
LaTeX table with xtable) this works as expected (thanks to all working
on this; its really great).

Now I wanted to show a plot, but the associated code should also be
shown in the appendix. In this case CALL seems not to work (not plot
file is created or its empty).

Here is a small example of what I'm trying to achieve:

--8---cut here---start-8---
#+TITLE: Plotting Test
#+OPTIONS: author:nil date:nil email:nil toc:nil
#+CREATOR: Emacs 24.5.1 (Org mode 8.2.10)
#+STARTUP: showall
#+PROPERTY: session *R*
#+PROPERTY: exports results

* Main Part

Here I want to show some plot:

#+CALL: myplot[:exports results]()

* Appendix

Here the code of the plot should be shown:

#+NAME: myplot
#+BEGIN_SRC R :results output graphics :exports code :file my-plot.pdf
hist(rnorm(50))
#+END_SRC
--8---cut here---end---8---

Any ideas what I'm doing wrong or how to better achieve my goal?

-- 
Until the next mail...,
Stefan.



Re: [O] org-mode to latex, again!

2015-04-02 Thread Stefan Nobis
Marcin Borkowski mb...@wmi.amu.edu.pl writes:

 As I wrote - yes, provided you update the filename database
 (e.g. launching mktexlsr from the command line). (Because of speed, TeX
 does not search the directory tree each time it looks for a package or
 something, but uses a database in a familiar, ls -R format.)

This is true, but with one exception: the user texmf tree. So
everything below ~/texmf (or ~/Library/texmf on Mac OS X) should work
without running mktexlsr (on a default TeXLive installation).

-- 
Until the next mail...,
Stefan.



Re: [O] [OT] A short (less than a minute), informal survey about LaTeX

2015-03-23 Thread Stefan Nobis
Marcin Borkowski mb...@wmi.amu.edu.pl writes:

 1. Did you know about the savetrees package by Scott Pakin

Yes.

 2. Would you find it useful when producing PDF files other that
 scientific articles (using Org-mode or not)?

No. I use org-mode mostly for documentation and even documentation
should look nice (the whitespace in a document is there for a reason;
IIRC in the documentation of koma-script there is some rationale for
the layout).

There are many other ways to influence the layout and save
whitespace on paper. Personally, I use the koma-script classes and
playing with parameters like DIV IMHO give more appealing results. For
controlling the body there are also quite some good packages (like
enumitem), that allow more fine grained control.

With a simple #+LATEX_HEADER_EXTRA: \usepackage[extreme]{savetrees}
it's very easy to get this special effect. But maybe we should make
this easier with a special option like uglyandcompressed:t (pun
intended)?

I'm not against a more compact and cleaned up preamble and maybe a
special orgmode package for LaTeX may be a good idea. But fiddling
with the layout of a document should never be the default and only be
enabled via explicit options, as quite some classes out there do a
really good job.

BTW: If producing PDF for screenreading is important, we should think
about an easy option to switch to A5 with a sane layout. A5 is much
better for screenreading than A4 and even 2 pages A5 printed on a
single A4 looks quite good and readable. The main benefit: With A5
there is much less whitespace (see documentation of koma-script for an
example). Maybe A5 output should be the default setting?

-- 
Until the next mail...,
Stefan.



Re: [O] fontenc makes pdf non-searchable

2015-03-23 Thread Stefan Nobis
Martin Leduc mart...@hotmail.com writes:

 You can find a minimal example here[1], with the org file, and the
 tex and pdf files generated from it. Firts try to search within the
 pdf. It does not work (at least on my side) To solve the problem,
 remove the line with \usepackage[T1]{fontenc}

Your PDF is not generated with pdflatex (or a newer engine like
lualatex), but with dvips and Ghostscript. Thus the fonts are not PS
Type 1 fonts, but Type 3 fonts (bitmap instead of vector; therefore
scaling/zooming will result in bad quality).

I'm not quite sure if this is also the root cause of the inability to
search. But if i recompile your tex-file (from [1]) with pdflatex, I
get Type 1 fonts and have no problems with searching.

Therefore I would suggest to switch the engine to pdflatex.

Another hint: You should try the Latin Modern font (put a
\usepackage{lmodern} after loading fontenc) -- it's the
(technically) modern variant of Computer Modern (the old TeX default
font). Lati Modern is available as OpenType font and has less problems
with Unicode and special characters like german umlauts (ä, ü,...) or
other non-ASCII letters.

And maybe you should also have a look at biblatex[2] (as a much more
flexible alternative to natbib).

[1] https://www.dropbox.com/sh/7s6di4en5ljbkcq/AAAzyQeg6VkMHnC1X9dQTg6ua?dl=0
[2] http://ctan.org/pkg/biblatex
-- 
Until the next mail...,
Stefan.



Re: [O] fontenc makes pdf non-searchable

2015-03-23 Thread Stefan Nobis
dbo...@mmm.com (J. David Boyd) writes:

 And how did you determine that please?

I assume you mean how I determined that the PDF has been produced by
dvips and Ghostscript. In this case: I've just looked into the
document information of the PDF file. For example with Acrobat Reader
I just press CMD+D, with Apple Preview its CMD+I (look out in the
menus for document information or properties).

In this document information there is somewhere a line like PDF
creator. If the PDF is created with pdftex or pdflatex, this line
should read something like pdfTeX-1.40.15.

Each PDF viewer shows a different degree of details about the file.
For example with Apple Preview I do not see the used fonts, these are
only shown by Acrobat Reader (or command line tools like pdffonts from
xpdf).

 And how would it be switched?

The default settings of org-mode uses pdflatex. The compilation
process is configurable via the variable org-latex-pdf-process.

I don't know why and how Martin used dvips+gs. Maybe he just generated
the tex file with org and used another tool for generating PDF. Or
maybe he customized org-latex-pdf-process.

-- 
Until the next mail...,
Stefan.



Re: [O] Citation syntax: Underscore MUST(?) be allowed in cite keys?

2015-03-09 Thread Stefan Nobis
Vaidheeswaran C vaidheeswaran.chinnar...@gmail.com writes:

 By saying bibtex is not a requirement,

I said exporting to bibtex. You talked about Zotero but showed a
bibtex entry. Therefore exporting from Zotero to bibtex may not
be a requirement, there may be a direct interface to Zotero,
eventually.

We are at the start of the development, we are currently CUTTING EDGE!
Therefore tool support (hopefully including guides to configure
citation managers) will evolve in the future.

My main point is: You found a single example that *may* be a problem
with the current syntax. But there are multiple software packages
involved (Zotero, Zotero to bibtex exporter, org-mode, etc.). The
citation syntax will never be able to handle all of the possible
problems in a longer chain of tools. Sometimes its better to fix a
problem at the start of in the middle of this chain.

IMHO it's a good idea to constrain the syntax for keys a little bit
(no whitespace, no arbitrary unicode character, no punctuation at the
end etc.). If in some cases the default configuration of the involved
tools will create invalid keys, than the configuration should be fixed
instead of dropping constraints for the key syntax.

 I hope you don't mean to imply that bibtex users are any less
 blessed or less holy or that their needs wouldn't be readily
 catered to.

I am a bibtex user. :)

I want to say, that it is impossible to accomodate for all the
citations managers with any possible configurations of them. Sometimes
we have to state: This case is not supported, please adjust your
configuration.

-- 
Until the next mail...,
Stefan.



Re: [O] Citation syntax: Underscore MUST(?) be allowed in cite keys?

2015-03-09 Thread Stefan Nobis
t...@tsdye.com (Thomas S. Dye) writes:

 It strikes me that basing core features of the citation syntax on
 the software users happen to be using today is a bit like this--at
 some point the design of the system will prove unprepared for new
 developments.

I don't think this is a big problem. We are talking about citation
managers, that already have to interface to different word processors.
They have to be configurable. Also, I don't think it makes any sense
for developers of citation engines to generate keys with random signs.

On the other hand, if we want to be really liberal in terms of keys,
we must allow whitespace, arbitrary unicode values etc. In this case,
its a hard problem to delimit the key because any character we use as
delimiter (like , ``, , etc.) may be used inside the key.

So some constraints for the key are always necessary. I don't know
every citation manager out there but I'm quite confident that all of
them are quite configurable and that keys containing whitespace or
ending in punctuation characters are really corner cases that could
and should be handled in the citation manager.

IMHO keys with lots of ??? in them are a sign of a data problem.
Therefore the author should solve the root cause.

-- 
Until the next mail...,
Stefan.



Re: [O] Citation syntax: Underscore MUST(?) be allowed in cite keys?

2015-03-09 Thread Stefan Nobis
Vaidheeswaran C vaidheeswaran.chinnar...@gmail.com writes:

 On Monday 09 March 2015 02:27 PM, Stefan Nobis wrote:

 IMHO keys with lots of ??? in them are a sign of a data problem.
 Therefore the author should solve the root cause.

 Not in the specific case that I cited. The Bib entry is a pointer to
 a website.

I would say, even a website needs a date (in this case: date last
seen). :)

IMHO here you are mixing two different things: We already talked about
direct support for Zotero as a backend, CSL etc. Therefore exporting
to bibtex is not a requirement. If you use bibtex as the primary
source and Zotero only as a tool to fetch references from the web,
then its easy to edit the key in bibtex.

Maybe the best way is to add a new export module to Zotero for even
better org integration and handle correct keys in this module?

IMHO it's the job of the citation manager to generate sane keys, not
the job of org to accept arbitrary keys.

 If you had shared how I can configure Zotero to leave out the
 question marks that would have been the most helpful comment from
 your side.

I'm not a Zotero expert, I even don't use it. But with a quick look at
Google I found this:

  http://curiousjason.com/zoterotobibtex.html

(in the Firefox profile there is a configuration file
zotero/translators/BibTeX.js that needs to be edited; the above source
is from 2010 - maybe today there is a GUI to edit this setting).

-- 
Until the next mail...,
Stefan.



Re: [O] Citation syntax: Underscore MUST(?) be allowed in cite keys?

2015-03-08 Thread Stefan Nobis
Richard Lawrence richard.lawre...@berkeley.edu writes:

 Like I said, this seems like an edge case, and I don't see that it
 is necessarily Org's responsibility to accommodate the keys produced
 by Zotero in such edge cases. And there is a significant benefit to
 *not* accommodating such keys: namely, you can use in-text citations
 at the end of a sentence.

+1

-- 
Until the next mail...,
Stefan.



Re: [O] Citation syntax: a revised proposal

2015-02-27 Thread Stefan Nobis
Aaron Ecay aarone...@gmail.com writes:

 I count roughly 50 commands in sections 3.7.1 – 3.7.6 of the
 biblatex user’s manual (version 2.9a of 24/06/2014). Some of these
 are quite esoteric, of course, but they are all provided.

There are many commands (and even more private commands are possible)
in order to help reproducing all the various citation styles out there.

The critical question for org and org users is: How many different
citation commands are needed in a single document (or needed by a
single author within all her documents)?

If no single author ever needs more than about a dozen different
commands (including variations like the genetive versions), the
[cite:subcommand ...] syntax should suffice.

 By way of illustration, Biblatex (AFAICT) doesn’t provide a
 possessive citation command, which was mentioned by someone in this
 thread (or its predecessor) as a desideratum. I’d expect a savvy
 latex user to put in their preamble:

 \newcommand{\citeposs}[1]{\citeauthor{#1}’s (\citeyear{#1})}

This is what the subcommand is for. An author may define poss as a
subcommand and use [cite:poss ...]. Then all the nice gimmicks will
still work.

-- 
Until the next mail...,
Stefan.



Re: [O] Citation syntax: a revised proposal

2015-02-18 Thread Stefan Nobis
Richard Lawrence richard.lawre...@berkeley.edu writes:

 1) Is it worth allowing a name for a user-defined type in the [cite:
 ...] part, or is it OK to confine user-defined types to the second
 part (like: [cite: ...] %%(:type foo) or [cite: ...]{:type foo})?

IMHO it is better to have such an important part of the citation in a
prominent position, therefore I'm in favour of Nicolas suggestion of

[cite:subtype: ...]{backend options}

with the four variations for cite (i.e. [cite:...], [Cite:...],
[(cite):...], and [(Cite):...]).

The drawback is that now subtype is hard or even impossible to vary
for different backends. Therefore I would suggest that either org has
to define the allowed values of subtype or else we should define that
subtype has to be handled by the user (e.g. for use in private filter
functions) and is out of the scope of org (maybe this would be a good
place of extensions like org-ref to plug in their machinery).

 2) If a user-defined type can go in the [cite: ...] part, where should
 it go?

   [cite:subtype ...]
   [cite:subtype: ...]
   [cite/subtype: ...]
   [cite|subtype: ...]

I favor [cite:subtype: ...] a very tiny bit over the other variants.

-- 
Until the next mail...,
Stefan.



Re: [O] Citation syntax: a revised proposal

2015-02-16 Thread Stefan Nobis
jorge.alfaro-muri...@yale.edu (Jorge A. Alfaro-Murillo) writes:

 From what I read in this and the previous thread, the new proposal
 tries more or less to reimplement BibTeX in org.

No, that's wrong, not the database should be replaced. The goal is to
make citations a first class citizen in the org world (so no fallback
to LaTeX commands or links with special handlings are needed).

 The biggest advantage of having something org/elisp native as in the
 proposal would be the implementation of functions to create
 bibliographies with a specific style, what Oren Patashnik called
 Bibliography-style hacking, which is very cumbersome in BibTeX
 (maybe is just that I cannot read WEB/Pascal and have a strong
 preference for Lisp dialects).

Hmmm... nowadays one uses biblatex[fn:1] (with its companion biber)
which makes hacking bibliography styles quite easy (in LaTeX; compared
to customizing bst files). I do not think that the current discussion
will lead to writing bib-styles in Lisp instead of LaTeX (at least not
in the foreseeable future).

[fn:1] http://ctan.org/pkg/biblatex

-- 
Until the next mail...,
Stefan.



Re: [O] Citation syntax: a revised proposal

2015-02-16 Thread Stefan Nobis
jorge.alfaro-muri...@yale.edu (Jorge A. Alfaro-Murillo) writes:

 I see, so in the examples provided Doe99 is only the key, org would
 not have to know that the author name is Doe and its year is 1999,
 or any other information about the citation.

Yes and no. In the first place org should only get a special syntax
for citations. That means there will be special data structures for
citations and backends get a uniform interface for these parts of the
source text. In the simple case that's all, i.e. the backends get more
information to generate the correct commands (in the case of LaTeX) or
to call some tool that will generate the text/object to be inserted in
the resulting document.

On the other hand org should be able to show additional information
for citations, like linking to its data (in some bib file, in zotero
or wherever). But that's a second step.

 But now it is not clear to me what the actual org reference points
 to. If it is the actual reference, I mean the article's PDF or URL,
 what would you do when you need to cite a physical book?

The org element, say [cite: see @doe99], will point to some
data source, to be defined in the same org document (e.g. with
#+BIBIOGRAPHY:...). This data source for citations may be a bib
file, a zotero database, maybe even Endnote or something else.

As said above, org will not handle every aspect of citation. It should
only know a little more about these things in order to enable some
extra features (e.g. special UI for citations or exporting citations to
different backends instead of the need to fallback to LaTeX commands).

-- 
Until the next mail...,
Stefan.



Re: [O] Citation syntax: a revised proposal

2015-02-16 Thread Stefan Nobis
Richard Lawrence richard.lawre...@berkeley.edu writes:

 Rasmus ras...@gmx.us writes:

 Parts I hate:

 The flag is either `@' or `'.  `@' [...] The optional hyphen (`-') 

 Too many weird symbols that I won't be able to remember, much less explain
 to somebody else.

 I don't love these either, but I am not sure what a better
 alternative would be.

I would say, just keep @ to mark the key. The others are not really
needed. Both,  and - are better handled by a nice internal
syntax, something like

  [cite:command ...]

or

  [cite: ... @key :part year ...]

These internal extensions via keywords are IMHO much nicer that the
%%(...) variant (as a programmer I also like %%(...), but not as
an author).

I think this kind of syntax (only plain @key or maybe [@key] as
shortcut and everything else within [cite:...]) is also easier to
handle with overlays, user input helpers etc.

Some input helper can make remembering all the options and keywords
inside [cite:...] a non-issue and overlays will render it nice in the
text. Therefore the syntax should be rather simple and regular with as
few exceptions and shorthands as sensible.

-- 
Until the next mail...,
Stefan.



Re: [O] Citation syntax: a revised proposal

2015-02-16 Thread Stefan Nobis
Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 Time for another crazy idea. Last one on my side for today

   [cite ...] [(cite) ...] [Cite ...] [(Cite) ...]

 It should solve the :capitalize issue.

+1

I really like it - even when looking at the org file with something
weird like vim, it's very clear and intuitive what's meant.

-- 
Until the next mail...,
Stefan.



Re: [O] Colon in block name?

2015-02-13 Thread Stefan Nobis
Loris Bennett loris.benn...@fu-berlin.de writes:

 The above was attached with Gnus 'C-c RET f', MIME type 'text/x-org'.

But you attached it as inline, so the same problems could arise. To be
sure to transfer the file unmodified, choose attachment as
disposition.

 Reading with Gnus, I don't see any blank lines between the table
 info and the table itself.

It depends on your Gnus configuration. If you set

   (setq gnus-inhibit-mime-unbuttonizing t)

then at least my version of Gnus (v5.13) does indeed split the buffer
in multiple pieces with additional newlines.

-- 
Until the next mail...,
Stefan.



Re: [O] Citations, continued

2015-02-11 Thread Stefan Nobis
Richard Lawrence richard.lawre...@berkeley.edu writes:

 I know these commands are convenient, and that not having them would
 introduce this class of errors, but the question is whether they are
 so important that it's worth providing an equivalent for them in
 non-LaTeX backends.

Hmmm... I don't see this as a big problem. Either the exporter or some
tool has to be able to read from the bibliography database and has to
understand at least parts of the available fields (e.g. author and
year to enable author-year style citations). Based on this it should
be easy to only output some of the fields (e.g. only author).

 For my part, it seems like the convenience is not worth the effort
 that would be required to make the exporter handle these correctly
 in general. (For example, it seems the exporter would then have to
 worry about things like quoting and emphasizing document titles --
 which means worrying about context, document type, locale and
 language, quotation styles, etc.)

Does the exporter really habe to worry about these things? But anyway:
Some tool is needed to generate the bibliography with all its data -
this tool has to handle all these details and therefore it should be
not too hard to get partial data from it. BTW: I don't think any
special formatting should be required - ASCII or even HTML would never
look the same as a LaTeX generated PDF. So minor drawbacks are IMHO
not as important as to be able to express important details in the
source.

I think, the syntax should be quite flexible (at least easy to extend,
with compact, nice looking extension-syntax). If some backend lacks
support for some feature, maybe someone finds the time to fix it (and
then org-mode would rule the world :)). Otherwise a simple fallback
(default citation style, output citation string unchanged,...) will be
used.

-- 
Until the next mail...,
Stefan.



Re: [O] Citations, continued

2015-02-10 Thread Stefan Nobis
Richard Lawrence richard.lawre...@berkeley.edu writes:

 Rasmus ras...@gmx.us writes:

 Citation types for extracting parts:
  citeauthor, citetitle, citeyear, citedate, citeurl,

 As I've said in other posts, I think maybe we should not think of
 these as `citation' commands and thus don't need to represent them
 in citation syntax. Instead I suggest we give authors tools to
 insert this information into documents directly.

This would render changes quite hard. Maybe I misspelled something in
the database or I choosed the wrong reference: With above part
extractors all I have to do at most is to replace the @key. But if
data is copied verbatim, I have to search for all years, author names,
titles, urls etc. Very error prone.

I think, even citeauthor or citeurl are citations. A normal \cite
command is nothing else than a short reference to all the detail data
in the bibliography. And sometimes context allows to make these
references even shorter, by only using the author name or a year etc.
I don't really see the distinction between citation and indirection -
each citation is as much an indirection as e.g. citeyear is.

-- 
Until the next mail...,
Stefan.



Re: [O] Include another org-document without settings

2015-02-02 Thread Stefan Nobis
Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 You can skip the first lines of an INCLUDEd file with :line parameter.
 You can also only include a section.  See manual for details.

Thank you for the hint. I used something like

   #+INCLUDE a.org :lines 3-

but still got duplicate keywords (the KEYWORDS option is in line 2 of
my example).

It seems, I got the syntax wrong. The correct version is

   #+INCLUDE: a.org :lines 3-

so the quotations marks around the parameter are mandatory and not
optional. Using the correct syntax everything works as expected.

--
Until the next mail...,
Stefan.



[O] Include another org-document without settings

2015-02-01 Thread Stefan Nobis
Hi.

I try to build an org document that has two parts. One file contains
the first part of the resulting document and should be useable
stand-alone. The second file is some kind of extension to the first
file.

My idea is to simple #+INCLUDE the first file in the second one. But
then the global settings will be mixed. For example the keywords
contains all keywords of both files. Also some export options like
LATEX_EXTRA_HEADER are duplicated in some cases (I found no easy way
to reproduce this in the simple example).

Here are two example files:

--8---cut here---start-8---
#+TITLE: FILE A
#+KEYWORDS: a x

* First Section

Some text in file A.
--8---cut here---end---8---

--8---cut here---start-8---
#+TITLE: FILE B
#+KEYWORDS: b x

#+INCLUDE: a.org

* Second section

Some text in file b.
--8---cut here---end---8---

Is there a better way to handle this use-case or is it possible to
force org to ignore (global) settings on include (I tried only to
include lines after the global settings but that seems not to work).
My main target is LaTeX/PDF, but exporting to HTML shows similiar
problems.


GNU Emacs 24.4.1.
Org-mode version 8.2.10 (8.2.10-30-gca21b7-elpaplus).

--
Until the next mail...,
Stefan.



Re: [O] Include another org-document without settings

2015-02-01 Thread Stefan Nobis
Eric S Fraga e.fr...@ucl.ac.uk writes:

 When I used to do this in LaTeX, I usually had a /master/ document
 which included the others.

That's what I did with pure LaTeX, too. But then there is the nice
feature in AucTeX which allows you to compile the whole document while
you are in one of the slaves.

I'm just curious if the #+INCLUDE statement is supposed to work with
complete org documents full of global options or if it is intended to
work only with slave documents (as in the LaTeX case) without any kind
of preamble.

Maybe it would be a helful extension to give #+INCLUDE an option to
just ignore global settings?

-- 
Until the next mail...,
Stefan.



Re: [O] Build-System: Why not compile contrib

2013-05-26 Thread Stefan Nobis
Suvayu Ali fatkasuvayu+li...@gmail.com writes:

 http://orgmode.org/worg/dev/org-build-system.html#sec-4-1-2

 Hope this helps,

A little bit. I already know about ORG_ADD_CONTRIB, but I thought it
would only be used by `make install' and I do not install org-mode, I
use it directly from my local repository (running `make update' or
`make up1' from time to time; org-mode/lisp and org-mode/contrib/lisp
are both in my load-path).

I dug a bit deeper into the Makefiles and now I realized that files
defined by ORG_ADD_CONTRIB will be copied to the main lisp directory
and then everything is compiled. Just removing org-mode/contrib/lisp
from my load-path and only using org-mode/lisp is enough.

The only unaethetic thing left is that now git sees all those files
from contrib/lisp copied to lisp as new untracked files (but that does
not bother me too much).

-- 
Until the next mail...,
Stefan.



[O] Build-System: Why not compile contrib

2013-05-25 Thread Stefan Nobis
Hi.

I'm using the maint branch of org-mode and lately I discovered that
the files beneath contrib are not compiled and there seems to be no
easy way (e.g. via local.mk) to enable compilation of contrib. Is this
on purpose and if yes: why?

-- 
Stefan.



[O] Sum marked values in table

2013-03-22 Thread Stefan Nobis
Hi.

Is there any way to somehow mark cells in an org-table and then sum
over all marked cells of the whole table. For example in the following
table I marked some time values bold:

  || Col 1 | Col 2  | Col 3  | Col4 |  Sum |
  |+---+++--+--|
  | Row 1  |   | *1:00* ||  | 01:00:00 |
  | Row 2  |  8:30 | 6:30   | *7:00* |  | 22:00:00 |
  |+---+++--+--|
  | Sum|   |||  | 23:00:00 |
  | Marked |   |||  | 08:00:00 |
  #+TBLFM: @$=??::@$=vsum(@..@);T::$=vsum($..$);T

Exist some clever trick to be used as formula for @$ or is a custom
lisp function needed for this?

-- 
Until the next mail...,
Stefan.



Re: [O] Controlling pagination on headings in Latex/PDF export?

2012-02-17 Thread Stefan Nobis
Nick Dokos nicholas.do...@hp.com writes:

 \def\mykeepwithnextpar{\par\nobreak\@afterheading}

 However, I find it exceedingly difficult to manufacture an example
 that will produce the bad break that the OP reports: LaTeX seems
 very reluctant to break after the headline.

Yes. That's because the above snippet is already part of the
definition of a section (from chapter down to paragraph). IIRC it's
defined in the latex kernel. Therefore it should not make any
difference if the command is only used directly after a sectioning
command.

One way to ensure that some part of the document is always seen as a
single entity by latex is to put it in a minipage (maybe there are
better options, but that's my fallback if I need to ensure that
something is always kept together).

-- 
Until the next mail...,
Stefan.



Re: [O] Controlling pagination on headings in Latex/PDF export?

2012-02-17 Thread Stefan Nobis
Jos'h Fuller Jos'h.ful...@arcproductions.com writes:

 but it still doesn't seem to want to cooperate (heading on one page,
 table on the next).

Reading this again, another hint: If the table is exported to tabular
and wrapped in a figure environment, then that might be the
problem. I'm not familiar with org-modes latex export. But if you show
me the resulting LaTeX code, maybe I could help on the LaTeX side.

-- 
Until the next mail...,
Stefan.



Re: [O] Controlling pagination on headings in Latex/PDF export?

2012-02-17 Thread Stefan Nobis
Jos'h Fuller Jos'h.ful...@arcproductions.com writes:

 Hi!

 Thanks for your kind words! ; - )

 I did wrap the mykeepwithnextpar definition and I moved the call between 
 the heading
 and the table as suggested, but it still doesn't seem to want to cooperate 
 (heading on
 one page, table on the next).

I just tried to export the example posted by Nick. The tabluar is
wrapped in a center environment. I think this is the problem. Without
the help of something like the minipage environment I think it is
impossible to prevent page breaks before the centered object in the
general case (the problem is not the centering but the environment
center is implemented with the help of a list environment and IIRC
lists allow page breaks around them).

As I'm not a LaTeX expert it may be helpful to ask on comp.text.tex
for some tipps.

-- 
Until the next mail...,
Stefan.



Re: [O] How to debug org-clock-display: Args out of range: [48230 48230 48230 38618 38618 0 0 0 0 0 ...], 61

2012-01-15 Thread Stefan Nobis
Nick Dokos nicholas.do...@hp.com writes:

 The code that sets the level seems suspect to me:

 (let* ((headline-forced
 (get-text-property (point)
  :org-clock-force-headline-inclusion))
  (headline-included
   (or (null headline-filter)
   (save-excursion
 (save-match-data (funcall headline-filter))
   (setq level (- (match-end 1) (match-beginning 1)))

 What do match-beginning/match-end return if headline-filter is nil?
 The save-match-data is not done, so we get the results of whatever
 random search was done last before this code executed.

Hmmm... the above snippet is from org-clock-sum, right? That means it
is part of (while (re-search-backward re nil t) ...) and that's the
search match-beginning/match-end are referring to.

-- 
Until the next mail...,
Stefan.



Re: [O] Latex image placement (...again. H vs. h!)

2011-08-21 Thread Stefan Nobis
John Hendy jw.he...@gmail.com writes:

 Was just rediscovering how to properly get floats to drop in where I
 want them in LaTeX export (right where I say vs. where LaTeX thinks
 is convenient).

Another way to tackle this problem may be to just not use floats. As
the name suggests, these construct is meant to let things float. :)

If you want a figure or table to be placed at exactly the point where
you place it, why are you using a float environment? Most people
answer at this point, because they want the captions and all examples
with captions use the float environment. Thats because with captions
and in the general case it makes sense to let LaTeX find the right
place for these things.

If you want exact, controlled placements and also a caption, have a
look at the package 'caption' (version 3.1, author Axel
Sommerfeldt). Then you can get rid of floats and don't have to bother
with obscure placement rules. :)

-- 
Until the next mail...,
Stefan.


pgpbWvwGJsXom.pgp
Description: PGP signature


Re: [O] Wishlist: LaTeX export: automatically append backslash to . unless at end of sentence

2011-08-19 Thread Stefan Nobis
Andras Major andras.g.ma...@gmail.com writes:

 Hi,

 in TeX and LaTeX, the width of the glue (blank space) after a . can
 be one of two different values, depending on the context.

And depending on the use of \nonfrenchspacing and \frenchspacing.

 There is always a longer space between sentences than after a .
 that doesn't mark the end of a sentence

This could easily be turned off with the use of a single \frenchspacing
in the preamble (or in the document; you may switch between the two in
the document as often as you like; e.g. \frenchspacing is active
starting from the point TeX reads the macro until it is set back to
\nonfrenchspacing).

-- 
Until the next mail...,
Stefan.


pgpk9oKN0N7KA.pgp
Description: PGP signature


Re: [O] Unicode and Latex export

2011-08-08 Thread Stefan Nobis
Sebastien Vauban wxhgmqzgw...@spammotel.com writes:

 having \usepackage[utf8x]{inputenc} inserted

Please beware that utf8x is part of the obsolete and unsupported ucs
package. As ucs deeply affects the LaTeX kernel, more and more modern
packages are incompatible with utf8x and ucs (csquotes,
hyperref,...). For proper Unicode support its preferable to use LuaTeX
or XeTeX rather than using ucs (which is one of the first attemtps at
better Unicode support for TeX).

-- 
Until the next mail...,
Stefan.


pgpFLgv2hD8Ll.pgp
Description: PGP signature


Re: [O] [PATCH] org-latex.el: New defcustom `org-export-latex-quotes' to control quotes.

2011-07-11 Thread Stefan Nobis
Bastien b...@altern.org writes:

 Org to output something like \endquote{some quoted text} instead

s/endquote/enquote/

-- 
Until the next mail...,
Stefan.


pgpzl49iatYmp.pgp
Description: PGP signature


Re: [O] LaTex export: How to use `csquotes' and `\enquote{}'

2011-07-07 Thread Stefan Nobis
Nick Dokos nicholas.do...@hp.com writes:

 Here are some points to keep in mind while working on a patch:

 o csquotes.sty is part of the texlive-latex-extra package on Ubuntu
   (and probably something similar on other Linux distros and
   possibly MacOS X - hunoz about Windoz?)

On MacOS the MacTeX distribution is quite common and in this case a
complete TeXLive (including csquotes) is installed.

On Windows MikTeX is probably the defacto standard and IIRC it
supports installing packages on demand (I'm not sure wether csquotes
is included in the basic installation, but on the other hand I would
assume that a complete installation is not uncommen).

But another suggestion:

Always use \enquote for quotations in the exported text. In the
preambel of the document either include csquotes or provide a simple
macro enquote like the very simple

  \newcommand{\enquote}[1]{``#1''}

Maybe a bit more hackery might be needed for some special cases, but
with this approach it would be quite easy to change quotations styles
later on.

BTW: IMHO babel and csquotes should be considered standard packages
for all non-US texts (and even for US texts they have some
advantages).

-- 
Until the next mail...,
Stefan.


pgpd6PAdYP6OT.pgp
Description: PGP signature


Re: [O] LaTex export: How to use `csquotes' and `\enquote{}'

2011-07-07 Thread Stefan Nobis
Nick Dokos nicholas.do...@hp.com writes:

 I'd worry a bit about adding the newcommand in the preamble during
 org processing: what would happen if I tried to use csquotes then?

It should be either the newcommand or else use csquotes. Mixing both
would be no good idea.

--
Until the next mail...,
Stefan.


pgpoRt8r2jkK9.pgp
Description: PGP signature