Re: [BUG] Geiser fails to start REPL on Emacs 26
Hi. Thanks for the heads up. I've upped the requirement in Geiser 0.29.1
to Emacs 27.1.
Cheers,
jao
On Sun, Aug 06 2023, Ihor Radchenko wrote:
> Hi,
>
> Our (Org mode) CI is now failing to run ob-scheme tests because Geiser
> fails to run REPL:
>
> https://builds.sr.ht/~bzg/job/1035753
>
> Test test-ob-scheme/tables backtrace:
> (obsolete max-specpdl-size)()
> geiser-syntax--read-from-string("#")
> geiser-guile-update-warning-level()
> geiser-guile--startup(nil)
> apply(geiser-guile--startup nil)
> geiser-impl--call-method(repl-startup guile nil)
> geiser-repl--startup(guile nil)
> geiser-repl--start-repl(guile nil)
> geiser(guile)
> org-babel-scheme-get-repl(guile nil)
>
> This happens because `geiser-syntax--read-from-string' tries to call
> `with-suppressed-warnings', which is only available starting from Emacs
> 27.
>
> Considering that geiser claims supporting Emacs >=25.1, this appears to
> be a bug.
Re: tab at beginning of line does not indent any more
On Mon, Dec 27 2021, Mandar Mitra wrote: > I have org 20210929 installed. > > With emacs -Q and (package-initialize) evaluted in the *scratch* > buffer, I see the following change in behaviour: > > * ABCD > > > > > I'm fairly sure that, before the last upgrade, I used to get > > * ABCD > > > > Have other users observed this? Are you bothered by it? Is this a bug > or a feature? Note I'm running with emacs -Q for the above, but I get > the same behaviour with org-cycle-emulate-tab set to t or white. The > information I found on the net seems to pertain to much older > versions. i was surprised by this (new?) behaviour too. in my case, i "fixed" it with (setq org-adapt-indentation t) if memory serves, i found about this variable in the info manual. hope this helps, jao -- In this world, there are only two tragedies. One is not getting what one wants, and the other is getting it. - Oscar Wilde
Re: [O] [Geiser-users] bug#33403: Data length limit in Guile/Geiser/Scheme evaluation
On Sat, Nov 17 2018, Mark H Weaver wrote: [...] >> 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. I think this is not an actual problem in Geiser. In comint mode, the stdin of the Guile process doesn't receive any input bytes until higher level elisp functions send them, and that's totally under our control. Repeating that experiment in a Geiser REPL, nothing is printed before a RET (and, in fact, we might not even send the RET to Guile). > > 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. Again, a comint/geiser REPL doesn't have this problem. > So, it might be that Geiser needs to be adjusted somewhat to deal with > these differences. Seems we're lucky enough to be already adjusted :) > 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. Yes, that's a real concern. We should at least provide some kind of warning. > 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. Not for all of them. For Guile it's doable, but definitely not "simpler", it requires some work and solving some unrelated corner cases; but it might be worth the effort, because it's a cleaner interaction mode (for instance, behaves much better in the presence of multiple threads). Cheers, jao -- Beware of the stories you read or tell; subtly, at night, beneath the waters of consciousness, they are altering your world. -Ben Okri, poet and novelist
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] [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")
[Orgmode] Re: marking out-links
Carsten Dominik [EMAIL PROTECTED] writes: [...] I you rest the mouse over the link, a tooltip window will show the link. Additional markers in the display text would require hacking the function `org-activate-bracket-links', but I am not in favor of this proposal. If you dont like using the mouse, one could use an idle timer to display the link in the echo area when the cursor is on the link - I have done something like this with RefTeX, on BibTeX references. Well, i run emacs on a terminal most of the time, so tooltips don't work for me. As for echoing, yes, that'd work, but it's somewhat orthogonal to the marking feature, the point of the latter being knowing the kind of one or more links before going there. But it seems i'm the only one finding that useful :), so i guess i'll hack something around org-activate-bracket-links. Thanks for the tip! Cheers, jao -- Sometimes I think we're alone in the universe, and sometimes I think we're not. In either case, the idea is quite staggering. -Arthur C Clarke, writer (1917- ) ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: a small (?) feature request
Leo [EMAIL PROTECTED] writes: On 2008-05-24 22:33 +0100, Jose A. Ortega Ruiz wrote: [...] Is there already a way of doing this? Setting `org-special-ctrl-a/e' to t Yes, exactly what i was looking for. Thanks a lot. jao, who will try to rtfm next time -- Always have a vision. Why spend your life making other people’s dreams? -Orson Welles (1915-1985) ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] a small (?) feature request
Hi, When i'm on a header line that has tags, C-e will bring the cursor, well, to the end of the line, i.e., after the tags. But, most of the time, that's not the 'end' i meant: i want to go to the 'end' of the header text *before* the tags (e.g., to add some text to said header--modifying the tags is much more conveniently done via C-cC-c). Is there already a way of doing this? Cheers, jao ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Problem with agenda file list
Carsten Dominik [EMAIL PROTECTED] writes: On Apr 27, 2008, at 5:17 PM, Eddward DeVilla wrote: [...] Anyhow, I'm pretty sure I only add files with the org-mode menu and I think the key sequence C-]. (The machine I'm on doesn't have org-mode at the moment.) I don't modify the list much though. I can try to stress it if you like. Please do, I think this would be useful. I will switch to this setup myself. I will too. But i think this solution is suboptimal: i already have a .el file to store my org-specific configuration, and this obligues me to split my configuration into two files, the only reason being that i don't want org to overwrite my customisation variables. I'm not privy with the implementation details, but i guess the overwrite is unavoidable when not using the additional file? I'm a bit surprised by this fact: i use dozens of emacs packages, and org is the first one wanting to modify my custom.el; even in cases where customising a variable must trigger some additional side-effect, there's some function one can call in the init file to both set the variable and trigger the additional side-effects. That said, if this is the only workable solution, so be it :) jao -- A student came to the master and asked, for the master was one of them who knew such things: Does Emacs have the Buddha nature? The master contemplated this for some time, and answered: I don't see why not, it has about everything else. ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Problem with agenda file list
Hi Carsten, Carsten Dominik [EMAIL PROTECTED] writes: Hi Jose, in principle it would be possible, of course, to write a custom function that directly modifies a special Org configuration file. However, that is even less clean than what I was doing so far and is bound to cause problems. What if another person does *not* have a special file for Org? Should I then directly manipulate .emacs? I think this is not acceptable. I think we're misunderstanding each other :) What i really want is to just set in my .emacs something along the lines of (setq org-agenda-files '(/home/jao/org/a.org home/jao/org/b.org)) (require 'org-install) and be sure that org won't write any custom-set-variables or custome-set-faces in my custom file. Last time i tried doing that, org-agenda-files appeared automagically in my custom-set-variables section, together with a face definition for font-lock-warning in my custom-set-faces... they were put in my .emacs, but i was using a separate custom-file, so i just set and loaded custom-file before loading org, and then org-agenda-files and font-lock-warning are written by org in my custom-file instead of .emacs. But since i'm setting org-agenda-files in my .emacs, what i'd like is that it wouldn't appear in custom-set-variables. My understanding was that, in order to prevent this behaviour (that is, the automatic modification of custom-set-variables and -faces), my only option was to use the org files list file. Am i confused? Thanks! jao There is of course, a simple solution for you: Set the value of org-agenda-files with a lisp setq form in .emacs, and never use `C-c [' and `C-c ]' to modify the list. If you want to be sure, disable these functions with `disable-command'. ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Problem with agenda file list
Dan Griswold [EMAIL PROTECTED] writes:
Hello all,
I've encountered a strange problem with the org-agenda-files
variable.
When I start up org-mode (which I do from my .emacs) the following
unsavory events happen:
1. org-agenda-files is set to only the first file in the list;
2. custom-set-variables is set to just org-agenda-files (blowing
away all other customizations);
3. custom-set-variables and custom-set-faces are written to .emacs,
even if custom-file is set to a different file name (as in my
setup).
I've encountered problems 2) and 3). The latter can be fixed by loading
custom-file before org, and i had to explicitly set the value of
org-agenda-files in custom-set-variables to get the value i want.
I put all my customizations in separate files and rarely use
custom-set-{variables, faces}. It'd be nice if org offered the option of
*not* writing any customization back (i was specially puzzled by its
overwriting some of my faces, which i manage using color-theme) and be
totally customizable using elisp outside the customize interface. That's
already almost the case: all may other elisp settings for org work
nicely. IMHO, custom-set-{variables, faces} should be modified only
when *explicitly* requested by the user, either by using customize or
manually editing custom-file.
Cheers,
jao
--
When you come to a fork in the road, take it
-Yogi Berra, baseball coach.
___
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Org-mode version 5.17
Hi Carsten, Carsten Dominik [EMAIL PROTECTED] writes: - When the new option `org-refile-use-outline-path' is set, refile targets will be presented like a file path to the completion interface: level 1/level 2/level 3. This may be the fastest interface yet to get to a certain outline entry. Do we need to use this interface in other places? Thanks to Jose Ruiz for this proposal. Thanks again. I've been playing with this new feature and it's really as useful as i imagined. One related idea just occurred to me: i think it'd be nice to be able to specify a non-existent leaf at the prompt, in which case a node with the requested path would be created and the refile would take place (as a child of the new node). Would that be difficult to implement? Cheers, Jose -- Peter Principle: In a hierarchy, every employee tends to rise to his level of incompetence. -Laurence J Peter, educator and author (1919-1990) ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: org-refile
Carsten Dominik [EMAIL PROTECTED] writes: Hi Jose, In 5.17, you will be able to do this: (setq org-refile-use-outline-path t) The refile targets will then be represented by /-separated paths just like you suggested. Thanks. What can I say? Excellent Cannot wait for the new release :) Thanks a lot, Carsten Jose -- In this world, there are only two tragedies. One is not getting what one wants, and the other is getting it. - Oscar Wilde pgpwKpDQkmW1x.pgp Description: PGP signature ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: org-refile
Carsten Dominik [EMAIL PROTECTED] writes: Hi Jose, The idea of using the org-goto interface (which is what org-remember-handler uses for interactive filing), but IIRC Max has pointed out correctly that this interface is way too slow for this task. It is OK for occasional use, and if you are comfortable with it, you can use it during remember to file your note. However, if remember has collected some 10 tasks during a day and you need to go through this interface 10 times in succession, you will immediately get tired of it. Opening another window and doing cut-and-paste from one window to the other would probably be better. I see... yes, I agree with your point here. It might be worth looking into disambiguating (is that a word???) duplicate headlines, or indeed make the hierarchy look like a path or even complete like find-file. Not a bad idea at all. C-c r o Implement way to distinguish identical headlines for org-refile C-c C-c Excellent! If you find the time, my vote goes for the find-file-like interface (one could even choose among different org files that way, with the current one as default). Thanks, and please keep up the awesome job. Jose -- They say when you play a Microsoft CD backwards you can hear satanic messages...but that's nothing, if you play it forward it will install windows! ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] org-refile
Hi. I'm very happy with the new org-refile, but the current way of specifying the target node is, IMHO, not as convenient as it could be. For instance, if i specify levels up to, say, 2 as targets, and have duplicated headlines at said level: * Project A ** Tasks ** Resources * Project B ** Tasks ** Resources the completion shows only the first occurrence of 'Tasks' and 'Resources'. What i do now is giving them different names, but it's a bit artificial: * Project A ** Project A tasks ** Project A resources * Project B ** Project B tasks ** Project B resources For situations like this one, it would help a lot having the option of interactively selecting the target node in the same way as one selects it after invoking org-remember. A second option would be to have completion for all headlines in a hierarchical way, navigating the outline tree at the mini-buffer prompt as if one where navigating a file tree after C-xC-f. Finally, a (quick?) workaround would be to show the target names as 'full-paths', e.g. Project A/Tasks, Project B/Tasks in the first example above. What do you think? Regards, jao P.D. I've looked a bit at org.el to try to implement this myself, but unfortunately my time is right now too short for the amount of code involved :-(. ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
