emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
Search results ordered by [date|relevance]  view[summary|nested|Atom feed]
thread overview below | download mbox.gz: |
* Re: [patch, ox] Unnumbered headlines
  @ 2014-09-21 13:12 11%         ` Nicolas Goaziou
  0 siblings, 0 replies; 5+ results
From: Nicolas Goaziou @ 2014-09-21 13:12 UTC (permalink / raw)
  To: Rasmus; +Cc: emacs-orgmode, alantyree, tsd

Hello,

Rasmus <rasmus@gmx.us> writes:

> I'm happy to finally be able to send an updated version of this patch
> that touches most backends in lisp/, but not the manual.  I have been
> moving over the summer etc.

Thanks for that work.  Some comments follow.

> You now specify unnumbered headlines with properties.  I think this is
> better since being unnumbered it's a pretty permanent state.  It's
> pretty hard to discover though, other than by looking at the output.
>
> So this works as expected:
>
> * Some headline
>   :PROPERTIES:
>   :UNNUMBERED: t
>   :END:
>
> There's no :NUMBERED property and :UNNUMBERED is hardcoded.

Sounds good.

> I introduce a new function `org-export-get-headline-id` which returns
> the first non-nil from the following list.  There's a caveat:
> CUSTOM_ID is ensured to be unique!  Did I open the famous can of worm?
>
> 1. The CUSTOM_ID property.
> 2. A relative level number if the headline is numbered.
> 3. The ID property
> 4. A new generated unique ID.

I think we should keep separated CUSTOM_ID and ID on the one hand, and
internal reference on the other hand.

There's no guarantee that CUSTOM_ID will be unique, and, even if you
check it out, there's no guarantee either that its value can be used
as-is in the generated docstring (think about ":CUSTOM_ID: 100%" in
LaTeX export).

CUSTOM_ID is a human readable reference to an Org headline. This
headline should be referred to internally with a more specific id. To
a lesser extent, I think this also applied to org-id.

Also `org-export-headline-internal-id' (or some such, to avoid confusion
with other IDs) may return a value simpler than what `org-id-new'
returns (e.g. a dumb counter). If it is possible, the output will be
easier to read.

> Anyhow, `org-export-get-headline-id' ensures that we can refer to
> unnumbered headlines, which was not possible before.

This is untrue.

> Of course, in LaTeX such ref to a \section* will be nonsense, so we
> could introduce a \pageref here.

At the moment, referring to an unnumbered section displays its name.

> I'm unsure about whether this conflicts `org-latex-custom-id-as-label'
> which I had never seen until today (also notes on this in patch).

This variable has its use if custom-id and internal representation are
separated.

> PS: Not knowing or caring much about md, the links generated by it to
> headlines seem wrong.  Referring to headline 1 it only prints "1".
> Should it be something like "[LABEL](1)"?

There is probably something to do here, but that would be in another
patch.

> * ox-odt.el (org-odt-headline, org-odt-link,
> org-odt-link--infer-description): Support unnumbered
> headline.
> * ox-md.el (org-md-headline, org-md-link): Support
> unnumbered headlines.
> * ox-latex.el (org-latex-headline, org.latex-link): Support
> unnumbered headlines.
> * ox-html.el (org-html-headline, org-html-link): Support
> unnumbered headlines.
> * ox-ascii.el (org-ascii-link): Support ununbered headlines.

You can also write "Support unnumbered headlines" just once.

> +		(when (equal 'headline (org-element-type destination))

Comparing symbols with `equal' is a sin beyond redemption. Use `eq'.

> +		  (format "[%s]" (org-export-data (org-export-get-alt-title destination info) info)))))))))

alt title is for table of contents only.

