bug#35419: [O] [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter)
Hi! Some late clarifications about mmm-mode. On 26.04.2019 00:00, Dmitrii Korobeinikov wrote: > A lot of the functionality of MMM Mode---that which makes the major mode > appear to change---is implemented by saving and restoring the values of > local variables, or pseudo-variables. What I don't understand is where the modes of the submode region run and when they are turned on. They are run in an empty temporary buffer, see mmm-update-mode-info. That is true for all the "submodes" in a buffer. The primary major mode is run in the context of that buffer (IIRC). After any of them runs, the code responsible for it collects the values of a certain number of known variables and associates that map with the major mode (this is a bit of a simplification). Are necessary modes just allowed to run at the right time for the whole buffer? When you move between the "chunks", no major mode functions are called. Instead, the values of variables are swapped in. Including the value of the 'major-mode' variable. But then, how are they limited in their effect to just the necessary region? Narrowing? Usually, yes. Especially when we're talking about font-lock and syntax-propertize-function. See mmm-fontify-region-list for an example. Could, for example, syntax checking be done efficiently that way? That depends on the combination of modes and how they are used (either they can be nested, like in web templates, or it's a flat list where chunks are largely independent like in Jupyter). But in most cases, I think, you could pick a good strategy. There are no universal ones, though.
Re: [O] Using CEDET modules from Emacs core
On 12.02.2017 05:33, Stefan Monnier wrote: We don't have enough infrastructure support in general for "advanced" editing functionality such as type/scope-aware completion. So we have various add-on thingies (like company-mode, cedet, and auto-complete) which provide such support for specific modes, but really these should move to core, so that major modes can themselves provide support for such completion. That doesn't always equate to "add semantic-mode support", and in many cases won't be optimal. 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.
Re: [O] Sync up the org in emacs master to org maint branch?
On 02.02.2017 14:10, Lars Ingebrigtsen wrote: If Django had traditionally always been distributed along with Python, and maintained in the Python repo, I'm pretty sure the first versions of Emacs came without Gnus. Later, it got bundled. Some time after that, Org and CEDET joined too. All of that was before we got ELPA and with it, a very easy way for users to install third-party packages. and the suggestion now would be to move Django to a part of the Python repo that very few developers look at, I've never looked at the Gnus source code either, even inside the Emacs repository. but Django would continue to be distributed with Python, and all Django bug reports would continue to go to the Python bug repository, and Python developers would continue to be responsible for QA and bug fixing of Django. You could introduce a separate bug tracker, if that helps.
[O] bug#25132: 26.0.50; emacs hangs when loading org file with python source blocks
On 20.01.2017 03:52, npost...@users.sourceforge.net wrote: My feeling is that inhibit-modification-hooks should usually be buffer local anyway. Maybe you're right. inhibit-read-only, bound nearby, seems to be in the same situation. If we are not, why not make inhibit-modification-hooks always buffer-local instead? It would have to be in addition to, because even after doing (make-variable-buffer-local 'var), (let ((var 'foo))...) still makes a global binding. `make-variable-buffer-local' only has effect for `setq', which I think will hardly ever happen for `inhibit-modification-hooks'. You're right, and that sounds a little too complicated for my taste. So, personally, I'd try to fix the particular instance first. Switching buffers inside with-silent-modifications is not a very common usage, I think. Maybe org-src should itself let-bind the aforementioned variable(s) where it visits other buffers. Up to you, of course, since you've already been given the go-ahead for the proposed fix.
[O] bug#25132: 26.0.50; emacs hangs when loading org file with python source blocks
On 08.01.2017 00:20, npost...@users.sourceforge.net wrote: -(inhibit-modification-hooks t)) +(inhibit-modification-hooks + (progn (make-local-variable 'inhibit-modification-hooks) t))) Are we not worried that inhibit-modificaiton-hooks will become buffer-local even after control flow leaves this let*? If we are not, why not make inhibit-modification-hooks always buffer-local instead?
[O] bug#19606: 24.4; Emacs hangs when editing a 5-line Org file
On 01/15/2015 09:14 PM, Eli Zaretskii wrote: But you didn't even show the backtrace from the main (a.k.a. "Lisp") thread. Your backtrace is from thread 15, whereas the main thread is thread 1. The output is from 'thread apply all backtrace', AFAICS. On the other hand, it's not 'bt full' or `xbacktrace', which report-emacs-bug asks to call.
Re: [O] org-export raises stringp nil error
On 08.03.2013 18:06, Eli Zaretskii wrote: From: Dmitry Gutov Cc: l...@metapensiero.it, joa...@verona.se, emacs-de...@gnu.org, b...@gnu.org, emacs-orgmode@gnu.org, sdl@gmail.com Date: Fri, 08 Mar 2013 15:18:19 +0400 I like the idea of stripping big bundled packages (like org, gnus, cedet, maybe even tramp, if that's possible). That would certainly mean more problems for users to set them up with a particular version of Emacs, because there's no longer a clear way of getting the version of package X that correspond to Emacs version N.M. There won't be such correspondence. And therein lies the problem. AFAIK, all 4 packages I mentioned above maintain backward compatible codebases, so it's not like they depend on the latest Emacs. When I install a package, I usually want its latest *stable* version that is compatible with the Emacs version I run. As great as Well, you're not getting it now. If you're using Emacs 23, you get the old version of Org that was bundled with it, and not some newer one that is still compatible with it (that would be the current stable release, I imagine). compatibility stuff is, I trust testing more, as I need to do something each day that doesn't involve debugging Emacs and my other tools. Easier access to newer versions for users means a bigger testing pool. Yes, the combination of "latest org + latest Emacs" may end up getting tested less, but that might be an acceptable tradeoff. Also, since org-mode or gnus won't update without explicit action from you, working with/on Emacs trunk may become more stable, because it will mean less moving parts. Also think about various package managers for GNU/Linux distros, which need to specify on what version of Emacs package X depends. They already do, at least for some packages: http://packages.ubuntu.com/quantal/gnus http://packages.ubuntu.com/quantal/org-mode
Re: [O] org-export raises stringp nil error
Eli Zaretskii writes: >> From: joa...@verona.se >> Date: Fri, 08 Mar 2013 10:15:07 +0100 >> Cc: b...@gnu.org, l...@metapensiero.it, emacs-orgmode@gnu.org, >> Leo Liu , emacs-de...@gnu.org >> >> - Emacs "trunk" could be stripped of all but the bare essentials to >> achieve bootstrap. >> - distribution tarballs could be made from trunk+elpa. >> >> Since I dont do releases for Emacs I dont get to have an opinion on the >> matter, but if pressed, I would say this idea has considerable merit. > > It also has at least one demerits: people who track the trunk will not > necessarily use the revisions of packages from elpa that will be > included in Emacs tarballs. That will probably mean longer and more > painful pretests, and some of the advantages of having a publicly > accessible development trunk will be lost. On the other hand, people using older-but-still-supported versions of Emacs will be able to help test the new versions of packages in ELPA. Considering the total Emacs userbase is huge, this could be a great benefit, and hey, if a problem in org-mode is found just before Emacs release, it would either be completely org-mode team's problem (if it's not bundled with Emacs), or Emacs could bundle the last stable version without the regression. As long as Org is in the same tree, doing this kind of trick is much harder.
Re: [O] org-export raises stringp nil error
Eli Zaretskii writes: >> From: Dmitry Gutov >> Cc: Eli Zaretskii , b...@gnu.org, l...@metapensiero.it, >> emacs-orgmode@gnu.org, Leo Liu , emacs-de...@gnu.org >> Date: Fri, 08 Mar 2013 13:25:16 +0400 >> >> joa...@verona.se writes: >> > Just a small reminder of the idea Stefan sometimes drops in these >> > discussions: >> > - Emacs "trunk" could be stripped of all but the bare essentials to >> > achieve bootstrap. >> >> I like the idea of stripping big bundled packages (like org, gnus, >> cedet, maybe even tramp, if that's possible). > > That would certainly mean more problems for users to set them up with > a particular version of Emacs, because there's no longer a clear way > of getting the version of package X that correspond to Emacs version > N.M. There won't be such correspondence. AFAIK, all 4 packages I mentioned above maintain backward compatible codebases, so it's not like they depend on the latest Emacs. And if some do, package.el allows to specify the minimal Emacs version in the "Package-Requires" header. It just might use some improvement in the error message when this dependency is not satisfied. So, users of all versions of Emacs would use the same latest stable Gnus, Org and CEDET, as long as the packages maintain backward compatibility. That would create some pressure to upgrade old Emacs versions, though (as long as ELPA repositories only contain the latest versions of packages), but that's not necessarily a bad thing.
Re: [O] org-export raises stringp nil error
joa...@verona.se writes: > Just a small reminder of the idea Stefan sometimes drops in these > discussions: > - Emacs "trunk" could be stripped of all but the bare essentials to > achieve bootstrap. I like the idea of stripping big bundled packages (like org, gnus, cedet, maybe even tramp, if that's possible). > - distribution tarballs could be made from trunk+elpa. > > Since I dont do releases for Emacs I dont get to have an opinion on the > matter, but if pressed, I would say this idea has considerable merit. If distribution tarballs include code from elpa, then I imagine code freeze rules would also apply to elpa branch. So I don't see how this would be an improvement.
