Re: [O] latex preview table environment

[Jeremie Juste]

I found the culprit. 

I have set my background color to black and forground color to white.

Yet when I adust the org-format-latex-options to see the preview white on 
black, the tabular environment displays the expected color setting but not the 
table environment.

So far I can only change the background color to preview the table environment 
but not the foreground color. I'll try to find a solution and come back if I 
do. In the meantime any idea to fix this issue is welcome :-).


Below are the settings with which I hope you could reproduce this phenomenon.

(set-background-color "black")
(set-foreground-color "white")
   
(setq org-format-latex-options '(:foreground "white" :background "black" :scale 
1.4 :html-foreground "Black" :html-background "Transparent" :html-scale 1.0 
:matchers ("begin{.*[^table]}" "end{.*[^le]}" "$1" "$" "$$" "\\(" "\\[")))

Thanks again,
Jeremie

Re: [O] Bug: Bug in Orgmode Clocktable? [9.0.5 (9.0.5-elpa @ c:/Users/sane/AppData/Roaming/.emacs.d/elpa/org-20170210/)]

[Axel Kielhorn]

> Am 17.02.2017 um 15:14 schrieb Nicolas Goaziou :
> 
> Hello,
> 
> I'm Cc'ing the mailing list for archiving purpose.
> 
> michael.zi...@xiron.de writes:
> 
> It happens because no translation is available for "de" in
> `org-clock-clocktable-language-setup’.

Maybe we should add a german translation?
Here is what I use:

 '(org-clock-clocktable-language-setup
   (quote
(("en" "File" "L" "Timestamp" "Headline" "Time" "ALL" "Total time" "File 
time" "Clock summary at")
 ("es" "Archivo" "N" "Fecha y hora" "Tarea" "Tiempo" "TODO" "Tiempo total" 
"Tiempo archivo" "Clock summary at")
 ("fr" "Fichier" "N" "Horodatage" "En-tête" "Durée" "TOUT" "Durée totale" 
"Durée fichier" "Horodatage sommaire à")
 ("nl" "Bestand" "N" "Tijdstip" "Hoofding" "Duur" "ALLES" "Totale duur" 
"Bestandstijd" "Clock summary at")
 ("de" "Datei" "L" "Timestamp" "Tätigkeit" "Dauer" "ALLES" "Gesamtzeit" 
"Datei Zeit" "Erstellt am"

Does this require a patch and a TINYCHANGE?

Axel

Re: [O] Bug: save-some-buffers saves org-edit-special buffers to separate files [9.0.4 (9.0.4-elpa @ /home/thblt/.emacs.d/elpa25/org-20170124/)]

[Nicolas Goaziou]

Hello,

Thibault Polge  writes:

> When calling (save-some-buffers t) while a code block is being edited
> with org-edit-special, the org-edit-special buffer is saved to the disk
> to a new, separate file with a name like:
>
> dotemacs.org[*Org Src dotemacs.org[ emacs-lisp ]*]
>
> I can reproduce this from emacs -Q with org 9.0.4 from org ELPA, but not
> with builtin org in Emacs 25.1.
>
> I would expect these buffers not to be saved at all, or at least to just
> be synchronized back to the .org file which in turn gets saved.

Fixed. Thank you.

Regards,

-- 
Nicolas Goaziou

Re: [O] Bug: org-insert-heading adds extra newlines [9.0.4 (release_9.0.4-222-g63aaff.dirty @ /home/kyle/.emacs.d/modules/org-mode/lisp/)]

[Nicolas Goaziou]

Hello,

Kyle Sherman  writes:

> When pressing M-return, which calls `org-insert-heading', in addition to
> adding the new heading under the current one (and splitting if not at
> the end
> of the line) it also now adds an additional newline after the new
> heading.  It
> didn't used to do this.
>
> This is the commit where this functionality changed:
>
> 68d8f860cd0b898a02f60ec3b4781f4ddf7d2627
>
> If this was intentional, I do wish you would change it back as it
> continuously
> adds more and more newlines if I keep adding headings.

Fixed. Thank you.

Regards,

-- 
Nicolas Goaziou

Re: [O] Bug: Clocking Notes [9.0.4 (9.0.4-elpaplus @ /home/giammi/.emacs.d/elpa/org-plus-contrib-20170124/)]

[Nicolas Goaziou]

Hello,

gian-maria.daf...@giammi.com (Gian-Maria Daffré) writes:

> Hello,
>
> I get a strange behaviour when cloking out and adding the notes.
>
> The expected result should be:
>
> ** Task XYZ
>:LOGBOOK:
>CLOCK: [2017-02-09 Thu 11:34]--[2017-02-09 Thu 11:57] =>  0:23
>- Worked on task A
>CLOCK: [2017-02-07 Die 10:18]--[2017-02-07 Die 11:08] =>  0:50
>- Worked on task B
>CLOCK: [2017-02-06 Mon 13:22]--[2017-02-06 Mon 13:59] =>  0:37
>- Worked on task C
>:END:
>
> The current out put is (see Task A)
>
> ** Task XYZ
>:LOGBOOK:
>- Worked on task A
>CLOCK: [2017-02-09 Thu 11:34]--[2017-02-09 Thu 11:57] =>  0:23
>CLOCK: [2017-02-07 Die 10:18]--[2017-02-07 Die 11:08] =>  0:50
>- Worked on task B
>CLOCK: [2017-02-06 Mon 13:22]--[2017-02-06 Mon 13:59] =>  0:37
>- Worked on task C
>:END:

This was fixed recently, IIRC. You need to upgrade Org.

Regards,

-- 
Nicolas Goaziou

Re: [O] Using CEDET modules from Emacs core

[Edward John Steere]

>> Which CEDET features would we want to use from core?
>
> For one, I'd like to see more major modes come with support for Semantic
> right in the major mode's own definition (rather than have it part of
> CEDET).  E.g. for Elisp mode, CC-mode, ...
>
> The idea is to get to the point where Semantic support is just another
> thing that a major mode should aim to support alongside syntax-tables,
> indentation, font-lock, outline-minor-mode, ...

This sounds like a great idea!  Semantic appears to be to be stable
enough that we might want to consider extracting it from CEDET in core
like EIEIO was.

Perhaps it's worth considering this line of thought: that are parts of
CEDET which are worthy of becoming part of Emacs proper.  As Stefan
said, semantic is a perfect example of something which built in modes
could benefit from.

There are other parts of CEDET which I don't think meet the criteria of
being stable and general enough that they should be considered for this.
Such as EDE and the external databases for semantic db.  All of which
are useful, but unstable (and sometimes very slow) and I feel like they
shouldn't be expected as part of the core editing experience --
i.e. that one should have to buy into their use.

[O] exclude_tags stoppped working at 9.0.5?

[Leslie Watter]

Hi Folks,

I've been dealing with an issue here. Does the '#+EXCLUDE_TAGS' still works
on release 9.0.5 ?

I used the following org-mode file to test the export to latex, only the
subtree.

t.org
* exclude tags test
:PROPERTIES:
:EXPORT_FILE_NAME: t.pdf
:EXPORT_OPTIONS: toc:nil tags:nil <:nil ^:nil
:EXPORT_AUTHOR:
:EXPORT_DATE:
:END:

#+TAGS: alunos professor
#+EXCLUDE_TAGS: professor

** First Section

At 1st

***
:professor:
This should not appear on t.pdf
---

And it's not working: (

I've searched logs, changelog but no mention to removal of these feature.

What I've done? Point cursor on the :PROPERTIES: line and export only the
subtree to latex and open it  =>  C-c C-e C-s lo

Any hint? Any help is welcome.

Cheers,

LEslie



-- 
Leslie H. Watter

[O] Not tables in babel scheme

[Luis Souto Graña]

Spacemacs version 0.200.7
Org mode version 9.0.3
Guile version 2.0.11

#+BEGIN_SRC emacs-lisp
(list '(1 2 3) '(4 5 6))
#+END_SRC

#+RESULTS:
| 1 | 2 | 3 |
| 4 | 5 | 6 |

#+BEGIN_SRC scheme
   (list '(1 2 3) '(4 5 6))
#+END_SRC

#+RESULTS:
:((1 2 3) (4 5 6))

Is it me  or a known bug?

[O] exclude_tags stoppped working at 9.0.5 release?

[Leslie Watter]

Hi Folks,

Sorry if it is a duplicate, I've sent this a few days ago and didn't see it
appear on the list.

I've been dealing with an issue here. Does the '#+EXCLUDE_TAGS' still works
on release 9.0.5 ?

