Re: ob-plantuml: Proposal to add 'jar-args' customizable variable
On Fri 03 Dec 2021, Dejan Josifović wrote: > Hi all, > > I use PlantUML integration in org-mode for years now, but only > recently I came across some unwanted behavior. > > Using PlantUML from jar (org-plantuml-jar-path variable) and latest > org-mode, I wanted to render a diagram containing some Unicode > characters (such as '⊥' and '∀'), but the end image had some gibberish > instead. However, > trying this from a standalone file using plantuml-mode[1], the end image > rendered correctly. Here is some sample code which can reproduce the issue: > > #+BEGIN_SRC plantuml :file ./test.png > A -> B: ∀ characters display correctly is ⊥ > #+END_SRC > > Comparing ob-plantuml.el and plantuml-mode.el files I found what is the > problem. plantuml-mode has a customizable variable for specifying > arguments when using PlantUML from jar (plantuml-jar-args (list > "-charset" "UTF-8" ). The charset arguments is what is needed for > the images to render correctly (I confirmed it by implementing it locally). > > I was wondering why such variable doesn't exist in ob-plantuml. I have > searched the mailing list archives, confirmed bugs and help page and > couldn't find anything related. I use this snippet to set the ob-plantuml.el args to match the plantuml-mode.el settings: (setf (alist-get :javaorg-babel-default-header-args:plantuml) (mapconcat #'identity plantuml-java-args " ") (alist-get :cmdline org-babel-default-header-args:plantuml) (mapconcat #'identity plantuml-jar-args " ")) Hope that helps, AndyM
Re: Bug: Org 9.3 table columnwidth directive not working [9.3 (release_9.3 @ /Applications/Emacs.app/Contents/Resources/lisp/org/)]
On Sat 07 Dec 2019, Nicolas Goaziou wrote: > Hello, > > Andy Moreton writes: > >> That still does not match the old behaviour though, as the table still >> shows the `org-table-shrunk-column-indicator' overlay which is >> undesireable. > > Why is it undesirable? It also always shows the shrink/expend overlay, even if that is not desired. I find it visually intrusive, and the extra character introduces a new misalignment. >> Dynamic shrink/expand is a fine feature to add, but why was it done in a >> way that broke the documented existing behaviour ? > > I think the current state is better. However, I initially explained the > motivation behind this change (see links in this thread). While everyone has their own preferences, developers should not impose their preferences on users, who may decide to make different choices. The dynamic shrink feature added a new capability that many will find useful, but it also removed the ability to do things the older and simpler way. It should have been added as an option, so either static or dynamic behaviour can be selected by the user. AndyM
Re: Bug: Org 9.3 table columnwidth directive not working [9.3 (release_9.3 @ /Applications/Emacs.app/Contents/Resources/lisp/org/)]
On Fri 06 Dec 2019, Nicolas Goaziou wrote: > Hello, > > Andy Moreton writes: > >> This is still a regression. >> >> The old behaviour allowed display of fixed width columns, even if that >> is wider than the content of cells in that column. This is useful for >> display of several related tables with aligned column dividers. >> >> How do I get the old behaviour back, rather than the new breakage ? > > I will try to ignore the sarcasm, or whatever you may call it, from your > answer. No sarcasm intended, merely a re-statement that this change is a regression of user visible behaviour. > AFAICT, you still can have cells wider than their contents, e.g., try > `C-c TAB` on the table below. > > | <30> | > | foo | That still does not match the old behaviour though, as the table still shows the `org-table-shrunk-column-indicator' overlay which is undesireable. Dynamic shrink/expand is a fine feature to add, but why was it done in a way that broke the documented existing behaviour ? AndyM
Re: Bug: Org 9.3 table columnwidth directive not working [9.3 (release_9.3 @ /Applications/Emacs.app/Contents/Resources/lisp/org/)]
On Thu 05 Dec 2019, Kyle Meyer wrote: > Pankaj Jangid writes: > >> C-c TAB is working but earlier the behaviour was to apply >> directive by default on next electric formatting. Has the behaviour >> changed in 9.3? > > 9.2, I believe, more specifically 6d6a30d4c (org-table: Implement shrunk > columns, 2017-06-27). The relevant NEWS entry, added in 6e5598dc3 > (Document new column display, 2017-08-19), is > > *** =align= STARTUP value no longer narrow table columns > > Columns narrowing (or shrinking) is now dynamic. See [[*Dynamically > narrow table columns]] for details. In particular, it is decoupled from > aligning. > > If you need to automatically shrink columns upon opening an Org > document, use =shrink= value instead, or in addition to align: > > #+BEGIN_EXAMPLE > ,#+STARTUP: align shrink > #+END_EXAMPLE > > Quickly digging, here are some related threads on the mailing list: > > https://lists.gnu.org/archive/html/emacs-orgmode/2017-07/msg00214.html > https://lists.gnu.org/archive/html/emacs-orgmode/2017-09/msg00217.html This is still a regression. The old behaviour allowed display of fixed width columns, even if that is wider than the content of cells in that column. This is useful for display of several related tables with aligned column dividers. How do I get the old behaviour back, rather than the new breakage ? AndyM
Re: [O] Bug: Bug in svg generation from plantuml sources [9.1.7 (9.1.7-20-ge1f1ac-elpa @ /home/guertler/.emacs.d/elpa/org-20180319/)]
On Tue 20 Mar 2018, Martin Gürtler wrote: > ob-plantuml wraps a plantuml source in @startuml/@enduml tags without > checking whether they are already in the source code. This results in > the creation of invalid SVG, at least for newer versions of plantuml, > because the resulting SVG file contains then two XML documents ((I was > using version 1.2018.2, it seems to work though for older plantuml > versions <= 8059). > > So the following does not work > > #+BEGIN_SRC plantuml :file "out.svg" > @startuml > a->b > @enduml > #+END_SRC > > > while this works: > > #+BEGIN_SRC plantuml :file "out.svg" > a->b > #+END_SRC > > Every plantuml example I found contains @startuml/@enduml so all my old > org mode files do contain the tags... I feel the required change is not > very difficult, but unfortunately I do not speak elisp at all... > > Emacs : GNU Emacs 25.2.2 (x86_64-pc-linux-gnu, GTK+ Version 3.22.28) > of 2018-02-19, modified by Debian > Package: Org mode version 9.1.7 (9.1.7-20-ge1f1ac-elpa @ > /home/guertler/.emacs.d/elpa/org-20180319/) > > Thanks for considering, > > Martin Note that newer versions of plantuml supports additional diagram types, so diagrams may need to use: @startuml .. @enduml @startsalt .. @endsalt @startdot .. @enddot @startditaa .. @endditaa @startgantt .. @endgantt It is expected that support for new diagram types will use keywords starting with "@start" and "@end" as delimiters. See "Generalisation" at http://plantuml.com/ditaa for more details. AndyM
Re: [O] Release 9.0.4
On Wed 25 Jan 2017, Joon Ro wrote: >> Will this get syncd to the emacs repo ? > >> The emacs master branch still has org 8.2.10. > > You might want to add the org repo if you want to get the latest version of > org. I have the following in my init.el file (org in addition to melpa): Thats not what I was asking. The emacs repo contains a copy of Org mode (excluding contrib), and this copy needs attention from the Org maintainer to keep it up to date. AndyM
Re: [O] Release 9.0.4
On Wed 25 Jan 2017, Bastien wrote: > Hi all, > > Org 9.0.4 is out now. > > Enjoy! Will this get syncd to the emacs repo ? The emacs master branch still has org 8.2.10. AndyM
Re: [O] Trouble passing variables into shell blocks on windows
On Sun 14 Jun 2015, Johan W. Klüwer wrote: I'm having difficulties passing org variables into shell source blocks. This is using Windows 7 and Cygwin with bash shell. For instance, the following #+BEGIN_SRC sh :var x=. ls $x #+END_SRC fails with the error message (as displayed in emacs) ls: cannot access .^M^M : No such file or directory As far as I can see, the first ^M stems from org-babel-sh-var-quote-fmt, and the second from org-babel-expand-body:generic, but I haven't been able to figure out a solution. Any suggestions? I can reproduce this using the native Windows build of emacs. If you are using cygwin tools, consider using a cygwin build of emacs, which will not suffer from this problem. If you running an X server then the cygwin emacs-X11 package is what you need. If you don't want to run an X server then the emacs-w32 package may fit your needs (a cygwin native build of emacs that uses the Windows GUI for display). HTH, AndyM
Re: [O] Launching Emacs org-mode commands from Windows 7 command line?
On Thu 31 Jul 2014, Martin Beck wrote: I want to use a shell command in Windows 7 command prompt (cmd.exe) to create a search agenda view in Emacs org-mode (in the active frame). I tried like that: emacsclient --eval '(org-search-view nil search string)' but with no success. In the command line I get the error message: *ERROR*: End of file during parsing And I get no a search or search result in Emacs org-mode. Any tips are appreciated. I'm using Windows 7, Emacs 24.3 and org-mode 8.2.6 Kind regards Martin cmd.exe has strange quoting rules. Does this work for you ? emacsclient --eval (org-search-view nil search string) HTH AndyM
Re: [O] backslashchar in texinfo
On 06/01/2013 20:20, Bastien wrote: Hi Andy, Andy Moreton andrewjmore...@gmail.com writes: This still appears to be broken in emacs trunk - could you please update the org manual there to fix this too ? This has been fixed in the emacs-24 branch and will be merged into trunk soon. Thanks for sorting this out, AndyM
Re: [O] backslashchar in texinfo
On Sun 06 Jan 2013, Bastien wrote:
Hi Takaaki,
Takaaki ISHIKAWA tak...@ieee.org writes:
I found two build errors in the latest org manual(HEAD of git).
1. Using ``@backslashcar{}'' command in texinfo(L5114).
2. Missing ``@''(L3091).
Thanks for reporting this!
The texinfo command was introduced at the version 4.14,
see http://permalink.gmane.org/gmane.comp.gnu.lilypond.devel/51827.
I think the command should not be used because many users
currently use the previous version 4.13.
Any comments?
I backported a diff from the Emacs trunk erroneously.
It is fixed now.
This still appears to be broken in emacs trunk - could you please update
the org manual there to fix this too ?
Thanks,
AndyM
Re: [O] source code disappears
On 17/11/2012 12:41, Bastien wrote: Hi Andy, Andy Moreton andrewjmore...@gmail.com writes: When I switch to the ELPA version ( Org-mode version 7.9.2 (7.9.2-82-g2aeb28-elpa @ . . . )) this misbehavior is corrected. HTH. I've filed emacs bug#12905 about this, as it is occurring in on the emacs-24 branch, and emacs 24.3 is getting close to release. Can somebody please update org mode in emacs to bring it up to date. I will take care of this before the end of the pretest week. Hi Bastien, I haven't seen this merge appear on the emacs-24 branch yet - any idea when you will have time to do the merge ? Thanks, AndyM
[O] bug#12905: 24.2.50; org: edit source block causes data loss
On Wed 12 Dec 2012, Bastien wrote: This is fixed, thanks for the heads up. I just merged the Org bugfix branch into emacs-24. I can confirm the bug is fixed for emacs-24 after this merge. Thanks Bastien, AndyM
Re: [O] source code disappears
On Fri 16 Nov 2012, Neil Best wrote: When I switch to the ELPA version ( Org-mode version 7.9.2 (7.9.2-82-g2aeb28-elpa @ . . . )) this misbehavior is corrected. HTH. I've filed emacs bug#12905 about this, as it is occurring in on the emacs-24 branch, and emacs 24.3 is getting close to release. Can somebody please update org mode in emacs to bring it up to date. Thanks, AndyM
Re: [O] Bug: source code editing using C-c ' (org-edit-special) eats characters
On 07/11/2012 23:02, Eric S Fraga wrote: Andy Moreton andrewjmore...@gmail.com writes: I'm seeing a similar problem in emacs trunk (r110821) where C-c ' in the *Org Src* buffer closes the source edit window and discards the entire contents of the source block. Should I raise an emacs bug for this ? AndyM I've seen this happen recently as well, specifically where I have added comment lines to the source, e.g. lines starting with # in sh src code blocks. I was in a rush to get something done so didn't stop to try to figure out what was happening or to generate a minimal example. I also don't know if it's still happening -- this happened to me late last week, IRC. I also don't know if the problem was dependent on the version of Emacs as I use three systems daily (long story). This problem does seem difficult to reproduce consistently. Editing this to add new source discarded all edits: #+begin_src c #+end_src Changing it to use C made it keep the edits: #+begin_src C #+end_src However after changing the source block back to using c, the problem did not return. I've seen problems more consistently with shell script blocks: #+begin_src shell-script #+end_src I'll try to produce a recipe that can consistently show this problem. AndyM
Re: [O] Bug: source code editing using C-c ' (org-edit-special) eats characters
On Thu 25 Oct 2012, Bastien wrote: Hi Hsiu-Khuern, Hsiu-Khuern Tang tan...@gmail.com writes: Sorry if this has been reported -- a brief search didn't turn up anything. this is now fixed -- thanks for reporting this! Best, Has this been pushed to org in emacs trunk ? I'm seeing a similar problem in emacs trunk (r110821) where C-c ' in the *Org Src* buffer closes the source edit window and discards the entire contents of the source block. Should I raise an emacs bug for this ? AndyM
Re: [O] do it today, or well, tomorrow
On Wed 12 Oct 2011, John Wiegley wrote: Andrea Crotti andrea.crott...@gmail.com writes: On 10/12/2011 03:54 PM, Dave Abrahams wrote: Binding `org-agenda-date-later' to a key like `f' ought to work out for you. 'f' is already bound to next-week, and it's also quite useful. I bind M-n/p to next/perv-week/day/etc. I fervently hope this an unfortunate typo. A whole week ? :-) AndyM
Re: [O] Compile warnings on Win7/Emacs24.0.50
On Wed 13 Jul 2011, Achim Gratz wrote: I've tested some things on Win7 and happen to have an Emacs24 installed there, so I compiled the latest org-mode. I got quite a few warnings that I've never seen before with Emacs23, so I assume this is Emacs24 tightening the screws on some loseness. I don't remember the exact warning text, but it was something about top-level forms and global variables not having a prefix (presumably to keep them in their own namespace and not step on the toes of other packages). AFAIK this is because emacs-24 now supports lexical scope. The use of name prefixes is used to manage namespace as you mention, but also as convention used by the byte compiler to help distinguish between uses of lexically and dynamicly scoped variable bindings. See the emacs-24 elisp manual for more details, or ask the friednly folks on the on the emacs devel list. HTH AndyM
