Re: [O] [Geiser-users] bug#33403: Data length limit in Guile/Geiser/Scheme evaluation
A few more notes: I wrote earlier: > However, before doing this, some warnings are in order: > > When in noncanonical mode, the normal processing of ERASE (usually DEL > or Ctrl-H) and KILL (usually Ctrl-U) characters are disabled, Also the handling of Ctrl-D appears to be disabled in noncanonical mode on my system, although this wasn't clear to me from the docs. > At least in the case of the Guile REPL, one notable side effect of > running in noncanonical mode is that when a list is entered at the REPL, > the 'read' returns as soon as the final close parenthesis is entered. > Nothing after that is read, not even the usual newline. There's an additional wrinkle here: after 'read' returns, Guile tries to read optional whitespace followed by a newline, but only if it's immediately available. See 'flush-to-newline' at the end of module/system/repl/repl.scm in Guile. So, unfortunately there's a race condition here, but typically if you send the newline immediately after the final character of input, it is likely that the newline will be consumed by the REPL reader and not by the code that is subsequently run. Finally, I should note that I consider this race condition suboptimal, and will likely change how Guile behaves in the future, so please don't rely on the behavior I have described above. I will likely change Guile's REPL reader to wait for the final newline in all cases. Mark
Re: [O] [Geiser-users] bug#33403: Data length limit in Guile/Geiser/Scheme evaluation
Hello all, "Jose A. Ortega Ruiz" writes: > On Fri, Nov 16 2018, Neil Jerram wrote: > >> Neil Jerram writes: >> >>> Mark H Weaver writes: >>> This is a documented limitation in Linux's terminal handling when in canonical mode. See the termios(3) man page, which includes this text: Canonical and noncanonical mode The setting of the ICANON canon flag in c_lflag determines whether the terminal is operating in canonical mode (ICANON set) or noncanonical mode (ICANON unset). By default, ICANON is set. >>> [...] * The maximum line length is 4096 chars (including the terminating newline character); lines longer than 4096 chars are truncated. After 4095 characters, input processing (e.g., ISIG and ECHO* processing) continues, but any input data after 4095 characters up to (but not including) any terminating newline is discarded. This ensures that the terminal can always receive more input until at least one line can be read. Note that last item above. >>> >>> Awesome; thank you Mark. >>> >>> So possibly this limit can be removed, in my Org/Geiser context, by >>> evaluating (system* "stty" "-icanon") when initializing the Geiser-Guile >>> connection. I'll try that. Will the terminal that that 'stty' sees be >>> the same as Guile's stdin? >>> >>> Jao, if that works, I wonder if it should be the default for Geiser? It >>> appears to me that Geiser shouldn't ever need the features of canonical >>> mode. Is that right? >>> >>> Anyway, I'll see first if the stty call is effective. >> >> Yes, with this in my ~/.guile-geiser - >> >> (system* "stty" "-icanon") >> >> - I can do evaluations past the 4K line length limit, and the Org-driven >> problem that I first reported [1] has disappeared. > > Ah, system* is a scheme call! So yeah, maybe we could add that call to > Geiser's guile initialization... i don't really see how that would cause > any problem elsewhere. I think something like this should be done, not only in the Guile initialization, but ideally in the generic Geiser code that connects to inferior processes via pseudo-tty. After the pseudo-tty is allocated but before launching the inferior Scheme process, something like "stty --file=/dev/pts/N -icanon" should be run. However, before doing this, some warnings are in order: When in noncanonical mode, the normal processing of ERASE (usually DEL or Ctrl-H) and KILL (usually Ctrl-U) characters are disabled, and input characters are delivered to the subprocess immediately as they are typed, rather than waiting for the newline as normally happens in canonical mode. At least in the case of the Guile REPL, one notable side effect of running in noncanonical mode is that when a list is entered at the REPL, the 'read' returns as soon as the final close parenthesis is entered. Nothing after that is read, not even the usual newline. The final newline is only read if the reader is not yet sure that it has finished reading the token, e.g. if a number or symbol is entered. In those cases, typically any delimiter may be typed to terminate the read, e.g. space. To see this, you can try running Guile from a traditional terminal program (e.g. xterm or GNOME Terminal), and type: (system* "stty" "-icanon") and then: (display "hello") You will see that as soon as you type that close paren, "hello" is immediately printed, followed by another REPL prompt, all on the same line. You might also try (use-modules (ice-9 rdelim)) and then: (read-line) and you'll see that the newline you type at the end of that line is read by 'read-line', which then immediately returns the empty string. The input that you wish for 'read-line' to see must be typed on the same line, immediately after the close parenthesis. So, it might be that Geiser needs to be adjusted somewhat to deal with these differences. Finally, you might consider the possibility that 'stty' might not be available in PATH, or fails for some reason, and ideally this case should be handled as well. It might be simpler to always use REPL servers over a socket, than to deal with these headaches, although I don't know if that will be an option for the other Scheme implementations. Regards, Mark
Re: [O] [Geiser-users] bug#33403: Data length limit in Guile/Geiser/Scheme evaluation
On Fri, Nov 16 2018, Neil Jerram wrote: > Neil Jerram writes: > >> Mark H Weaver writes: >> >>> This is a documented limitation in Linux's terminal handling when in >>> canonical mode. See the termios(3) man page, which includes this text: >>> >>>Canonical and noncanonical mode >>> >>>The setting of the ICANON canon flag in c_lflag determines >>>whether the terminal is operating in canonical mode (ICANON set) >>>or noncanonical mode (ICANON unset). By default, ICANON is set. >> [...] >>>* The maximum line length is 4096 chars (including the >>> terminating newline character); lines longer than 4096 chars >>> are truncated. After 4095 characters, input processing (e.g., >>> ISIG and ECHO* processing) continues, but any input data after >>> 4095 characters up to (but not including) any terminating >>> newline is discarded. This ensures that the terminal can >>> always receive more input until at least one line can be read. >>> >>> Note that last item above. >> >> Awesome; thank you Mark. >> >> So possibly this limit can be removed, in my Org/Geiser context, by >> evaluating (system* "stty" "-icanon") when initializing the Geiser-Guile >> connection. I'll try that. Will the terminal that that 'stty' sees be >> the same as Guile's stdin? >> >> Jao, if that works, I wonder if it should be the default for Geiser? It >> appears to me that Geiser shouldn't ever need the features of canonical >> mode. Is that right? >> >> Anyway, I'll see first if the stty call is effective. > > Yes, with this in my ~/.guile-geiser - > > (system* "stty" "-icanon") > > - I can do evaluations past the 4K line length limit, and the Org-driven > problem that I first reported [1] has disappeared. Ah, system* is a scheme call! So yeah, maybe we could add that call to Geiser's guile initialization... i don't really see how that would cause any problem elsewhere. > Thanks to Nicolas, Jao and Mark for your help in understanding this. And thanks to Nicolas, Mark and you for yours :) Cheers, jao -- The vast majority of human beings dislike and even dread all notions with which they are not familiar. Hence it comes about that at their first appearance innovators have always been derided as fools and madmen. -Aldous Huxley, novelist (1894-1963)
Re: [O] Bug: org-mode - "Wrong type argument: number-or-marker-p, nil" [9.1.14 (9.1.14-1-g4931fc-elpaplus @ /home/emilio/.emacs.d/elpa/org-plus-contrib-20180910/)]
Hello, Emilio Francesquini writes: > Consider the following snippet of org > > - First item. I'm just writing something longer so that the minimum > number of characters is reached. > > Anywhere on the second line, calls to org-list-struct fail with the > error: "Wrong type argument: number-or-marker-p, nil". This is not a bug. The function `org-list-struct' has to be called on an item, not anywhere within an item. BTW, it is an internal function. You may want to use `org-element-at-point' instead. Regards, -- Nicolas Goaziou
Re: [O] [Feature Request] Add an dispatcher command (keybinding) for inserting dynamic blocks
On 16/11/2018 02:15, stardiviner wrote:
In package `orgtbl-aggregate` has bellowing command to insert different dynamic blocks.
#+begin_src emacs-lisp
(defun org-insert-dblock ()
"Inserts an org table dynamic block.
This is a dispatching function which prompts for the type
of dynamic block to insert. It dispatches to functions
which names matches the pattern `org-insert-dblock:*'"
(interactive)
(let ((fun
(intern
(format
"org-insert-dblock:%s"
(org-icompleting-read
"Kind of dynamic block: "
(mapcar (lambda (x)
(replace-regexp-in-string
"^org-insert-dblock:"
""
(symbol-name x)))
(apropos-internal "^org-insert-dblock:")))
(if (functionp fun)
(funcall fun)
(message "No such dynamic block: %s" fun
#+end_src
This command matches Org Mode API style.
I hope Org Mode can have this built-in. Because there are some other dynamic blocks. They can use this dispatcher function.
For example org-gantt dynamic block, I write a function manually:
#+begin_src emacs-lisp
(defun org-insert-dblock:org-gantt ()
"Insert org-gantt dynamic block."
(interactive)
(org-create-dblock
(list :name "org-gantt"
:file "data/images/project-gantt-chart.png"
:imagemagick t
:tikz-options "scale=1.5, every node/.style={scale=1.5}"
:weekend-style "{draw=blue!10, line width=1pt}"
:workday-style "{draw=blue!5, line width=.75pt}"
:show-progress 'if-value
:progress-source 'cookie-clocksum
:no-date-headlines 'inactive
:parameters "y unit title=.7cm, y unit chart=.9cm"
:tags-group-style '(("test"."group label font=\\color{blue}")
("toast"."group label font=\\color{green}"))
:tags-bar-style '(("test"."bar label font=\\color{blue}")
("toast"."bar label font=\\color{green}")
#+end_src
+1
Org defines C-c C-x i as org-insert-columns-dblock.
Instead, it could call the org-insert-dblock dispatcher
shown here. The original org-insert-columns-dblock
would be one among other dblock inserters.
Possible dblocks:
org-insert-columns-dblock
org-clock-report
propview
invoice
org-insert-dblock:aggregate
org-insert-dblock:join
org-insert-dblock:transpose
Any future dblock inserter would be taken into account by the
dispatcher just by providing an autoloadable org-insert-dblock:something
function.
Re: [O] LaTeX chunk makes .org file not in Org mode
On Friday, 16 Nov 2018 at 13:28, alain.coch...@unistra.fr wrote: > > > %%% Local Variables: > > > %%% mode: latex > > > %%% TeX-master: t > > > %%% End: > But it is certainly not obvious to me why the content of this chunk > takes precedence over the file extension -- after all, the manual > says: "Files with the ‘.org’ extension use Org mode by default." Because local variables are set after the initial loading of the file. When the file is opened, the mode is initially determined by the autoload settings but then local variables allow you to change this as file extensions may not always reflect what you want. -- Eric S Fraga via Emacs 27.0.50, Org release_9.1.13-894-gf79545
[O] Setting timestamp from end time and an interval
Hello, I find myself often working intervals “backwards”, eg. when planning transportation: I need to be there at XX:YY, thus need to depart 35min before. Org-mode has this great feature that when typing `11:12+00:35` it automatically computes the interval 11:12-11:47. What I'm wondering is, whether there'd be interest in having eg. `11:47+-00:35`, that'd create the same interval but from an *end* time and interval duration. What do you think about this? Is there already a way of doing this I don't know of? Cheers, Leo
Re: [O] LaTeX chunk makes .org file not in Org mode
Eric S Fraga writes on Fri 16 Nov 2018 09:27: > On Wednesday, 14 Nov 2018 at 12:54, alain.coch...@unistra.fr wrote: > > Hello. I guess this is normal, but I wanted to report it in case > > there is room for improvement: > > > > After inserting a latex file into an .org file, I ended up with the > > following part in the org file (which was an agenda file): > > > > %%% Local Variables: > > %%% mode: latex > > %%% TeX-master: t > > %%% End: > > [...] > > > It the issue could somehow be made apparent to the user right away > > (that is, when the chunk is inserted), it would be easier/faster to > > fix. > > There's really nothing to fix. You've inserted some local variable > settings that take effect next time you visit the file. You've decided > (not on purpose, I realize) that you want this file to be opened in > LaTeX mode and Emacs does what you said. I cannot imagine a fix that > could catch this as it would require org to essentially parse the new > contents as if it were all of Emacs and then somehow figure out what had > been set that shouldn't have been set. Hi Eric, and thanks a lot for the feedback. By 'fix', I of course meant 'fix my own mistake'... I forgive myself here, though, because I have been using LaTeX for many years without having to pay any attention to this kind of chunks, which are (for me) inserted automatically. But it is certainly not obvious to me why the content of this chunk takes precedence over the file extension -- after all, the manual says: "Files with the ‘.org’ extension use Org mode by default." I can certainly understand if the content cannot be examined after each insertion, but, as there are many things in Org which are done on the fly, I felt compelled to ask. (One could also imagine that Org would detect upon loading the file that there is a conflict between the modes -- but I also understand if this is not something reasonable to ask.) Regards, a. -- EOST (École et Observatoire des Sciences de la Terre) IPG (Institut de Physique du Globe) | alain.coch...@unistra.fr 5 rue René Descartes [bureau 106] | Phone: +33 (0)3 68 85 50 44 F-67084 Strasbourg Cedex, France| Fax: +33 (0)3 68 85 01 25
Re: [O] bug#33403: [Geiser-users] Data length limit in Guile/Geiser/Scheme evaluation
Neil Jerram writes: > Mark H Weaver writes: > >> This is a documented limitation in Linux's terminal handling when in >> canonical mode. See the termios(3) man page, which includes this text: >> >>Canonical and noncanonical mode >> >>The setting of the ICANON canon flag in c_lflag determines >>whether the terminal is operating in canonical mode (ICANON set) >>or noncanonical mode (ICANON unset). By default, ICANON is set. > [...] >>* The maximum line length is 4096 chars (including the >> terminating newline character); lines longer than 4096 chars >> are truncated. After 4095 characters, input processing (e.g., >> ISIG and ECHO* processing) continues, but any input data after >> 4095 characters up to (but not including) any terminating >> newline is discarded. This ensures that the terminal can >> always receive more input until at least one line can be read. >> >> Note that last item above. > > Awesome; thank you Mark. > > So possibly this limit can be removed, in my Org/Geiser context, by > evaluating (system* "stty" "-icanon") when initializing the Geiser-Guile > connection. I'll try that. Will the terminal that that 'stty' sees be > the same as Guile's stdin? > > Jao, if that works, I wonder if it should be the default for Geiser? It > appears to me that Geiser shouldn't ever need the features of canonical > mode. Is that right? > > Anyway, I'll see first if the stty call is effective. Yes, with this in my ~/.guile-geiser - (system* "stty" "-icanon") - I can do evaluations past the 4K line length limit, and the Org-driven problem that I first reported [1] has disappeared. Thanks to Nicolas, Jao and Mark for your help in understanding this. Neil [1] https://lists.gnu.org/archive/html/emacs-orgmode/2018-11/msg00177.html
Re: [O] [Geiser-users] Data length limit in Guile/Geiser/Scheme evaluation
On Thu, Nov 15 2018, Neil Jerram wrote: > "Jose A. Ortega Ruiz" writes: > >> I cannot see what it is, but there's something in that expression that >> makes scheme readers hang. I just pasted it in a vanilla guile repl >> (started with run-scheme, no geiser involved), and it never gets >> evaluated. The same thing happens with a MIT scheme vanilla repl. And >> the same thing happens if i try to evaluate it in a guile repl in a >> terminal, so it's not even emacs fault. Maybe there's some non-ascii >> char in there? In fact, the scheme readers hang somewhere in the middle >> of the let, because i can remove characters from the end and they never >> discover that the expression is unbalanced > > Thanks Jao; the plot thickens... > > The line length is quite close to 4K; I wonder if that could be > relevant? Hmm, I'd be a bit surprised if both Guile and MIT had that same (or similar) limitation, or if it were inherited somehow from Emacs' comint mode, but it's happening also in a terminal... > > Anyway, I will also check for odd characters... > > Neil > -- One reason that life is complex is that it has a real part and an imaginary part. -Andrew Koenig
Re: [O] [Geiser-users] Data length limit in Guile/Geiser/Scheme evaluation
Hi,
On Thu, Nov 15 2018, Neil Jerram wrote:
> Nicolas Goaziou writes:
>
>> Hello,
>>
>> Neil Jerram writes:
>>
>>> If I add one more (duplicate) row to the table, and hit C-c C-c again,
>>> the evaluation hangs somewhere and Emacs is blocked until I interrupt
>>> with C-g.
>>
>> Interesting.
>>
>>> Has anyone else seen this?
>>
>> I can reproduce this bug on master branch.
>
> Many thanks for trying and confirming this, Nicolas.
>
>> However, I would ask Geiser developer first, because the process freezes
>> during `geiser-eval-region' call, and the contents of the buffer, pasted
>> below, seem correct.
I cannot see what it is, but there's something in that expression that
makes scheme readers hang. I just pasted it in a vanilla guile repl
(started with run-scheme, no geiser involved), and it never gets
evaluated. The same thing happens with a MIT scheme vanilla repl. And
the same thing happens if i try to evaluate it in a guile repl in a
terminal, so it's not even emacs fault. Maybe there's some non-ascii
char in there? In fact, the scheme readers hang somewhere in the middle
of the let, because i can remove characters from the end and they never
discover that the expression is unbalanced
jao
>>
>> --8<---cut here---start->8---
>> ;; -*- geiser-scheme-implementation: guile -*-
>> (let ((classification (quote (("A" "Aood") ("AA" "Aood")
>> ("AA A" "Aood") (" AAA AA" "Aood") ("A "
>> "Aood") ("AAA AAA" "Aood") ("AAA " "Aood") ("AAA Aithdrawal"
>> "Aash") ("AAA.AAA.AA" "Aravel") (" A" "AAAard") ("AAAard"
>> "Aobot") (" " "Ainging") ("A" "Aood") ("AA" "Aood")
>> (" AA" "Aetrol") ("Aetrol" "Aravel") ("A AAA" "Aaircut")
>> ("Aaircut" "Aersonal care") ("Aank credit A AAA AA AAA" "Ancome")
>> ("Anterest added" "Ancome") ("AA " "Aobot") ("Ao Aouth Aoast Aoole
>> AA" "Aravel") (" AA" "Aravel") ("'A
>> AAA AAA" "Aoncert") ("AA & " "Aersonal care") (""
>> "Aood") ("AAA AA" "Aood") ("A credit A+A AAA AA AA AAA"
>> "Ancome") ("A A" "Aetrol") ("A AAA" "Aetrol") ("A A"
>> "Ausic lessons") ("AAA" "Ainging") ("AA AAA AAA" "AA licence") ("AA
>> licence" "Atilities") ("" "Arance funding") ("AAA AA"
>> "Aravel") ("AAA " "Aub") ("A A AA AAA AA" "Aennis
>> with cousin") ("A AAA" "Aood") ("AA AAA" "Aetrol") ("AA
>> AA" "Atilities") ("AAA A" "Aub") (" A AA" "Aood")
>> ("" "Atilities") ("AA AA " "Anvestment for cousin")
>> ("AA" "Aravel") ("Ahe Aike Aarista" "Aood") ("A AA
>> A" "Atilities") ("A.AA" "Atilities") ("A AAA" "Aouncil
>> tax") ("AA- AAA" "Aetrol") ("A AAA A"
>> "Aetrol") ("AAA AAA AA" "Aub") ("AA AA" "Aharity") ("AAA"
>> "Aharity") ("-AA51AAA" "Aar tax") ("071660 50225530" "Aransfer from
>> savings a/c") ("AAA" "Aegal fees") ("AAA.AAA" "Anline content")
>> ("Aon-Aterling transaction fee" "Anline content") (" AA"
>> "Aatteries") ("AA" "Aighgate cleaning") (81 "Aegal
>> fees") ("A AA40340807A A AAA" "Aetrol") ("AA AAA A"
>> "Aood") ("AAA..AAA" "Ainema") (" A AAA" "Aegal
>> fees") ("A " "Ausic lessons") ("A AA " "Aetrol")
>> (" A" "Aood") ("AAA AA AAA" "Aub") ("Aank credit A AAA
>> AA-AAA" "Ancome") ("AAA " "Aurling (reimbursable)") ("Aank credit A
>> Aerram" "Aransfer to/from other a/c") ("A AA" "Aood") ("Aheque
>> deposit" "Ancome") ("AAA" "Aood") ("AAA AAA AA AAA" "Aegal fees")
>> ("A AA & A A AAA" "Aransfer to/from other a/c") ("AAA A A"
>> "Aub") ("Aredit" "Ancome") ("A AAA" "Aood") ("A AA" "Achool
>> fees") ("AAA AAA AAA" "Aood") (" " "Aood") ("AAA Atore"
>> "Aeycutting") (" A A" "Ainging") ("A AA" "Ausic lessons")
>> ("A " "Ausic lessons") ("A AA" "Aood") ("A'A"
>> "Aood") ("A A AA AAA" "Aarking") ("" "Aardware")
>> ("AAA 374" "Aetrol") ("AA " "Aub") ("AA * A"
>> "Aood") ("AAA*" "Aharity") ("A AA" "Aood") ("Aheque deposit"
>> "Ancome") ("AAA" "Aood") ("AAA AAA AA AAA" "Aegal fees") ("A AA
>> & A A AAA" "Aransfer to/from other a/c") ("AAA A A" "Aub") ("Aredit"
>> "Ancome") ("A AAA" "Aood") ("A AA" "Achool fees") ("AAA AAA
>> AAA" "Aood") (" " "Aood") ("AAA Atore" "Aeycutting") ("
>> A A" "Ainging") ("A AA" "Ausic lessons") ("A "
>> "Ausic lessons") ("A AA" "Aood") ("A'A" "Aood") ("A A AA
>> AAA" "Aarking")
[O] Bug: org-mode - "Wrong type argument: number-or-marker-p, nil" [9.1.14 (9.1.14-1-g4931fc-elpaplus @ /home/emilio/.emacs.d/elpa/org-plus-contrib-20180910/)]
Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See https://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org mailing list. Consider the following snippet of org - First item. I'm just writing something longer so that the minimum number of characters is reached. Anywhere on the second line, calls to org-list-struct fail with the error: "Wrong type argument: number-or-marker-p, nil". The following numerical comparison fails in org-list-struct because itm-lst-s is nil: (when (<= ind (nth 1 (car itm-lst-2))) (push (cons ind (point)) end-lst-2)) I stumbled upon this because it essentially renders package guess-language unsusable in most of my org files. Related bug: https://github.com/tmalsburg/guess-language.el/issues/20 Emacs : GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.30) of 2018-09-11 Package: Org mode version 9.1.14 (9.1.14-1-g4931fc-elpaplus @ /home/emilio/.emacs.d/elpa/org-plus-contrib-20180910/)
Re: [O] LaTeX chunk makes .org file not in Org mode
On Wednesday, 14 Nov 2018 at 12:54, alain.coch...@unistra.fr wrote: > Hello. I guess this is normal, but I wanted to report it in case > there is room for improvement: > > After inserting a latex file into an .org file, I ended up with the > following part in the org file (which was an agenda file): > > %%% Local Variables: > %%% mode: latex > %%% TeX-master: t > %%% End: [...] > It the issue could somehow be made apparent to the user right away > (that is, when the chunk is inserted), it would be easier/faster to > fix. There's really nothing to fix. You've inserted some local variable settings that take effect next time you visit the file. You've decided (not on purpose, I realize) that you want this file to be opened in LaTeX mode and Emacs does what you said. I cannot imagine a fix that could catch this as it would require org to essentially parse the new contents as if it were all of Emacs and then somehow figure out what had been set that shouldn't have been set. -- Eric S Fraga via Emacs 27.0.50, Org release_9.1.13-894-gf79545