I used the following org-mode file to test the export to latex, only the
subtree.

t.org
* exclude tags test
:PROPERTIES:
:EXPORT_FILE_NAME: t.pdf
:EXPORT_OPTIONS: toc:nil tags:nil <:nil ^:nil
:EXPORT_AUTHOR:
:EXPORT_DATE:
:END:

#+TAGS: alunos professor
#+EXCLUDE_TAGS: professor

** First Section

At 1st

***
:professor:
This should not appear on t.pdf
---

And it's not working: (

I've searched logs, changelog but no mention to removal of these feature.

What I've done? Point cursor on the :PROPERTIES: line and export only the
subtree to latex and open it  =>  C-c C-e C-s lo

Any hint? Any help is welcome.

Cheers,

LEslie


-- 
Leslie H. Watter

[O] Problem of refile in the org capture buffer

[Liu Hui]

Hello,

I find C-c C-w (refile) in the org capture buffer doesn't work correctly 
when there are empty lines (containing the point) in the end of buffer. 
Steps to reproduce:


1. echo -e "* A\n* B" > /tmp/test.org; cat /tmp/test.org
* A
* B

2. Emacs -Q, and evaluate the code:

(setq org-capture-templates
  '(("t" "Todo" entry (file+headline "/tmp/test.org" "A")
 "** test1 %?")))

3. M-x org-capture, and press t to open the org capture buffer

4. In the capture buffer, press C-j to insert a newline, then C-c C-w:

   => the subtree "B" will be refiled rather than the "test1".


The problem is caused by org-capture-finalize, which deletes the empty 
lines and, as a result, makes the point saved by org-capture-refile 
invalid. The following patch should fix the problem:


diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index 1a1a500..27cb60b 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -827,6 +827,9 @@ already gone.  Any prefix argument will be passed to 
the refile command."

(base (buffer-base-buffer (current-buffer)))
(org-capture-is-refiling t)
(kill-buffer (org-capture-get :kill-buffer 'local)))
+(and (< (skip-chars-backward " \t\n") 0)
+(not (bobp))
+(setq pos (point)))
 (org-capture-put :kill-buffer nil)
 (org-capture-finalize)
 (save-window-excursion


Emacs  : GNU Emacs 26.0.50.2 (x86_64-pc-linux-gnu, GTK+ Version 3.18.9)
 of 2016-12-17
Package: Org mode version 9.0.4 (release_9.0.4-283-g2064b0 @ 
~/org-mode/lisp/)

[O] Bug: Clocking Notes [9.0.4 (9.0.4-elpaplus @ /home/giammi/.emacs.d/elpa/org-plus-contrib-20170124/)]

[Gian-Maria Daffré]

Hello,

I get a strange behaviour when cloking out and adding the notes.

The expected result should be:

** Task XYZ
   :LOGBOOK:
   CLOCK: [2017-02-09 Thu 11:34]--[2017-02-09 Thu 11:57] =>  0:23
   - Worked on task A
   CLOCK: [2017-02-07 Die 10:18]--[2017-02-07 Die 11:08] =>  0:50
   - Worked on task B
   CLOCK: [2017-02-06 Mon 13:22]--[2017-02-06 Mon 13:59] =>  0:37
   - Worked on task C
   :END:

The current out put is (see Task A)

** Task XYZ
   :LOGBOOK:
   - Worked on task A
   CLOCK: [2017-02-09 Thu 11:34]--[2017-02-09 Thu 11:57] =>  0:23
   CLOCK: [2017-02-07 Die 10:18]--[2017-02-07 Die 11:08] =>  0:50
   - Worked on task B
   CLOCK: [2017-02-06 Mon 13:22]--[2017-02-06 Mon 13:59] =>  0:37
   - Worked on task C
   :END:


Thanks for looking into it.

Best
Giammi
.



Emacs  : GNU Emacs 24.4.1 (x86_64-pc-linux-gnu, GTK+ Version 3.14.5)
 of 2015-03-07 on trouble, modified by Debian
Package: Org mode version 9.0.4 (9.0.4-elpaplus @ 
/home/giammi/.emacs.d/elpa/org-plus-contrib-20170124/)

current state:
==
(setq
 org-src-lang-modes '(("plantuml" . plantuml) ("ocaml" . tuareg)
  ("elisp" . emacs-lisp) ("ditaa" . artist)
  ("asymptote" . asy) ("dot" . fundamental)
  ("sqlite" . sql) ("calc" . fundamental) ("C" . c)
  ("cpp" . c++) ("C++" . c++) ("screen" . shell-script)
  ("shell" . sh) ("bash" . sh))
 org-clocktable-defaults '(:maxlevel 3 :lang "en" :scope file :block nil
   :wstart 1 :mstart 1 :tstart nil :tend nil :step nil
   :stepskip0 nil :fileskip0 nil :tags nil :emphasize
   nil :link nil :narrow 40! :indent t :formula nil
   :timestamp nil :level nil :tcolumns nil :formatter
   nil)
 org-clock-persist-query-save t
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe
  org-babel-header-arg-expand)
 org-log-note-clock-out t
 org-agenda-clockreport-parameter-plist '(:link t :maxlevel 5 :fileskip0 t
  :compact t)
 org-agenda-skip-deadline-prewarning-if-scheduled t
 org-icalendar-combined-agenda-file "~/org/ical.ics"
 org-time-clocksum-use-fractional t
 org-speed-command-hook '(org-speed-command-default-hook
  org-babel-speed-command-hook)
 org-agenda-fontify-priorities t
 org-agenda-diary-file "~/org/cal.org"
 org-agenda-skip-timestamp-if-done t
 org-icalendar-combined-name "Calendar"
 org-occur-hook '(org-first-headline-recenter)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-icalendar-include-todo t
 org-html-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME CONTENTS)"]
 org-log-done 'time
 org-latex-format-inlinetask-function 
'org-latex-format-inlinetask-default-function
 org-confirm-shell-link-function 'yes-or-no-p
 org-finalize-agenda-hook '(bh/org-agenda-to-appt)
 org-columns-default-format "%38ITEM(Details) %TAGS(Context) %7TODO(To Do) 
%PRIORITY %SCHEDULED %DEADLINE %5Effort(Effort){:} %6CLOCKSUM"
 org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
 org-startup-align-all-tables t
 org-export-with-date nil
 org-icalendar-use-deadline '(event-if-not-todo event-if-todo todo-due)
 org-agenda-skip-scheduled-if-done t
 org-latex-format-headline-function 'org-latex-format-headline-default-function
 org-default-notes-file "/home/giammi/org/notes.org"
 org-agenda-time-leading-zero t
 org-icalendar-use-scheduled '(event-if-not-todo event-if-todo todo-start)
 org-agenda-include-diary t
 org-after-todo-state-change-hook '(org-clock-out-if-current)
 org-latex-format-drawer-function #[514 "\207" [] 3 "\n\n(fn ## CONTENTS)"]
 org-odt-format-headline-function 'org-odt-format-headline-default-function
 org-from-is-user-regexp "\\"
 org-icalendar-timezone "Europe/Zurich"
 org-src-mode-hook '(org-src-babel-configure-edit-buffer
 org-src-mode-configure-edit-buffer)
 org-tags-column -79
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-babel-pre-tangle-hook '(save-buffer)
 org-log-redeadline 'time
 org-global-properties '(("Effort_ALL" .
  "0:30 1:00 2:00 3:00 4:00 5:00 6:00 8:00 12:00 0:00")
 ("STYLE_ALL" . "habit"))
 org-mode-hook '(turn-on-font-lock evil-org-mode
 #[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook org-show-block-all append
local]
   5 "\n\n(fn)"]
 #[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook org-babel-show-result-all
append local]
   5 "\n\n(fn)"]
 org-babel-result-hide-spec org-babel-hide-all-hashes
 org-eldoc-load)
 org-refile-targets '((org-agenda-files :maxlevel . 10))
 org-stuck-projects '("+LEVEL=2/-DONE" ("TODO" "NEXT" "NEXTACTION")
 

Re: [O] Sync up the org in emacs master to org maint branch?

[Stephen Leake]

Lars Ingebrigtsen  writes:

> John Wiegley  writes:
>
>> We're moving toward a future where Emacs.git will represent "core
>> Emacs", and only contain what core needs (plus a few historical bits,
>> I'm sure). There should be no argument for keeping a project in core
>> just to gain auxiliary benefits.
>
> I'm massively unenthusiastic about this future.  Things in ELPA has to
> be backwards-and-forwards compatible with a wide Emacs version range,

no, they don't.

