Glenn Morris writes:
>>> Debugger entered--Lisp error: (void-variable outline-regexp)
>>> outline-mode()
>>> org-mode()
>>
>> This seems like an org-mode bug. Perhaps it needs to require
>> outline-mode?
>
> It does, so it is very hard to see how this error could occur.
Perhaps something ha
Glenn Morris writes:
> Sebastien Vauban wrote:
>
>> Emacs 24.3.91.1 (of 2014-05-12) regularly hangs with Org-mode version
>> 8.2.6 (release_8.2.6-1010-g1ca86f).
>
> Well I guess this is an Org bug, which will get more attention on the
> Org list.
>
> (See eg http://debbugs.gnu.org/cgi/bugreport.c
Lars Ingebrigtsen writes:
> Glenn Morris writes:
>
>> Sebastien Vauban wrote:
>>
>>> Emacs 24.3.91.1 (of 2014-05-12) regularly hangs with Org-mode version
>>> 8.2.6 (release_8.2.6-1010-g1ca86f).
>>
>> Well I guess this is an Org bug, which will g
Eli Zaretskii writes:
> No, sorry. I really need to reproduce this on my machine and run
> Emacs under a debugger to see what happens and why.
>
> Please try to come up with a recipe starting from "emacs -Q". It is
> OK to include customizations and loading of optional packages, but
> please tr
Eli Zaretskii writes:
>> From: Glenn Morris
>> Cc: Sebastien Vauban , 18...@debbugs.gnu.org
>> Date: Wed, 26 Nov 2014 11:53:03 -0500
>>
>> Eli Zaretskii wrote:
>>
>> >> "sp-show--pair-function" (0x88f14c)
>> [...]
>> > Maybe. This backtrace looks very different from the last one.
>>
>> It i
Eli Zaretskii writes:
>> From: Sebastien Vauban
>> Cc: 17...@debbugs.gnu.org
>> Date: Sat, 31 May 2014 11:52:19 +0200
>>
>> > Also, typing "finish" repeatedly should reveal in which function is
>> > Emacs looping.
>>
>> --8<---cut here---start->8---
>> (gdb)
Lennart Borgman writes:
> Shift-select in cua-mode does not work in org-mode although
> org-replace-disputed-keys is t, org-disputed-keys are set for shift
> arrow keys and org-support-shift-select is always
Is this problem still present in Emacs 24.3?
--
(domestic pets only, the antidote for
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
John Wiegley writes:
> So far, all of these arguments against a tighter development integration with
> ELPA have been predicated on the way that ELPA is used today. ELPA is under
> our control; we can adjust our process to suit the needs of Emacs development.
Yes, but external packages lose much
David Engster writes:
>> (Except perhaps CEDET. There seems to be a lot of merging problems
>> there.)
>
> This is precisely why we're currently moving all development to Emacs
> and abandon the external repo. At least we were planning to...
Oh, great. One less thing that would be helped by mo
Stephen Leake writes:
>> 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
>
Aaron Ecay writes:
> If ELPA made available (on the server for downloading, and in the
> client for installing) old versions of packages, then users could
> always be offered the latest compatible version, but not later
> incompatible ones.
I don't think having Emacs developers fixing bugs in a
John Wiegley writes:
> In fact, what we're doing feels like if Python included Django in its main
> repository, just to solve Django's problems of compatibility, testing, and
> making its bugs known to the main Python developers.
I guess that would be a fair comparison.
If Django had traditiona
John Wiegley writes:
> OK, to continue the analogy, what is the right answer? Technically it
> doesn't seem as though Django belongs there, even if culturally it
> sounds hard to separate. Should it stay indefinitely, or should the
> development model change?
If somebody genuinely offered to tak
Ihor Radchenko writes:
> The code above always skips a bibtex entry starting at bob.
> Hence, the provided example bibliography is parsed as empty, which is
> not expected by Org.
This should now be fixed on the trunk.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: h
Boruch Baum writes:
> When POINT is on the first column of an org-heading, org-mode makes
> available a set of 'speed-commands'. One of those commands is a
> keybinding cheatsheet, M-x org-speed-command-help, bound to '?'.
> However, that cheatsheet only maps keybindings to function names, so it
Lars Ingebrigtsen writes:
> The Subject here says "code included", but no code was included here.
> Di you forget to attach it?
Sorry, the code was in a different bug report, 43955. I've now merged
the two.
--
(domestic pets only, the antidote for overdose, milk.)
"numbch...@gmail.com" writes:
> The commit "e1f09607e0" caused this problem. I confirmed by git
> checkout a commit before it. And re-eval source code, then the problem
> is gone. This is because the commit added
> ~image-converter-file-name-extensions~ in image-convert.el library
> which include
"numbch...@gmail.com" writes:
> Thanks Lars. I will wait for new update in Emacs source code, then re-compile
> Emacs.
The fix has been pushed already. :-)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Malcolm Purvis writes:
> Error: error ("Eager macro-expansion failure: (void-function
> byte-compile-warn-obsolete)") debug-early-backtrace()
> debug-early(error (error "Eager macro-expansion failure:
> (void-function byte-compile-warn-obsolete)")) error("Eager
This should now be f
Ihor Radchenko writes:
> Lars Ingebrigtsen writes:
>
>> The bug on the Emacs side was fixed by Augusto's patch, I think, but
>> there's a remaining problem in ob-python, so I'm reassigning this bug
>> report to org-mode.
>
> Could you please ela
"gbio...@gmail.com" writes:
> Executing the command "xdg-open /path/to/file.pdf" in a terminal
> (Konsole) works.
>
> Executing the same command in Emacs via eshell DOES NOT WORK.
What happens if you execute that command in Emacs via eshell?
--
(domestic pets only, the antidote for overdose, m
"gbio...@gmail.com" writes:
> The same as using C-c C-e l o
> "The default PDF program (okular) appears to open (i see the icon, but not
> the window) and closes without showing anything."
If I do
$ xdg-open ./doc/lispintro/cons-2.pdf
after `M-x shell', "Document Viewer" is opened as normal.
"gbio...@gmail.com" writes:
>> Yeah, calling xdg-open (and expecting it not to exit) is a known
>> problem, but here it seems that xdg-open doesn't even work from *shell*,
>> which is very odd.
>
> More info:
>
> As per bug 25234, using 'M-! xdg-open /tmp/test.pdf', 'M-& xdg-open
> /tmp/test.pdf'
Geraldo Biotti writes:
> I get the same results reported in bug 25234. 'M-! xdg-open /tmp/test.pdf'
> works
> fine. I apologise for my english but it's not my mother language.
So:
This works:
M-! xdg-open /tmp/test.pdf RET
This doesn't work:
M-& xdg-open /tmp/test.pdf RET
This doesn't work:
Eli Zaretskii writes:
>> This doesn't work:
>> M-x shell RET xdg-open /tmp/test.pdf RET
>
> How about asking the xdg-open developers to help us figure out the
> reason? Or, failing that, debug xdg-open in the problematic
> situations to find out what fails there and why? E.g., could it be
> tha
Eli Zaretskii writes:
> And I still don't understand why some people (like Lars) cannot
> reproduce the problem at all -- the issue sounds like something that
> should fail deterministically on any GNU/Linux system. What am I
> missing?
The recipe said to start with `M-x shell' -- I wasn't able
Bastien writes:
> Taylor Sutton writes:
>
>> I can fix it.
>
> It looks like your understanding of the problems is enough to propose
> a patch -- would you like to propose one?
(I'm going through old bug reports.)
This was six years ago, and I had a glance at org-mobile.el, and it
seems like t
"Drew Adams" writes:
> IIUC, `org-open-file' and its associated code, such as `org-file-apps',
> `org-default-apps', and `org-apps-regexp-alist', have nothing
> particularly to do with Org mode. They constitute general-purpose code
> for opening files using associated programs. Code that uses t
daniela-s...@gmx.it writes:
> So now the maintainer starts telling users that they are rare cases
> for being confused. How can any woman stand this guy!!! Impossible.
I'm closing this bug report. If there's anything more to be done here,
please report the bug to the Org maintainers.
--
(dome
Maxim Nikulin writes:
> I am attaching a patch similar to proposed to Org mode that should
> help to avoid obscure failures of viewers due to unnecessary terminal
> sessions.
Thanks; makes sense to me (and seems to fix these persistent issues with
xgd-open etc), so I've applied it to Emacs 28.
Maxim Nikulin writes:
> Thanks for looking into this issue. Please, consider the following
> additional change:
Thanks; applied to Emacs 28.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Yuchen Pei writes:
>> This bug seems to be still around, as it just happened to me. Steps
>> to
>> reproduce:
>>
>> - Build a recent version e.g. commit efaed29f3d with `make`
>> - ./src/emacs
>> - M-x calendar RET
>> - i
>>
>> results in "command-execute: Wrong type argument: commandp,
>> org-ag
33 matches
Mail list logo