>       (t
>        (if (not (org-string-nw-p desc)) (format "[%s]" raw-link)
>  	(concat (format "[%s]" desc)
> diff --git a/lisp/ox-html.el b/lisp/ox-html.el
> index 1d424cc..94cee20 100644
> --- a/lisp/ox-html.el
> +++ b/lisp/ox-html.el
> @@ -2321,7 +2321,7 @@ holding contextual information."
>    (unless (org-element-property :footnote-section-p headline)
>      (let* ((numberedp (org-export-numbered-headline-p headline info))
>             (numbers (org-export-get-headline-number headline info))
> -           (section-number (mapconcat #'number-to-string numbers "-"))
> +           (section-number (when numbers (mapconcat #'number-to-string numbers "-")))

Nitpick: I suggest `and' instead of `when' since there's no side-effect.

> +                            (when section-number (concat "sec-" section-number))

Ditto.

> +  (unless (org-export-get-node-property :UNNUMBERED headline t)

Actually, this test is fragile. In the following example

  * H1
    :PROPERTIES:
    :UNNUMBERED: t
    :END:
  ** H2
     :PROPERTIES:
     :UNNUMBERED: nil
     :END:
  *** H3

H3 should clearly be unnumbered even though inheritance disagrees. This
is a bit stronger than inheritance: if there is a single non-nil
UNNUMBERED property among ancestors (or the headline itself), it cannot
be numbered.


Regards,

-- 
Nicolas Goaziou

^ permalink raw reply	[relevance 11%]

* Re: [PATCH] Fix moving cursor in org-set-tags-command
  @ 2020-05-08  7:53 14% ` Nicolas Goaziou
  0 siblings, 0 replies; 5+ results
From: Nicolas Goaziou @ 2020-05-08  7:53 UTC (permalink / raw)
  To: Matt Lundin; +Cc: Org Mode List

Hello,

Matt Lundin <mdl@imapmail.org> writes:

> -    (when (save-excursion (skip-chars-backward "*") (bolp))
> -      (forward-char))))
> +    (and (looking-at " ")
> +	 (string-match "\\*+" (buffer-substring (point-at-bol) (point)))
> +	 (forward-char))))

Please replace `and' with `when' if side-effects are involved.

Also, note that

  (save-excursion (skip-chars-backward "*") (bolp))

is faster and more accurate than

  (string-match "\\*+" (buffer-substring (point-at-bol) (point)))

because the latter matches, e.g.,

  ab*|c

where "|" is point.

Besides, I don't understand how this is related to empty headlines
since, AFAICT, this part of code is supposed to fix the issue on empty
headlines.

Regards,

-- 
Nicolas Goaziou


^ permalink raw reply	[relevance 14%]

* Re: [ox, patch] #+SUBTITLE
  @ 2015-03-29  9:44 14%     ` Nicolas Goaziou
  0 siblings, 0 replies; 5+ results
From: Nicolas Goaziou @ 2015-03-29  9:44 UTC (permalink / raw)
  To: Rasmus; +Cc: emacs-orgmode

Rasmus <rasmus@gmx.us> writes:

>> Could you elaborate a bit in the comment?
>
> Consider if title is nil.  With format-spec I'll get an empty <h1></h1>.
> As I remember, the W3 checker dislike these.  I have never used these
> html5 slides, so I don't really know how to fix it.

You probably should add this to the comments in the file.

> But de facto KEYWORDS and DESCRIPTION were also only supported in some
> backends.  I think it's more convenient to have these type of keywords in
> one place.  But I don't feel strongly about this.

I would like to keep a clear and somewhat future-proof rule about this:

 1. A keyword a user can expect to find in all back-ends where it makes
    sense should be defined in "ox.el". To put it differently, it can be
    considered as a bug if a back-end could /simply/ support a keyword
    in this category but doesn't. Keywords in this category are to be
    documented in (info "(org)Export settings").

 2. Other keywords are defined in their respective back-end, and
    documented in their respective chapter in the manual.

As a non-trivial example, consider :email. You can expect it to produce
something sensible in any back-end. Yet, "ox-icalendar" doesn't use it.
It still belongs to first category.

If we support SUBTITLE everywhere it makes sense, it might be worth
adding it to the first category. Actually, considering the rule above,
I even lean towards adding it to that category. WDYT?

Also, I'm going to implement the `parse-object' and `parse-element'
behaviour we discussed in another thread, and remove
`org-element-document-properties' (and the relative
`org-export-document-properties') altogether. This will remove a useless
distinction among keywords: two categories are enough.

As a side-effect, however, `org-element-context' will not show objects
when called on TITLE and al, but that might be a good thing actually
(there are objects in there only during export and only if considered
export back-end makes use of them).

>> Nitpick:
>>
>>   (and formatted-subtitle ...)
>
> Can you explain why (and ⋯) should be used here?

It makes more obvious you are expecting a return value. `when' is
preferred for side effects. However, this is not a hard rule, since

  (and test
       ... some very long computation)

is less clear than

  (when test
    ... some very long computation)

However, it doesn't apply in this case.

As I warned, this is all about nitpicking anyway.


Regards,

^ permalink raw reply	[relevance 14%]

* Re: API problem
  @ 2014-01-22 22:23 15%             ` Nicolas Goaziou
  0 siblings, 0 replies; 5+ results
From: Nicolas Goaziou @ 2014-01-22 22:23 UTC (permalink / raw)
  To: Cecil Westerhof; +Cc: emacs-orgmode

Hello,

Cecil Westerhof <cldwesterhof@gmail.com> writes:

> But one thing I do not understand. When you do an org-list-write-struct,
> you want to change the structure. So why is old-struct optional?

Good question.

IIRC, it's just syntactic sugar since `org-list-write-struct' will do
the `copy-tree' for you in most situations (i.e., when you don't use
a function that modifies structure by side-effect).


Regards,

-- 
Nicolas Goaziou

^ permalink raw reply	[relevance 15%]

* Re: org-review-schedule
  @ 2014-04-26 12:25 15%           ` Nicolas Goaziou
  0 siblings, 0 replies; 5+ results
From: Nicolas Goaziou @ 2014-04-26 12:25 UTC (permalink / raw)
  To: Thorsten Jolitz; +Cc: emacs-orgmode

Thorsten Jolitz <tjolitz@gmail.com> writes:

> the answer is in the quote already:
>
> ,---------------------------------------------
> | Since return value matters, I suggest to use ...
> `---------------------------------------------

Exactly. I use `when' if side-effects are involved or if the code is too
long and doesn't fit nicely in a `and' branch.

Of course, this is nitpicking. There's nothing wrong with `when'
variant.


Regards,

-- 
Nicolas Goaziou

^ permalink raw reply	[relevance 15%]

Results 1-5 of 5 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2014-08-08 13:39     [patch, ox] Unnumbered headlines Rasmus
2014-08-11 14:18     ` Nicolas Goaziou
2014-08-11 15:37       ` Rasmus
2014-08-12  8:58         ` Nicolas Goaziou
2014-09-20 16:02           ` Rasmus
2014-09-21 13:12 11%         ` Nicolas Goaziou
2020-05-08  0:20     [PATCH] Fix moving cursor in org-set-tags-command Matt Lundin
2020-05-08  7:53 14% ` Nicolas Goaziou
2014-04-18 20:27     org-review-schedule Alan Schmitt
2014-04-19  8:14     ` org-review-schedule Bastien
2014-04-24 11:51       ` org-review-schedule Alan Schmitt
2014-04-25  6:51         ` org-review-schedule Nicolas Goaziou
2014-04-26  8:57           ` org-review-schedule Alan Schmitt
2014-04-26 10:38             ` org-review-schedule Thorsten Jolitz
2014-04-26 12:25 15%           ` org-review-schedule Nicolas Goaziou
2015-03-27 14:19     [ox, patch] #+SUBTITLE Rasmus
2015-03-28 15:40     ` Nicolas Goaziou
2015-03-28 15:55       ` Rasmus
2015-03-29  9:44 14%     ` Nicolas Goaziou
2014-01-22 16:37     API problem Cecil Westerhof
2014-01-22 17:03     ` Nicolas Goaziou
     [not found]       ` <CAG-LmmApJwvTvTYZ3cFjb_rLkiX9B_JP3FzTX-D_kW3H1=D6pA@mail.gmail.com>
2014-01-22 20:24         ` Fwd: " Cecil Westerhof
2014-01-22 20:28           ` Cecil Westerhof
2014-01-22 20:40             ` Nicolas Goaziou
2014-01-22 21:57               ` Cecil Westerhof
2014-01-22 22:23 15%             ` Nicolas Goaziou

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).