That is one possible policy, but each package decides for itself whether
to follow it. You can have

;; package-requires: ((emacs "25.2"))

if you want.

If you want to maintain two versions, one for older emacs, one for
newer, you'll need two different package names, similar to gtk2, gtk3.


It does appear we need a "next release" branch in ELPA git similar to
"master" in emacs git, so the released ELPA package is still available,
but those working on emacs master can access the leading edge ELPA
packages.

> Emacs doesn't seem to have a massive surfeit of developers, so I wonder
> where this plan comes from.

Several developers prefer the decoupled development cycle of ELPA
packages.

It is primarily up to the package developers whether a package is in
core or not, at least until it is clear that there is no advantage to
being in core.

-- 
-- Stephe

[O] LaTeX math doesn't always export to HTML as math

[Richard Stanton]

I created the following very simple org file:




#+TITLE: *Math example*

\[ w_j = \nu_j \prod_{l
\[ w_j = \nu_j \prod_{l

Am I missing something?

By the way, org-version gives

Org mode version 9.0.5 (9.0.5-elpa @ /Users/stanton/.emacs.d/elpa/org-20170210/)

[O] Bug: org-insert-heading adds extra newlines [9.0.4 (release_9.0.4-222-g63aaff.dirty @ /home/kyle/.emacs.d/modules/org-mode/lisp/)]

[Kyle Sherman]

Hello.

When pressing M-return, which calls `org-insert-heading', in addition to
adding the new heading under the current one (and splitting if not at 
the end
of the line) it also now adds an additional newline after the new 
heading.  It

didn't used to do this.

This is the commit where this functionality changed:

68d8f860cd0b898a02f60ec3b4781f4ddf7d2627

If this was intentional, I do wish you would change it back as it 
continuously

adds more and more newlines if I keep adding headings.

BTW, I absolutely love org-mode.  I use it for everything!

Cheers, Kyle

Emacs  : GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, GTK+ Version 3.18.9)
 of 2016-04-17 on lgw01-04, modified by Debian
Package: Org mode version 9.0.4 (release_9.0.4-222-g63aaff.dirty @ 
/home/kyle/.emacs.d/modules/org-mode/lisp/)


current state:
==
(setq
 org-export-backends '(ascii html icalendar latex md org)
 org-hide-leading-stars t
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe 
org-babel-header-arg-expand)
 org-speed-command-hook '(org-speed-command-activate 
org-babel-speed-command-activate)

 org-reverse-note-order t
 org-ellipsis "…"
 org-occur-hook '(org-first-headline-recenter)
 org-src-tab-acts-natively t
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-agenda-start-on-weekday nil
 org-log-done 'time
 org-src-window-setup 'current-window
 org-confirm-shell-link-function nil
 org-time-stamp-custom-formats '("<%Y-%m-%d %a>" . "<%Y-%m-%d %a %H:%M>")
 org-file-apps '((auto-mode . emacs) ("\\.mm\\'" . default) 
("\\.x?html?\\'" . default)

 ("\\.pdf\\'" . emacs))
 org-special-ctrl-a/e t
 org-agenda-skip-scheduled-if-done t
 org-agenda-custom-commands '(("d" todo "DONE" nil) ("w" todo "WAITING" 
nil)

  ("W" agenda "" ((org-agenda-ndays 21)))
  ("A" agenda ""
   ((org-agenda-skip-function
 (lambda nil
  (org-agenda-skip-entry-if (quote 
notregexp)

   "\\=.*\\[#A\\]")
  )
 )
(org-agenda-ndays 1)
(org-agenda-overriding-header "Today's 
Priority #A tasks: "))

   )
  ("u" alltodo ""
   ((org-agenda-skip-function
 (lambda nil
  (org-agenda-skip-entry-if (quote 
scheduled)
   (quote deadline) (quote regexp) 
"<[^>\n]+>")

  )
 )
(org-agenda-overriding-header 
"Unscheduled TODO entries: "))

   )
  )
 org-return-follows-link t
 org-after-todo-state-change-hook '(org-clock-out-if-current)
 org-src-mode-hook '(org-src-babel-configure-edit-buffer 
org-src-mode-configure-edit-buffer)

 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-babel-pre-tangle-hook '(save-buffer)
 org-mode-hook '(local-org-mode-hook er/add-org-mode-expansions
 #[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook org-show-block-all 
append local] 5

   "\n\n(fn)"]
 #[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook 
org-babel-show-result-all append local]

   5 "\n\n(fn)"]
 org-babel-result-hide-spec org-babel-hide-all-hashes)
 org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3 
"\n\n(fn ENTRY)"]

 org-archive-hook '(org-attach-archive-delete-maybe)
 org-replace-disputed-keys t
 org-agenda-file-regexp "agenda.*\\.org\\'"
 org-directory "/home/kyle/org"
 org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
  org-cycle-show-empty-lines 
org-optimize-window-after-visibility-change)

 org-use-property-inheritance t
 org-todo-keywords '("TODO" "DONE")
 org-fast-tag-selection-single-key 'expert
 org-agenda-span 7
 org-babel-tangle-lang-exts '(("java" . "java") ("emacs-lisp" . "el") 
("elisp" . "el"))

 org-confirm-elisp-link-function nil
 org-src-ask-before-returning-to-edit-buffer nil
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-odd-levels-only t
 org-treat-S-cursor-todo-selection-as-state-change nil
 org-agenda-skip-deadline-if-done t
 org-link-parameters '(("id" :follow org-id-open)
   ("rmail" :follow org-rmail-open :store 
org-rmail-store-link)
   ("mhe" :follow org-mhe-open :store 
org-mhe-store-link)
   ("irc" :follow org-irc-visit :store 
org-irc-store-link)
   ("info" :follow org-info-open :export 
org-info-export :store

org-info-store-link)
   ("gnus" :fo

[O] org-table-(iterate/recalculate)-buffer-tables and remote tables in batch mode

[cédric ody]

Hi,

I can't manage the org-table-(iterate/recalculate)-buffer-tables
functions to work in batch mode.

When using the functions inside emacs, no problem, fields are well
calculated from remote tables.
I get errors and zeros when launching emacs in batch mode.

Any reason for that?

Cheers,

cédric

Re: [O] Sync up the org in emacs master to org maint branch?

[Edward John Steere]

>>  - Suppose that Emacs 22.0 is the current release and Emacs 22.1 is then
>>released; CEDET is at 
>>  - we update a registry somewhere indicating that Emacs 22.0 works with
>> and 22.1 works with
>>
>>  - When we make updates to CEDET we mark 22.1 as working with
>> but we don't change that reference
>>for 22.0 (or any older versions)
>>  - When someone complains that there's a bug in CEDET for 22.0 we
>>indicate that it's no longer supported and that they should update
>>Emacs to receive updates
>>
>> This process would almost be the same as what you get just by bundling
>> CEDET with Emacs except that:
>>
>>  - You can get the latest CEDET *if* you have the latest Emacs
>
> No. We have two branches: emacs-25 and master. The CEDET from master
> will usually not work on any 25.x version.

In the process which I proposed we would be developing against the most
recently released Emacs.  I now see that there's a trade off.  If we
were to go with my scheme then users would have access to the latest
version, but we would:
 1. miss out on the new features being developed on the Emacs master
branch (which CEDET stands to gain a lot from);
 2. have to endure a difficult and error prone release process every time
Emacs is released because that's not what all the testing is done
against;

If we go ahead and merge it in then we would be able to benefit from all
the new Emacs features and the release would be less painful.  Of course
our users would still have to wait for the latest features, but at least
it would be worth the wait because we would be able to consider using
features like threading.

>>  - The version of CEDET for any particular version of Emacs is as far as
>>CEDET got before the next release of Emacs came out
>>
>> If this is what you were thinking of then please could you elaborate on
>> what ended up being the problem which added more work.
>
> First off, CEDET is currently *not* a package, although that notion gets
> thrown around a lot. It is scattered across the Emacs code base:
> lisp/cedet, admin/grammars, etc/srecode, documentation, and test
> suite. All this needs to be packaged in a way so that it can be
> integrated into Emacs during a normal checkout. It needs to build and
> test in such a normal checkout, but also separately when installed from
> ELPA, including grammar compilation. And you need this twice: one for
> emacs-25, one for master, with the possiblity to merge between the two.

Yes, this would be a pain.  I'm in favour of Phillip's approach in which
the packages are self contained somewhere in the Emacs source tree.
This would eliminate the need for a complicated copying process and
eliminate the problem of where things go and what files should be
updated.  No other folder would be touched because a package contains
it's own source, documentation etc.  Unfortunately the idea isn't
gaining a lot of traction.  I'm not satisfied that the alternative would
make things easier for anyone because, as you say, it would need to
describe a complex copying process which intertwines CEDET with various
parts of Emacs.

> Then there's this "registry". No one has said how that should
> work. "Submodules/Subtrees" are *not* a sufficient answer, they are just
> tools. People will need to say how the *workflow* should be, including
> such things like merges from stable, ChangeLog generation, AUTHORS,
> NEWS, creating release tarballs, and so on. Once someone has written
> this down *in detail*, we can discuss again if this indeed will make
> things simpler and reduce our workload.

I haven't heard the registry mentioned before.  I mentioned it as a
detail required by my process for supporting multiple versions, but I'm
beginning to think that it's the wrong line of thought to pursue.

>>> Well, we cannot really discuss this since there's no real plan how this
>>> all should work. I can only speak from experience.
>>
>> We can still put ideas forward though.  Haven't come up with anything
>> myself yet though.
>
> Yes, you can, but it has a cost. Once again, the CEDET merge is stalled,
> and we spend our time writing mails. I find this situation incredibly
> frustrating.

In lieu of any input from others the best we have is Phillip's idea of
using Elpa.  That solves how the files are copied in and compiled.

>>> How does CEDET, Gnus and Org affect the rest of Emacs? They strongly
>>> depend on Emacs "core" (whatever exactly that is), not the other way
>>> round.
>>
>> I believe that one of the intentions of the move is to enforce this so
>> we can't build bad dependencies -- am I wrong?
>
> I think other modes should use Semantic.

Agreed.  I mentioned this in my response to Stefan's email.  Shouldn't
we then consider moving it out of CEDET in Emacs?

>> Perhaps I'm wrong, but to my mind the package approach would afford us
>> with more testing before we get to the point of another release of
>> Emacs.
>
> If you develop on Emacs 'master', you can u

[O] Problem of refile in the org capture buffer

[Liu Hui]

Hello,

I find C-c C-w (refine) in the org capture buffer doesn't work correctly 
when there are empty lines (containing the point) in the end of buffer. 
Steps to reproduce:


1. echo -e "* A\n* B" > /tmp/test.org; cat /tmp/test.org
* A
* B

2. Emacs -Q, and evaluate the code:

(setq org-capture-templates
  '(("t" "Todo" entry (file+headline "/tmp/test.org" "A")
 "** test1 %?")))

3. M-x org-capture, and press t to open the org capture buffer

4. In the capture buffer, press C-j to insert a newline, then C-c C-w:

   => the subtree "B" will be refiled rather than the "test1".


The problem is caused by org-capture-finalize, which deletes empty lines 
and, as a result, makes the point saved by org-capture-refile invalid. 
The following patch should fix the problem:


diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index 1a1a500..27cb60b 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -827,6 +827,9 @@ already gone.  Any prefix argument will be passed to 
the refile command."

(base (buffer-base-buffer (current-buffer)))
(org-capture-is-refiling t)
(kill-buffer (org-capture-get :kill-buffer 'local)))
+(and (< (skip-chars-backward " \t\n") 0)
+(not (bobp))
+(setq pos (point)))
 (org-capture-put :kill-buffer nil)
 (org-capture-finalize)
 (save-window-excursion


Emacs  : GNU Emacs 26.0.50.2 (x86_64-pc-linux-gnu, GTK+ Version 3.18.9)
 of 2016-12-17
Package: Org mode version 9.0.4 (release_9.0.4-283-g2064b0 @ 
~/org-mode/lisp/)

[O] Bug: save-some-buffers saves org-edit-special buffers to separate files [9.0.4 (9.0.4-elpa @ /home/thblt/.emacs.d/elpa25/org-20170124/)]

[Thibault Polge]

When calling (save-some-buffers t) while a code block is being edited
with org-edit-special, the org-edit-special buffer is saved to the disk
to a new, separate file with a name like:

dotemacs.org[*Org Src dotemacs.org[ emacs-lisp ]*]

I can reproduce this from emacs -Q with org 9.0.4 from org ELPA, but not
with builtin org in Emacs 25.1.

I would expect these buffers not to be saved at all, or at least to just
be synchronized back to the .org file which in turn gets saved.

Emacs  : GNU Emacs 25.1.1 (x86_64-pc-linux-gnu, GTK+ Version 3.22.5)
 of 2017-01-01, modified by Debian
Package: Org mode version 9.0.4 (9.0.4-elpa @ 
/home/thblt/.emacs.d/elpa25/org-20170124/)

current state:
==
(setq
 org-hide-leading-stars t
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe 
org-babel-header-arg-expand)
 org-speed-command-hook '(org-speed-command-default-hook 
org-babel-speed-command-hook)
 org-occur-hook '(org-first-headline-recenter)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-imenu-depth 6
 org-confirm-shell-link-function 'yes-or-no-p
 org-link-translation-function 'toc-org-unhrefify
 org-default-notes-file "~/Documents/LOG.org"
 org-after-todo-state-change-hook '(org-clock-out-if-current)
 org-from-is-user-regexp "\\"
 org-src-mode-hook '(org-src-babel-configure-edit-buffer
 org-src-mode-configure-edit-buffer)
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-babel-pre-tangle-hook '(save-buffer)
 org-mode-hook '(toc-org-enable (lambda nil (org-indent-mode t) 
(visual-line-mode t))
 er/add-org-mode-expansions
 #[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook org-show-block-all append 
local] 5]
 #[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook org-babel-show-result-all 
append
local]
   5]
 org-babel-result-hide-spec org-babel-hide-all-hashes 
org-eldoc-load)
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
  org-cycle-show-empty-lines
  org-optimize-window-after-visibility-change)
 org-download-annotate-function 'org-download-annotate-default
 org-hide-emphasis-markers t
 org-catch-invisible-edits t
 org-confirm-elisp-link-function 'yes-or-no-p
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-link-parameters '(("id" :follow org-id-open)
   ("rmail" :follow org-rmail-open :store 
org-rmail-store-link)
   ("mhe" :follow org-mhe-open :store org-mhe-store-link)
   ("irc" :follow org-irc-visit :store org-irc-store-link)
   ("info" :follow org-info-open :export org-info-export 
:store
org-info-store-link)
   ("gnus" :follow org-gnus-open :store org-gnus-store-link)
   ("docview" :follow org-docview-open :export 
org-docview-export
:store org-docview-store-link)
   ("bibtex" :follow org-bibtex-open :store 
org-bibtex-store-link)
   ("bbdb" :follow org-bbdb-open :export org-bbdb-export 
:complete
org-bbdb-complete-link :store org-bbdb-store-link)
   ("w3m" :store org-w3m-store-link) ("file+sys") 
("file+emacs")
   ("doi" :follow org--open-doi-link)
   ("elisp" :follow org--open-elisp-link)
   ("file" :complete org-file-complete-link)
   ("ftp" :follow (lambda (path) (browse-url (concat "ftp:" 
path
   ("help" :follow org--open-help-link)
   ("http" :follow
(lambda (path) (browse-url (concat "http:" path
   ("https" :follow
(lambda (path) (browse-url (concat "https:" path
   ("mailto" :follow
(lambda (path) (browse-url (concat "mailto:"; path
   ("message" :follow
(lambda (path) (browse-url (concat "message:" path
   ("news" :follow
(lambda (path) (browse-url (concat "news:"; path
   ("shell" :follow org--open-shell-link))
 org-agenda-files '("~/Documents/LOG.org")
 org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
 )

Re: [O] Sync up the org in emacs master to org maint branch?

[Edward John Steere]

>>> they are extremely dependend on
>>> many obscure Emacs internals (not sure about Org).
>>
>> Shouldn't we be trying to avoid this situation?  It's sure to come back
>> and bite us in the future.  If we continue to develop a package
>> (wherever it ends up being developed) which is so tightly coupled that
>> any kind of re factoring in core becomes a nightmare, because we have to
>> consider the umpteen ways in which it'll break the package, then surely
>> that's a bad methodology to continue?
>
> I don't know what you have in mind. All I can say is: CEDET couldn't do
> what it does if we'd restrict ourselves to some subset of Emacs.

In particular I was worried by the phrasing "extremely dependent".  I
agree that in order to make a system like CEDET without re-inventing the
wheel and without running into performance problems it's necessary to
depend on more primitive parts of Emacs.  Perhaps we can improve the
relationship(?)  Perhaps this is a discussion to be had when all of this
is done though.

>> I feel like this problem isn't intractable.
>
> I didn't say it's intractable. I just said it means more work for me.
>
>> We can mark some state of CEDET as being stable under the various
>> versions of Emacs (because it was at the time) and then only support
>> the current release for the latest package.  This would most likely
>> require changes to package to ensure that you get an appropriate
>> version of the package when you download it.
>
> As I said: we did that. It was a huge amount of work. Please understand
> where I'm coming from: if you look through the CEDET history, you will
> see that in the past few years I almost exclusively did infrastructure
> work and no real coding. All I can say is: *I* won't do this anymore,
> and I don't want to be part in something which will increase grunt
> work. We did not make this decision lightly. But with the amount of
> developers we have, I'm convinced it's the right thing to do.

Fair enough.  I don't have the experience here.  It just seems like we
could meet both goals without increasing the work load in this regard.
To be clear I agree that, whatever decision this discussion arrives at,
we definitely don't want to we waste the time of any developer with
grunt work.

Continuing this line of thought.  I'm not sure that we're thinking of
the same process here.  What I'm suggesting is as follows:

 - Suppose that Emacs 22.0 is the current release and Emacs 22.1 is then
   released; CEDET is at 
 - we update a registry somewhere indicating that Emacs 22.0 works with
and 22.1 works with
   
 - When we make updates to CEDET we mark 22.1 as working with
but we don't change that reference
   for 22.0 (or any older versions)
 - When someone complains that there's a bug in CEDET for 22.0 we
   indicate that it's no longer supported and that they should update
   Emacs to receive updates

This process would almost be the same as what you get just by bundling
CEDET with Emacs except that:

 - You can get the latest CEDET *if* you have the latest Emacs
 - The version of CEDET for any particular version of Emacs is as far as
   CEDET got before the next release of Emacs came out

If this is what you were thinking of then please could you elaborate on
what ended up being the problem which added more work.

Also, would this be a problem for our users?  i.e. would we be inundated
with emails requesting continued support on older versions or would
users generally accept this kind of change.  I mostly work on back end
systems so I don't have a good feeling for how this would go down with
users (I would find this reasonable as a user).

> Bug fixes can go with point release, which we should have every
> year. But yes, if you want the latest, greatest and buggiest, you'll
> have to use Emacs master. But that goes for a lot of Emacs features, so
> I don't see why it's particularly bad for CEDET.

I feel like there are aspects of CEDET which are still under
development.  Perhaps I'm just unlucky in my particular usage patterns
of upstream and the way things are going this will be fine (with the
un-merged parts going into packages.)

>> I'm interested in exploring more with regards to how the subtree
>> approach would work.  In particular how it would impact the Makefiles
>> and build process.  I don't think that introducing features like this
>> necessarily increases the burden of maintaining our tooling.  If we get
>> it right it could reduce it.
>
> Well, we cannot really discuss this since there's no real plan how this
> all should work. I can only speak from experience.

We can still put ideas forward though.  Haven't come up with anything
myself yet though.

>> I think that it's a worthwhile goal to make core smaller.  It may not be
>> a gigantic enterprise system with tens of thousands of source files,
>> like some of us are accustomed to working on, but I think that it
>> becomes easier to reason about the features and behaviour of core when
>> it's smaller.

[O] org-hide in terminal

[Johannes]

Hello,

With "org-hide-leading-stars" set to t orgmode tries to hide stars by
using the "org-hide" face. This is documented with: "The foreground
color of this face should be equal to the background
color of the frame." and in the org manual in section Clean-view we find
"Because Org makes the font color same as the background color to hide
to stars, sometimes org-hide face may need tweaking to get the effect
right. For some black and white combinations, grey90 on a white
background might mask the stars better". As far as I can tell (which
might be wront) it just assumes default colors "white" or "black", which
might not be accurate.

I think this is a bad solution for the following reasons.

- It doesn't work well if emacs runs in a terminal (often the stars just
get a grey background)
- It shows the stars when we mark them (this might or might not be a
good thing)
- People who use the same config in multiple environments (other
terminals and colors) will have to write some if-else code to get this
right.
- People who change their terminal colors get problems.


Possible solutions I can think of are:
a) Somhow make the existion solution work for terminals. I thought I
could simply set org-hides forground to the backgrounf-value of the face
"default", but somehow it didn't work out and I ended up with some sort
of grey (which is not my background).
b) emacs could have a text property, similar to "invisible", which hides
text but still lets it occupy the space. I don't know how it work
internaly, though. This is probably the best solution if the problem of
hiding text occurs more often. I was told this was already discussed on
emcas-devel, but I couldn't find it there.
c) hide the leading stars behind spaces. I have a working prototype
which works quite well. It uses "org-bullets" and "compose-region". It
is not 100% clean though, since there still is a character which might
be visible when using some minor mode.

I am very new to emacs-lsip (and mailing lists) so I hope this is how it
is done.
Johannes Lippmann

Re: [O] Using CEDET modules from Emacs core

[Eric Ludlam]

On 02/12/2017 11:00 AM, Dmitry Gutov wrote:

On 12.02.2017 05:33, Stefan Monnier wrote:
I don't have anything against supporting Semantic more widely, but we
should understand that it isn't something all users want. And the
"Semantic is too slow for C++" complaint (e.g. compared to Clang-based
background process solutions) is unlikely to go away.


There are a lot of ways to use semantic which changes its performance 
profile.  It depends on what features you want.  Most configuration help 
assumes you want all the most time consuming features, but there are 
also simple helpful features that are supported with minimal parsing 
support.   To boot, C++ is also the oldest parser in the suite and it 
wasn't updated to the newer/faster parser generator.


While I haven't had time to work on CEDET  lately, I'd be happy to 
discuss specific performance issues and share ideas on how to improve 
them, presumably after the most recent merge is completed.


Eric

Re: [O] org-annotate/collaboration?

[Eduardo Mercovich]

Hi Matt.

> Does anyone use org-annotate actively? I'm wondering what your
> workflow is, how you incorporate comments, etc. 
> I'm hoping to embark on a book project with a colleague.  [...]

Is the math "Homotopy Type Theory" book git solution too much for your
colleague? http://math.andrej.com/2013/06/20/the-hott-book/

I still didn't used git personally, but I'm looking for an opportunity.
;)

Best... 


-- 
Eduardo Mercovich 

 Donde se cruzan tus talentos 
 con las necesidades del mundo, 
 ahí está tu vocación. 
 (Anónimo) 

Re: [O] Sync up the org in emacs master to org maint branch?

[Edward John Steere]

>
> DE> This is a misunderstanding. I said I wanted to move support for certain
> DE> languages and project types into ELPA, not CEDET core. I'm still of the
> DE> opinion that moving it completely to ELPA is a mistake.
>
> It would only be a mistake if other parts of core need to use it. If only
> users make use of it, then having it ELPA will be invisible to them.

Apologies in advance for the significant verbage.

I just want to provide context.

* Context regarding CEDET:
(apologies: I know this thread is more concerned with org mode and, if
you'll bare with me, I think that this is relevant.)

I started the CEDET merge process a few months ago.  There was talk on
the CEDET mailing list regarding the difficulty of getting going with
CEDET as a user and/or a developer.  One of the ideas put forward was
that there ought to be a merge into Emacs so that one wouldn't have to
clone the repo, build the code and install it with some ELisp
config. hacking.

I got in touch with Eric directly and bounced some ideas passed him.
Subsequently I volunteered to help with the merge.  I got in touch with
JohnW and (not being very familiar with Emacs development) asked some
basic questions about how to go about accomplishing the merge.  What
resulted instead was the idea that we should try to look at streamlining
how CEDET get's included with the Emacs tarball rather than having it
live in two repositories.  I agreed with the idea and got to work on
getting a version of CEDET together which would work with 26.  I merged
in the Emacs -> CEDET direction and ended up with a version of CEDET
which is a WIP and works with Emacs 26.

Some time passed between then and the start of the discussions here.  I
think that the approach has evolved past what I was originally planning
on working towards and is now something along the lines of: do a final
merge of core CEDET components and make the rest into a series of ELPA
packages.


* What I think that we shouldn't lose sight of (if I may suggest it): is
that packaging CEDET, Org Mode and other packages like them in a process
which integrates them only when producing the tarball would serve to
simplify things for everyone.  Emacs core wouldn't be able to depend on
packages which are more relevant to the users (and package developers)
of Emacs, but these packages would still there like they always have
been when one downloads binary Emacs.

I'm new around here and I know that I lack the context and experience in
this project to make such swooping suggestions or judge the validity of
these points, but I thought that they would be worth raising.

Kind regards,

Edward Steere

Re: [O] Sync up the org in emacs master to org maint branch?

[Edward John Steere]

> It's not like packages communicate with Emacs over a well
> defined RESTful interface. In other words: CEDET and Gnus are not
> loosely coupled, quite the opposite: they are extremely dependend on
> many obscure Emacs internals (not sure about Org).

Shouldn't we be trying to avoid this situation?  It's sure to come back
and bite us in the future.  If we continue to develop a package
(wherever it ends up being developed) which is so tightly coupled that
any kind of re factoring in core becomes a nightmare, because we have to
consider the umpteen ways in which it'll break the package, then surely
that's a bad methodology to continue?  (I'm not suggesting that we
rewrite it to make it more loosely coupled, just that it seems like a
bad idea to continue allowing this going forward.)

> As a consequence, we
> and also the Gnus guys decided to not do separate releases anymore.  We
> used to provide CEDET for different Emacs versions, and it was a *huge*
> amount of work. I had a buildbot running with 7 or 8 Emacs versions to
> run the test suite, and things broke pretty regularly.
> Now you might say: fine, only release a package for current master. But
> let's say we put CEDET into ELPA. Emacs 26 gets released, and work on
> Emacs 27 starts. Now there are changes happening in Emacs 27 that
> require changes in CEDET, which make it incompatible with Emacs 26. So
> you have to create two packages: one for 26, one for 27? Not only is
> this confusing, but it most definitely increases my workload.

I feel like this problem isn't intractable.  We can mark some state of
CEDET as being stable under the various versions of Emacs (because it
was at the time) and then only support the current release for the
latest package.  This would most likely require changes to package to
ensure that you get an appropriate version of the package when you
download it.

Consider the problem which our users currently face.  The built in CEDET
is miles behind and missing very important bug fixes and features.  The
upstream CEDET can be a real pain to setup, but it has the latest
features.  This is not a good place to be.  If we merge CEDET in and
only release it with the realeses of Emacs then we are heading for a
state where you only get the new features and bug fixes every time Emacs
is realesed, i.e. our users might have to wait up to two years to have
something fixed.  This is also a bad place to be.

>> We can arrange things so that a Git clone of Emacs includes pulling the
>> submodules (or trees, or ELPA.git, or what not) that are considered part of
>> "main Emacs development", including some of those batteries. I see this all 
>> as
>> a process issue, and that "living in one Git repository" has just been an
>> implementation strategy to satisfy that process.
>
> Obviously, I'm very skeptical towards such an approach. Our tooling
> around Emacs development is already very intricate and only works
> because a few people work quietly behind the scenes to keep this all
> running. Introducing even more complexity through
> submodules/subtrees/whatever will do the opposite of what you want to
> achieve: it creates more work for those few people who manage the Emacs
> infrastructure. But I'd love to hear what for instance Glenn and Paul
> think about this.

I'm interested in exploring more with regards to how the subtree
approach would work.  In particular how it would impact the Makefiles
and build process.  I don't think that introducing features like this
necessarily increases the burden of maintaining our tooling.  If we get
it right it could reduce it.  For example we could establish some sort
of convention for building submodules/subtrees which allows us to
simplify the related Makefiles.

>> Why do the split at all? Core becomes smaller,
>
> First off, the Emacs repo isn't that big w.r.t. the number of
> files. Secondly, while there surely is an inverse correlation between
> repo size and maintainability, I would argue that as long as the Big
> Three are well maintained, they are not the problem. When did CEDET,
> Gnus or Org ever significantly delay an Emacs release?  When was an
> Emacs core developer ever forced to fix a critical thing in those
> packages he did not break?  These are the questions we should be
> asking. From watching this list over the past years, I don't get the
> feeling that the inclusion of these packages has been a significant
> burden, but I may be wrong.

I think that it's a worthwhile goal to make core smaller.  It may not be
a gigantic enterprise system with tens of thousands of source files,
like some of us are accustomed to working on, but I think that it
becomes easier to reason about the features and behaviour of core when
it's smaller.

>> updating packages within it is no longer a major issue, and (I hope)
>> it will be clearer when something is a core issue vs. a package issue.
>
> I find this whole core vs package argument strange. If you ship Emacs
> with Org, Gnus and CEDET, they are pa

[O] [SOLVED] Re: exclude_tags stoppped working at 9.0.5 release?

[Leslie Watter]

Hi,

On Fri, Feb 17, 2017 at 2:32 PM, Nick Dokos  wrote:

> Leslie Watter  writes:
>
> > Hi Folks,
> >
> > I've tried org-lint on the files of these pastebin:
> >
> > http://pastebin.com/p7D3Qwd6
> >
> > which are the same files but with tags on headlines, and it returned
> nothing to me, but again, I still
> > have
> > headings with :gabarito: exported to latex.
>
> The org-lint comment was a sideline: as Nicolas said, the problem is
> that empty headlines with tags are ambiguous: the following
>
> ***  :foo:
>
> is interpreted as a headline ":foo:" with no tag, not as an empty
> headline with tag :foo: - the workaround is not to have empty
> headlines:
>
> *** baz  :foo:
>


Thanks ! This works as expected !

Thanks a lot!


Cheers,

LEslie

Re: [O] exclude_tags stoppped working at 9.0.5 release?

[Nicolas Goaziou]

Nick Dokos  writes:

> the workaround is not to have empty
> headlines:
>
> *** baz  :foo:

You can also insert a non-breaking space in lieu of headline.

Regards,

Re: [O] Publishing versus normal exporting

[Nick Dokos]

Lawrence Bottorff  writes:

> I'm looking at this which seems to suggest a difference between
> "publishing" and normal export (e.g., C-c C-e h o to get an HTML
> export). The Emacs configuration given here would or would not be in
> force with a normal export? What this "complex publishing
> configuration" gives is exactly what I want, but only for one
> project. Is there a way to keep normal export -- and possibly
> multiple projects -- separate?
>

It would not be in force for normal export. The config file comes into
force when you invoke org-publish and specify a project. You can
specify different configs for different projects by adding entries to
org-publish-project-alist.  In fact, the complex config specifies four
projects, although it is true that three of them are components of the
fourth. Generally, you'd publish the "website" project and the sub-projects
would be published, but you can publish them individually as well.

--
Nick

Re: [O] exclude_tags stoppped working at 9.0.5 release?

[Nick Dokos]

Leslie Watter  writes:

> Hi Folks,
>
> I've tried org-lint on the files of these pastebin:
>
> http://pastebin.com/p7D3Qwd6
>
> which are the same files but with tags on headlines, and it returned nothing 
> to me, but again, I still
> have 
> headings with :gabarito: exported to latex.

The org-lint comment was a sideline: as Nicolas said, the problem is
that empty headlines with tags are ambiguous: the following

***  :foo:

is interpreted as a headline ":foo:" with no tag, not as an empty
headline with tag :foo: - the workaround is not to have empty
headlines:

*** baz  :foo:

-- 
Nick

[O] Publishing versus normal exporting

[Lawrence Bottorff]

I'm looking at this
 which
seems to suggest a difference between "publishing" and normal export (e.g.,
C-c C-e h o to get an HTML export). The Emacs configuration given here
 would or
would not be in force with a normal export? What this "complex publishing
configuration" gives is exactly what I want, but only for one project. Is
there a way to keep normal export -- and possibly multiple projects --
separate?

LB

Re: [O] exclude_tags stoppped working at 9.0.5 release?

[Leslie Watter]

Hi Folks,

I've tried org-lint on the files of these pastebin:

http://pastebin.com/p7D3Qwd6

which are the same files but with tags on headlines, and it returned
nothing to me, but again, I still have
headings with :gabarito: exported to latex.

Even using a fresh installation of spacemacs as a test (just to remove any
pre-configuration I had) it acts the same, exporting gabarito sections.

Any hints ?

Cheers,

Leslie

On Fri, Feb 17, 2017 at 10:25 AM, Nicolas Goaziou 
wrote:

> Hello,
>
> Nick Dokos  writes:
>
> > Nick Dokos  writes:
> >
> >> Leslie Watter  writes:
> >>
> >>
> >>> ** First Section
> >>>
> >>> At 1st
> >>>
> >>> ***
> :professor:
> >>> This should not appear on t.pdf
> >>> ---
> >>>
> >> You might try running org-lint.
> >
> > Actually, I don't think org-lint detects empty headlines.
>
> Empty headlines are supported but an empty headline with tags is
> ambiguous. Currently Org prefers to see a headline with ":professor:"
> title and no tag.
>
> I added a checker in Org Lint. Thank you.
>
>
> Regards,
>
> --
> Nicolas Goaziou
>
>


-- 
Leslie H. Watter

Re: [O] org babel table header sent to awk code block

[Roland Everaert]

I see that more or less 30 seconds after posting to the ML :/

So the problem of this script is solved.

But anyway, why are column headers sent to the script, even with :hlines
and/or :colnames set approriately?

Thanks.

On Fri, Feb 17, 2017 at 2:08 PM, Eric S Fraga  wrote:

> On Friday, 17 Feb 2017 at 12:33, Roland Everaert wrote:
> > Hi,
> >
> > I am trying to filter a table using the following awk code block.
>
> I think your problem is an error in the awk script; specifically, the
> match is outputting all lines because you need to have the { on the same
> line as the match expression.  Try this:
>
> #+BEGIN_SRC awk :stdin list-example :var fstcol=1 :var seccol=3 :results
> output org
>   BEGIN {
>   print "|Host|Result"
>   print "|-"
>   }
>   $seccol ~ /[0-9]{1,3}(\.[0-9]\{1,3\}){3}/ {
>   print "|"$fstcol"|"$seccol
>   }
> #+END_SRC
>
> You may have noticed that the second line (which had an empty third
> column so should not have matched) was also being output when it
> shouldn't have.
>
> In any case, the above works for me.
>
> HTH,
> eric
>
> --
> : Eric S Fraga (0xFFFCF67D), Emacs 26.0.50.1, Org release_9.0.4-242-g2c27b8
>

Re: [O] org babel table header sent to awk code block

[Eric S Fraga]

On Friday, 17 Feb 2017 at 12:33, Roland Everaert wrote:
> Hi,
>
> I am trying to filter a table using the following awk code block.

I think your problem is an error in the awk script; specifically, the
match is outputting all lines because you need to have the { on the same
line as the match expression.  Try this:

#+BEGIN_SRC awk :stdin list-example :var fstcol=1 :var seccol=3 :results output 
org
  BEGIN {
  print "|Host|Result"
  print "|-"
  }
  $seccol ~ /[0-9]{1,3}(\.[0-9]\{1,3\}){3}/ {
  print "|"$fstcol"|"$seccol
  }
#+END_SRC

You may have noticed that the second line (which had an empty third
column so should not have matched) was also being output when it
shouldn't have.

In any case, the above works for me.

HTH,
eric

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 26.0.50.1, Org release_9.0.4-242-g2c27b8


signature.asc
Description: PGP signature

Re: [O] Bug: Bug in Orgmode Clocktable? [9.0.5 (9.0.5-elpa @ c:/Users/sane/AppData/Roaming/.emacs.d/elpa/org-20170210/)]

[Nicolas Goaziou]

Hello,

I'm Cc'ing the mailing list for archiving purpose.

michael.zi...@xiron.de writes:

> here is the backtrace: 
>
> Debugger entered--Lisp error: (wrong-type-argument char-or-string-p nil)
>   insert-before-markers("|" "" "" "" "" nil "|" nil "|" "|" "\n")
>   org-clocktable-write-default(262 ((nil 0 nil)) (:maxlevel 2 :lang "de"
> :scope subtree :block nil :wstart 1 :mstart 1 :tstart nil :tend nil
> :step nil :stepskip0 nil :fileskip0 nil :tags nil :emphasize nil :link
> nil :narrow 40! :indent t :formula nil :timestamp nil :level nil
> :tcolumns nil :formatter nil :name "clocktable" :indentation-column 0
> :content #("#+CAPTION:  [2017-02-17 Fr 14:12]\n|\n" 0 10 (fontified t
> font-lock-fontified t face org-meta-line) 10 12 (fontified t) 12 32
> (fontified t mouse-face highlight keymap (keymap (follow-link .
> mouse-face) (mouse-3 . org-find-file-at-mouse) (mouse-2 .
> org-open-at-mouse)) face org-block font-lock-fontified t) 32 33
> (fontified t mouse-face highlight keymap (keymap (follow-link .
> mouse-face) (mouse-3 . org-find-file-at-mouse) (mouse-2 .
> org-open-at-mouse)) rear-nonsticky (mouse-face highlight keymap
> invisible intangible help-echo org-linked-text htmlize-link) face
> org-block font-lock-fontified t) 33 36 (fontified t)) :multifile nil))
>   #[0 "\303\300@\304\"\211\305=\203 
>
> Concerning ECM: It happens to me in every orgmode file on version
> 9.0.2.

It happens because no translation is available for "de" in
`org-clock-clocktable-language-setup'.

This is fixed.

Thank you.

Regards,

-- 
Nicolas Goaziou0x80A93738

Re: [O] Why is Org PDF LaTeX Output not readonly?

[Nick Dokos]

Eric S Fraga  writes:

> On Thursday, 16 Feb 2017 at 14:48, Nick Dokos wrote:
>
> [...]
>
>> I don't understand this: why is it easier if the buffer is read-only?
>> Don't you still have to do M-x kill-buffer?
>
> IIUC, it's not so much read-only as a special mode where a single 'q'
> will bury the buffer (or delete it, maybe).  Sort of like docview or
> what read-only views give.

Ok - thanks!

-- 
Nick

Re: [O] Why is Org PDF LaTeX Output not readonly?

[Nicolas Goaziou]

Hello,

Florian Lindner  writes:

> Am 16.02.2017 um 14:47 schrieb Eric S Fraga:
>> On Thursday, 16 Feb 2017 at 08:33, Florian Lindner wrote:
>>> It would be much easier to close it quickly this way and it would be
>>> consistent with other buffers that serve the same
>>> purpose, like the beforementioned Auctex output buffer.
>> 
>> It would indeed be easier.  The buffer is created in org-latex-compile
>> and I guess it would be the case of setting the mode for the buffer?
>> Beyond my level of elisp expertise however.
>
> There is with-output-to-temp-buffer with redirects the output to a temp 
> buffer that behaves like a help window and shows
> that buffer Using this function however makes only sense, when org mode 
> defaults to displaying the latex output in case
> something goes wrong. Which, imo would be as sensible default too.
>
> Changing that is also way beyond my elisp knowlege.

In development version, Org now switches compilation buffers to
`compilation-mode'.

Thank you.

Regards,

-- 
Nicolas Goaziou

[O] org babel table header sent to awk code block

[Roland Everaert]

Hi,

I am trying to filter a table using the following awk code block.
#+BEGIN_SRC awk :stdin list-example :var fstcol=1 :var seccol=3 :results
output org
  BEGIN {
  print "|Host|Result"
  print "|-"
  }
  $seccol ~ /[0-9]{1,3}(\.[0-9]\{1,3\}){3}/
  {
  print "|"$fstcol"|"$seccol
  }
#+END_SRC

The input table:

#+NAME: list-example
| A  |B |C |
|+--+--|
| blabla |  12.147.5.74 | 10.23.31.189 |
| test   |  147.12.5.74 |  |
| hello  | 79.147.64.74 | 10.23.31.189 |


And the result is:


#+RESULTS:
#+BEGIN_SRC org
| Host   |   Result |
|+--|
| A  |C |
| blabla | 10.23.31.189 |
| test   |  |
| hello  | 10.23.31.189 |
#+END_SRC


Why the column names of the table are sent to awk?

I have tried to set :colnames and :hlines, but that doesn't change the
behavior.


Regards.

Re: [O] Bug: Bug in Orgmode Clocktable? [9.0.5 (9.0.5-elpa @ c:/Users/sane/AppData/Roaming/.emacs.d/elpa/org-20170210/)]

[Nicolas Goaziou]

Hello,

michael.zi...@xiron.de writes:
>
> i am running orgmode version 9.0.5 on GNU Emacs 24.3.1 on Windows.
> On a second PC im running orgmode version 9.0.2 also on Windows.
> When i now try to update the org clock table report on the version 9.0.5
> then i get a "org-clocktable-write-default: Wrong type argument:
> char-or-string-p, nil"
>
> I compared the two versions of org-clocktable-write-default in
> org-clock.el between 9.0.5 and 9.0.2 and the crash happens here:

Could you provide more backtrace? Also an ECM would help, if you can
produce one.

Regards,

-- 
Nicolas Goaziou

Re: [O] exclude_tags stoppped working at 9.0.5 release?

[Nicolas Goaziou]

Hello,

Nick Dokos  writes:

> Nick Dokos  writes:
>
>> Leslie Watter  writes:
>>
>>
>>> ** First Section
>>>
>>> At 1st 
>>>
>>> ***                                                               
>>> :professor:
>>> This should not appear on t.pdf
>>> ---
>>>
>> You might try running org-lint.
>
> Actually, I don't think org-lint detects empty headlines.

Empty headlines are supported but an empty headline with tags is
ambiguous. Currently Org prefers to see a headline with ":professor:"
title and no tag.

I added a checker in Org Lint. Thank you.


Regards,

-- 
Nicolas Goaziou

[O] Bug: Bug in Orgmode Clocktable? [9.0.5 (9.0.5-elpa @ c:/Users/sane/AppData/Roaming/.emacs.d/elpa/org-20170210/)]

[michael . ziems]

Hello,

i am running orgmode version 9.0.5 on GNU Emacs 24.3.1 on Windows.
On a second PC im running orgmode version 9.0.2 also on Windows.
When i now try to update the org clock table report on the version 9.0.5
then i get a "org-clocktable-write-default: Wrong type argument:
char-or-string-p, nil"

I compared the two versions of org-clocktable-write-default in
org-clock.el between 9.0.5 and 9.0.2 and the crash happens here:

Version 9.0.5:

;; Insert the table header line
(insert-before-markers
 "|"  ; table line starter
 (if multifile (concat (nth 1 lwords) "|") "")  ; file column, maybe
 (if level-p   (concat (nth 2 lwords) "|") "")  ; level column,
maybe
 (if timestamp (concat (nth 3 lwords) "|") "")  ; timestamp column,
maybe
 (if properties (concat (mapconcat 'identity properties "|") "|")
"") ;properties columns, maybe
 (nth 4 lwords) "|";headline
 (nth 5 lwords) "|";time column
 (make-string (1- (min maxlevel (or ntcol 100))) ?|)
 (if (eq formula '%) "%|\n" "\n"))

On the line 2551 for the "(if (eq formula '%) "%|\n" "\n"))"

When i compare version 9.0.2 the code changed:

;; Insert the table header line
(insert-before-markers
 "|"  ; table line starter
 (if multifile (concat (nth 1 lwords) "|") "")  ; file column, maybe
 (if level-p   (concat (nth 2 lwords) "|") "")  ; level column,
maybe
 (if timestamp (concat (nth 3 lwords) "|") "")  ; timestamp column,
maybe
 (if properties (concat (mapconcat 'identity properties "|") "|")
"") ;properties columns, maybe
 (concat (nth 4 lwords) "|"
 (nth 5 lwords) "|\n")) ; headline and time
columns

My Elisp skills are still quite limited, maybe somebody else could tell
me what is wrong and how to proceed.
Any help is highly appreciated.

Thanks,

Michael

Emacs  : GNU Emacs 24.3.1 (i386-mingw-nt6.2.9200)
 of 2013-03-17 on MARVIN
Package: Org mode version 9.0.5 (9.0.5-elpa @
c:/Users/sane/AppData/Roaming/.emacs.d/elpa/org-20170210/)

Re: [O] g: Feature request: table formulas: resolve references on LHS [9.0.5 (9.0.5-elpa @ /home/daniel/.emacs.d/elpa/org-20170210/)]

[Nicolas Goaziou]

Hello,

Quazgar  writes:

> As hinted on the manual http://orgmode.org/manual/Column-formulas.html
> and written explicitly on a StackOverflow topic
> http://emacs.stackexchange.com/questions/15185/cant-assign-to-hline-relative-reference,
> the left hand side of table formulas currently cannot contain
> references:
>
>The left-hand side of a column formula cannot be the name of column,
>it must be the numeric column reference or $>.
>
> In examples like the following, this would be very convenient though:
>
> | Value 1 | Value 2 | Sum |
> |-+-+-|
> |   1 |   1 | |
> |   3 |   4 | |
> |-+-+-|
> | Average | of sums | |
>
> #+TBLFM: @I$3..@II$3=$1+$2::$3=vmean(@I..@II)
>
> If I remember correctly, it used to work (I found a similar line in
> org documents from June 2015).  Is it possible to have this feature
> (back), now officially?

This feature was never introduced, at least in a correct implementation.
At some point, there was something like it, but it was broken and was
consequently removed.

AFAIR, relative references using hlines (e.g., @I) is not well defined
and is therefore difficult to implement. You may want to search the
mailing list archives about it.

Regards,

-- 
Nicolas Goaziou

[O] g: Feature request: table formulas: resolve references on LHS [9.0.5 (9.0.5-elpa @ /home/daniel/.emacs.d/elpa/org-20170210/)]

[Quazgar]

As hinted on the manual http://orgmode.org/manual/Column-formulas.html
and written explicitly on a StackOverflow topic
http://emacs.stackexchange.com/questions/15185/cant-assign-to-hline-relative-reference,
the left hand side of table formulas currently cannot contain
references:

  The left-hand side of a column formula cannot be the name of column,
  it must be the numeric column reference or $>.

In examples like the following, this would be very convenient though:

| Value 1 | Value 2 | Sum |
|-+-+-|
|   1 |   1 | |
|   3 |   4 | |
|-+-+-|
| Average | of sums | |
#+TBLFM: @I$3..@II$3=$1+$2::$3=vmean(@I..@II)

If I remember correctly, it used to work (I found a similar line in
org documents from June 2015).  Is it possible to have this feature
(back), now officially?

Best,

quazgar


Emacs  : GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, GTK+ Version 3.22.7)
 of 2017-01-22 on trouble, modified by Debian
Package: Org mode version 9.0.5 (9.0.5-elpa @ 
/home/xxx/.emacs.d/elpa/org-20170210/)


current state:
==
(setq
 org-src-lang-modes '(("ocaml" . tuareg) ("elisp" . emacs-lisp)
  ("ditaa" . artist) ("asymptote" . asy)
  ("dot" . fundamental) ("sqlite" . sql)
  ("calc" . fundamental) ("C" . c) ("cpp" . c++)
  ("screen" . shell-script) ("dot" . 
graphviz-dot-mode))

 org-export-backends '(ascii html icalendar latex md odt org)
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe
  org-babel-header-arg-expand)
 org-speed-command-hook '(org-speed-command-default-hook
  org-babel-speed-command-hook)
 org-time-clocksum-format '(:hours "%d" :require-hours t :minutes 
":%02d"

:require-minutes t)
 org-clock-history-length 100
 org-occur-hook '(org-first-headline-recenter)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-confirm-shell-link-function 'yes-or-no-p
 org-pretty-entities t
 org-use-sub-superscripts '{}
 org-after-todo-state-change-hook '(org-clock-out-if-current)
 org-from-is-user-regexp "\\"
 org-src-mode-hook '(org-src-babel-configure-edit-buffer
 org-src-mode-configure-edit-buffer)
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-agenda-clock-consistency-checks '(:max-duration "10:00" 
:min-duration 0

   :max-gap "0:05" :gap-ok-around
   ("12:30" "00:00") :default-face
   ((:background "DarkRed")
(:foreground "white"))
   :overlap-face nil :gap-face
   ((:background "coral")
(:foreground "black"))
   :no-end-time-face
   ((:background "lime green")
(:foreground "black"))
   :long-face nil :short-face nil)
 org-pretty-entities-include-sub-superscripts nil
 org-babel-pre-tangle-hook '(save-buffer)
 org-mode-hook '(#[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook org-show-block-all 
append

local]
   5 "\n\n(fn)"]
 #[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook 
org-babel-show-result-all

append local]
   5 "\n\n(fn)"]
 org-babel-result-hide-spec org-babel-hide-all-hashes)
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-cycle-hook '(org-cycle-hide-archived-subtrees 
org-cycle-hide-drawers

  org-cycle-show-empty-lines
  org-optimize-window-after-visibility-change)
 org-mouse-1-follows-link nil
 org-catch-invisible-edits 'show-and-error
 org-confirm-elisp-link-function 'yes-or-no-p
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-log-into-drawer t
 org-clock-clocktable-default-properties '(:maxlevel 3 :scope file)
 org-startup-truncated nil
 org-link-parameters '(("id" :follow org-id-open)
   ("rmail" :follow org-rmail-open :store
org-rmail-store-link)
   ("mhe" :follow org-mhe-open :store 
org-mhe-store-link)
   ("irc" :follow org-irc-visit :store 
org-irc-store-link)
   ("info" :follow org-info-open :export 
org-info-export

:store org-info-store-link)
   ("gnus" :follow org-gnus-open :store
org-gnus-store-link)
   ("docview" :follow org-docview-open :export
org-docview-export :store 
org-docview-store-link)

   ("bibtex" :follow org-bibtex-open :store
o