* bug#13133: 24.2.90; scroll-conservatively is too coarse a setting @ 2012-12-10 3:29 Dmitry Gutov 2012-12-10 6:30 ` Eli Zaretskii 0 siblings, 1 reply; 8+ messages in thread From: Dmitry Gutov @ 2012-12-10 3:29 UTC (permalink / raw) To: 13133 I think this value is used in contexts that are different enough to behave differently in this respect. Examples: 1) I want help-button-action to bring me to the function's definition, and I generally want in the middle of the screen. Same for imenu, etc. 2) I really don't want to see empty space after the contents in the compilation window. But as much as half of the window may be empty right after compilation because of the point recentering. 3) Ideally, if I move around with next/previous-line, I don't want sudden jumps and recenterings. Same thing with beginning/end-of-defun (so setting scroll-conservatively to a value larger than 0 is not a real solution). Thoughts? So far I'm doing this for the compilation buffer: (defun compile-scroll-eob (buffer _status) (let ((win (get-buffer-window buffer)) (current (selected-window))) (when win (select-window win) (with-current-buffer buffer (when (> (line-number-at-pos (point-max)) (window-height)) (goto-char (point-max)) (recenter (window-height)))) (select-window current)))) (add-to-list 'compilation-finish-functions 'compile-scroll-eob) I think that behavior should be the default, though. In GNU Emacs 24.2.90.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.6.0) of 2012-11-26 on vbx Bzr revision: 110959 rgm@gnu.org-20121126014100-0199uq4y2fo0cnaz Windowing system distributor `The X.Org Foundation', version 11.0.11300000 System Description: Ubuntu 12.10 ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#13133: 24.2.90; scroll-conservatively is too coarse a setting 2012-12-10 3:29 bug#13133: 24.2.90; scroll-conservatively is too coarse a setting Dmitry Gutov @ 2012-12-10 6:30 ` Eli Zaretskii 2012-12-10 6:46 ` Dmitry Gutov 0 siblings, 1 reply; 8+ messages in thread From: Eli Zaretskii @ 2012-12-10 6:30 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 13133 > From: Dmitry Gutov <dgutov@yandex.ru> > Date: Mon, 10 Dec 2012 07:29:40 +0400 > > I think this value is used in contexts that are different enough to > behave differently in this respect. > > Examples: > 1) I want help-button-action to bring me to the function's definition, > and I generally want in the middle of the screen. Same for imenu, etc. > 2) I really don't want to see empty space after the contents in the > compilation window. But as much as half of the window may be empty right > after compilation because of the point recentering. > 3) Ideally, if I move around with next/previous-line, I don't want > sudden jumps and recenterings. Same thing with beginning/end-of-defun > (so setting scroll-conservatively to a value larger than 0 is not a real > solution). I'm sorry, but the problem you describing is entirely unclear to me. You didn't say what value, if any, did you set scroll-conservatively to, nor if you have any other scroll-* variables customized to non-default values. If you don't customize anything, Emacs always re-centers when point goes out of sight. When point is re-centered, I don't think you can ever have half-window of empty space, because of the way re-centering works. Given this lack of information, I don't understand how you get the adverse effects in your 3 examples. Please elaborate, perhaps separately about each of the examples. Thanks. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#13133: 24.2.90; scroll-conservatively is too coarse a setting 2012-12-10 6:30 ` Eli Zaretskii @ 2012-12-10 6:46 ` Dmitry Gutov 2012-12-10 7:08 ` Eli Zaretskii 0 siblings, 1 reply; 8+ messages in thread From: Dmitry Gutov @ 2012-12-10 6:46 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 13133 On 10.12.2012 10:30, Eli Zaretskii wrote: >> From: Dmitry Gutov <dgutov@yandex.ru> >> Date: Mon, 10 Dec 2012 07:29:40 +0400 >> >> I think this value is used in contexts that are different enough to >> behave differently in this respect. >> >> Examples: >> 1) I want help-button-action to bring me to the function's definition, >> and I generally want in the middle of the screen. Same for imenu, etc. >> 2) I really don't want to see empty space after the contents in the >> compilation window. But as much as half of the window may be empty right >> after compilation because of the point recentering. >> 3) Ideally, if I move around with next/previous-line, I don't want >> sudden jumps and recenterings. Same thing with beginning/end-of-defun >> (so setting scroll-conservatively to a value larger than 0 is not a real >> solution). > > I'm sorry, but the problem you describing is entirely unclear to me. > You didn't say what value, if any, did you set scroll-conservatively > to, nor if you have any other scroll-* variables customized to > non-default values. If you don't customize anything, Emacs always > re-centers when point goes out of sight. When point is re-centered, I > don't think you can ever have half-window of empty space, because of > the way re-centering works. > > Given this lack of information, I don't understand how you get the > adverse effects in your 3 examples. Please elaborate, perhaps > separately about each of the examples. The problem is getting all 3 to work at the same time. For 1, scroll-conservatively needs to be < 100, something like 0-10, so that recentering usually happens. For 2, I have to set scroll-conservatively to 101. Some lower values may also help, but there's no guarantee, as I understand it: the contents of the compilation buffer are getting added in large chunks. For 3, again, I have to set scroll-conservatively to a large value. For C-n/C-p, the value of 5 is usually enough, for for C-M-e/C-M-a, it often has to be larger than that. Half-window happens because when the compilation buffer is filled, the point is at the end of it (when compilation-scroll-output is t, at least). Of other scroll- variables, I have scroll-preserve-screen-position set to t. Didn't think that matters. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#13133: 24.2.90; scroll-conservatively is too coarse a setting 2012-12-10 6:46 ` Dmitry Gutov @ 2012-12-10 7:08 ` Eli Zaretskii 2012-12-10 8:28 ` Dmitry Gutov 0 siblings, 1 reply; 8+ messages in thread From: Eli Zaretskii @ 2012-12-10 7:08 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 13133 > Date: Mon, 10 Dec 2012 10:46:51 +0400 > From: Dmitry Gutov <dgutov@yandex.ru> > CC: 13133@debbugs.gnu.org > > >> Examples: > >> 1) I want help-button-action to bring me to the function's definition, > >> and I generally want in the middle of the screen. Same for imenu, etc. > >> 2) I really don't want to see empty space after the contents in the > >> compilation window. But as much as half of the window may be empty right > >> after compilation because of the point recentering. > >> 3) Ideally, if I move around with next/previous-line, I don't want > >> sudden jumps and recenterings. Same thing with beginning/end-of-defun > >> (so setting scroll-conservatively to a value larger than 0 is not a real > >> solution). > > > > I'm sorry, but the problem you describing is entirely unclear to me. > > You didn't say what value, if any, did you set scroll-conservatively > > to, nor if you have any other scroll-* variables customized to > > non-default values. If you don't customize anything, Emacs always > > re-centers when point goes out of sight. When point is re-centered, I > > don't think you can ever have half-window of empty space, because of > > the way re-centering works. > > > > Given this lack of information, I don't understand how you get the > > adverse effects in your 3 examples. Please elaborate, perhaps > > separately about each of the examples. > > The problem is getting all 3 to work at the same time. > > For 1, scroll-conservatively needs to be < 100, something like 0-10, so > that recentering usually happens. > For 2, I have to set scroll-conservatively to 101. Some lower values may > also help, but there's no guarantee, as I understand it: the contents of > the compilation buffer are getting added in large chunks. > For 3, again, I have to set scroll-conservatively to a large value. For > C-n/C-p, the value of 5 is usually enough, for for C-M-e/C-M-a, it often > has to be larger than that. Why can't you use a value of scroll-conservatively around 10, then? The way I see it, the only problem might be with 2, and even there I'm not sure you will see it frequently, or ever. For 3, C-M-e/C-M-a will DTRT and show point in the middle of the window, unless the function is very short, in which case point will be near the beginning or end of the window; again, TRT. > Half-window happens because when the compilation buffer is filled, the > point is at the end of it (when compilation-scroll-output is t, at least). Does this happen with or without setting scroll-conservatively to a value larger than 100? Just for the record: when I asked whether people who like Emacs to _never_ recenter would mind having that behavior in contexts that have nothing to do with scrolling, the response was a huge YES. So the current behavior seems to be "by popular demand". Another possibility would be to add more customization values to compilation-scroll-output, implementing the behavior of your compile-scroll-eob. I won't argue what the default behavior should be, because it tends to become bike-shedding very fast. FWIW, I use the default behavior, without customizing any scroll-related variables, and like that behavior, including in compilation buffers. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#13133: 24.2.90; scroll-conservatively is too coarse a setting 2012-12-10 7:08 ` Eli Zaretskii @ 2012-12-10 8:28 ` Dmitry Gutov 2012-12-10 8:52 ` Eli Zaretskii 0 siblings, 1 reply; 8+ messages in thread From: Dmitry Gutov @ 2012-12-10 8:28 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 13133 On 10.12.2012 11:08, Eli Zaretskii wrote: >> Date: Mon, 10 Dec 2012 10:46:51 +0400 >> From: Dmitry Gutov <dgutov@yandex.ru> >> CC: 13133@debbugs.gnu.org >> >>>> Examples: >>>> 1) I want help-button-action to bring me to the function's definition, >>>> and I generally want in the middle of the screen. Same for imenu, etc. >>>> 2) I really don't want to see empty space after the contents in the >>>> compilation window. But as much as half of the window may be empty right >>>> after compilation because of the point recentering. >>>> 3) Ideally, if I move around with next/previous-line, I don't want >>>> sudden jumps and recenterings. Same thing with beginning/end-of-defun >>>> (so setting scroll-conservatively to a value larger than 0 is not a real >>>> solution). >>> >>> I'm sorry, but the problem you describing is entirely unclear to me. >>> You didn't say what value, if any, did you set scroll-conservatively >>> to, nor if you have any other scroll-* variables customized to >>> non-default values. If you don't customize anything, Emacs always >>> re-centers when point goes out of sight. When point is re-centered, I >>> don't think you can ever have half-window of empty space, because of >>> the way re-centering works. >>> >>> Given this lack of information, I don't understand how you get the >>> adverse effects in your 3 examples. Please elaborate, perhaps >>> separately about each of the examples. >> >> The problem is getting all 3 to work at the same time. >> >> For 1, scroll-conservatively needs to be < 100, something like 0-10, so >> that recentering usually happens. >> For 2, I have to set scroll-conservatively to 101. Some lower values may >> also help, but there's no guarantee, as I understand it: the contents of >> the compilation buffer are getting added in large chunks. >> For 3, again, I have to set scroll-conservatively to a large value. For >> C-n/C-p, the value of 5 is usually enough, for for C-M-e/C-M-a, it often >> has to be larger than that. > > Why can't you use a value of scroll-conservatively around 10, then? Just tried that with compilation, didn't help. In fact, I have to set it as large as 50 to not see empty space in the window (tried 40, no dice). And that's with one specific compilation process. Run something that's twice as verbose, and the value will have to be 100, no? > The way I see it, the only problem might be with 2, and even there I'm > not sure you will see it frequently, or ever. For 3, C-M-e/C-M-a will > DTRT and show point in the middle of the window, unless the function > is very short, in which case point will be near the beginning or end > of the window; again, TRT. Like I mentioned, I don't want C-M-e/C-M-a to recenter. Why do you think it's TRT? As far as I'm concerned, recentering might be fine when we go to the end of a small function (it will fit on the screen anyway), but a larger function, which might have fit on the full screen, will be cut in half. >> Half-window happens because when the compilation buffer is filled, the >> point is at the end of it (when compilation-scroll-output is t, at least). > > Does this happen with or without setting scroll-conservatively to a > value larger than 100? Without. > Just for the record: when I asked whether people who like Emacs to > _never_ recenter would mind having that behavior in contexts that have > nothing to do with scrolling, the response was a huge YES. So the > current behavior seems to be "by popular demand". If I had to guess, it might be that people just wanted out of the default always-recentering behavior, and it was a quick way to end the discussion and get the implementation. Anyway, I don't remember seeing that poll. And if you were asking on emacs-devel, that doesn't exactly represent the majority of users. I don't think I'm asking for anything exotic here, really. I think all 3 items are pretty much the standard in "modern" editors or IDEs. > Another possibility would be to add more customization values to > compilation-scroll-output, implementing the behavior of your > compile-scroll-eob. Yes, sure. Just set buffer-local value of scroll-conservatively, maybe? But that won't help with C-M-a/C-M-e and, I don't know, any other buffers with deal with process output? I think the compilation buffer is a great example that not only doesn't have anything to do with scrolling, but also is unrelated to code navigation. And still, scroll-conservatively is used there. > I won't argue what the default behavior should be, because it tends to > become bike-shedding very fast. FWIW, I use the default behavior, > without customizing any scroll-related variables, and like that > behavior, including in compilation buffers. Do you like the behavior of compilation buffer often having wasted space, or do you just not mind it (with monitors being cheap and all)? I don't see what anyone could really like about it. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#13133: 24.2.90; scroll-conservatively is too coarse a setting 2012-12-10 8:28 ` Dmitry Gutov @ 2012-12-10 8:52 ` Eli Zaretskii 2012-12-11 2:07 ` Dmitry Gutov 0 siblings, 1 reply; 8+ messages in thread From: Eli Zaretskii @ 2012-12-10 8:52 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 13133 > Date: Mon, 10 Dec 2012 12:28:58 +0400 > From: Dmitry Gutov <dgutov@yandex.ru> > CC: 13133@debbugs.gnu.org > > Like I mentioned, I don't want C-M-e/C-M-a to recenter. Why do you think > it's TRT? Because you generally want to see the entire definition of the API, not just the opening brace or paren. > As far as I'm concerned, recentering might be fine when we go to the end > of a small function (it will fit on the screen anyway), but a larger > function, which might have fit on the full screen, will be cut in half. IMO, C-M-e/C-M-a is not for observing the whole function. You may be looking for a separate feature, or maybe a modification of an existing feature. > >> Half-window happens because when the compilation buffer is filled, the > >> point is at the end of it (when compilation-scroll-output is t, at least). > > > > Does this happen with or without setting scroll-conservatively to a > > value larger than 100? > > Without. Can you cook up a test case? I'd like to see why this happens. (If showing this requires injection of specific amount of text into the compilation buffer, you could use 'cat' or some similar program to do so, instead of actually running a compiler.) > > Just for the record: when I asked whether people who like Emacs to > > _never_ recenter would mind having that behavior in contexts that have > > nothing to do with scrolling, the response was a huge YES. So the > > current behavior seems to be "by popular demand". > > If I had to guess, it might be that people just wanted out of the > default always-recentering behavior, and it was a quick way to end the > discussion and get the implementation. > > Anyway, I don't remember seeing that poll. And if you were asking on > emacs-devel, that doesn't exactly represent the majority of users. Emacs 24.x with this feature was released 6 months ago, and I have yet to see a single complaint about it -- until now. What user poll can possibly match that? > > Another possibility would be to add more customization values to > > compilation-scroll-output, implementing the behavior of your > > compile-scroll-eob. > > Yes, sure. Just set buffer-local value of scroll-conservatively, maybe? Could be. But I think it is best first to define the required behavior first. Then we can see if setting scroll-conservatively would fit the bill. > But that won't help with C-M-a/C-M-e and, I don't know, any other > buffers with deal with process output? "M-x shell" comes to mind. > > I won't argue what the default behavior should be, because it tends to > > become bike-shedding very fast. FWIW, I use the default behavior, > > without customizing any scroll-related variables, and like that > > behavior, including in compilation buffers. > > Do you like the behavior of compilation buffer often having wasted > space, or do you just not mind it (with monitors being cheap and all)? I > don't see what anyone could really like about it. Very simple: I don't watch the compilation messages as they come in. It's a waste of time; I continue editing or doing something else while the compiler churns away. To me, watching the messages is a relic from old DOS days when I couldn't do anything while waiting for the compiler to finish. I only look at the compiler messages when compilation finishes, and then I either scroll through the buffer or use "C-x `". In both cases, what redisplay does when a new message comes in is of no interest to me. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#13133: 24.2.90; scroll-conservatively is too coarse a setting 2012-12-10 8:52 ` Eli Zaretskii @ 2012-12-11 2:07 ` Dmitry Gutov 2012-12-11 7:09 ` Eli Zaretskii 0 siblings, 1 reply; 8+ messages in thread From: Dmitry Gutov @ 2012-12-11 2:07 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 13133 On 10.12.2012 12:52, Eli Zaretskii wrote: >> Date: Mon, 10 Dec 2012 12:28:58 +0400 >> From: Dmitry Gutov <dgutov@yandex.ru> >> CC: 13133@debbugs.gnu.org >> >> Like I mentioned, I don't want C-M-e/C-M-a to recenter. Why do you think >> it's TRT? > > Because you generally want to see the entire definition of the API, > not just the opening brace or paren. Not sure if I understand you here. For example, if I'm in an Elisp function, I can press C-M-a to go to its beginning, and the whole definition (including arglist and docstring) will be visible. If the value of scroll-conservatively is small, though, the function body may be cut in half. Or do you specifically mean non-lisp languages where the docstring is above the function definition? >> As far as I'm concerned, recentering might be fine when we go to the end >> of a small function (it will fit on the screen anyway), but a larger >> function, which might have fit on the full screen, will be cut in half. > > IMO, C-M-e/C-M-a is not for observing the whole function. You may be > looking for a separate feature, or maybe a modification of an existing > feature. I don't think you can reasonably decide what they are for. When a command moves viewport, I think it's reasonable to use it for that purpose. Not that that's the only purpose I use them for, but in general I prefer when the body of a function displayed in a buffer is not split in half. Also, I'd prefer if end-of-definition's behavior didn't depend on the length of the function it acts on. It's a little disorienting. >>>> Half-window happens because when the compilation buffer is filled, the >>>> point is at the end of it (when compilation-scroll-output is t, at least). >>> >>> Does this happen with or without setting scroll-conservatively to a >>> value larger than 100? >> >> Without. > > Can you cook up a test case? I'd like to see why this happens. (If > showing this requires injection of specific amount of text into the > compilation buffer, you could use 'cat' or some similar program to do > so, instead of actually running a compiler.) Here's one: ~/tesh.sh: #!/bin/bash for i in `seq 1 125`; do echo "Lorem ipsum" done eval: (setq scroll-conservatively 10) (let ((compilation-scroll-output t)) (compile "~/test.sh")) In the end, in 54-line window, the text "Compilation finished" ends up on line 26. >>> Just for the record: when I asked whether people who like Emacs to >>> _never_ recenter would mind having that behavior in contexts that have >>> nothing to do with scrolling, the response was a huge YES. So the >>> current behavior seems to be "by popular demand". >> >> If I had to guess, it might be that people just wanted out of the >> default always-recentering behavior, and it was a quick way to end the >> discussion and get the implementation. >> >> Anyway, I don't remember seeing that poll. And if you were asking on >> emacs-devel, that doesn't exactly represent the majority of users. > > Emacs 24.x with this feature was released 6 months ago, and I have yet > to see a single complaint about it -- until now. What user poll can > possibly match that? Not sure. But it is a low-level feature that's not exactly trivial to reason about. So a user might not think it's a bug worth reporting, even if they don't like the behavior. For example, when I migrated to Emacs 24, I remember reading about the improvements to scroll-conservatively, so setting it to 101 was one of the first things I did. Then I noticed that it makes imenu and help-button-action only scroll as far as the first line of the function definition, which is something I don't believe anyone can find optimal. So I set the variable value to 5, which allowed next/previous-line scrolling without recentering, and at the same time usually makes code navigation commands recenter. I haven't used compilation buffer much until recently. But this value of 5 is bad in subtle ways. Aside from what I mentioned about compilation, *-of-defun, *-sentence and similar commands, the behavior of imenu and help-button-action that comes with any positive value of scroll-conservatively is strange. Sure, that's a rare case, but what if the function I'm looking for is 3 or 5 lines below the last window line? Then imenu won't recenter on it. That makes no sense. I'd rather they used some other variable that allowed to specify the number of lines that the function I navigated to is allowed to be from the window boundary. Closer than 4 lines? Recenter! Or maybe always recenter, or put the first line of the function at 1/3rd of the window height from the top. >> But that won't help with C-M-a/C-M-e and, I don't know, any other >> buffers with deal with process output? > > "M-x shell" comes to mind. It passes my test case. Calling ~/test.sh doesn't make the prompt line scroll to the middle of the window. Same for inf-ruby (derived from comint-mode). >>> I won't argue what the default behavior should be, because it tends to >>> become bike-shedding very fast. FWIW, I use the default behavior, >>> without customizing any scroll-related variables, and like that >>> behavior, including in compilation buffers. >> >> Do you like the behavior of compilation buffer often having wasted >> space, or do you just not mind it (with monitors being cheap and all)? I >> don't see what anyone could really like about it. > > Very simple: I don't watch the compilation messages as they come in. > It's a waste of time; I continue editing or doing something else while > the compiler churns away. To me, watching the messages is a relic > from old DOS days when I couldn't do anything while waiting for the > compiler to finish. > > I only look at the compiler messages when compilation finishes, and > then I either scroll through the buffer or use "C-x `". In both > cases, what redisplay does when a new message comes in is of no > interest to me. I'm also only interested in what the window looks like when the compilation is finished. But I want to be able to see as much of the log as possible without scrolling or invoking any other commands. I'm not compiling anything, actually, just calling rspec and looking at the output. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#13133: 24.2.90; scroll-conservatively is too coarse a setting 2012-12-11 2:07 ` Dmitry Gutov @ 2012-12-11 7:09 ` Eli Zaretskii 0 siblings, 0 replies; 8+ messages in thread From: Eli Zaretskii @ 2012-12-11 7:09 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 13133 > Date: Tue, 11 Dec 2012 06:07:11 +0400 > From: Dmitry Gutov <dgutov@yandex.ru> > CC: 13133@debbugs.gnu.org > > On 10.12.2012 12:52, Eli Zaretskii wrote: > >> Date: Mon, 10 Dec 2012 12:28:58 +0400 > >> From: Dmitry Gutov <dgutov@yandex.ru> > >> CC: 13133@debbugs.gnu.org > >> > >> Like I mentioned, I don't want C-M-e/C-M-a to recenter. Why do you think > >> it's TRT? > > > > Because you generally want to see the entire definition of the API, > > not just the opening brace or paren. > > Not sure if I understand you here. For example, if I'm in an Elisp > function, I can press C-M-a to go to its beginning, and the whole > definition (including arglist and docstring) will be visible. If the > value of scroll-conservatively is small, though, the function body may > be cut in half. > Or do you specifically mean non-lisp languages where the docstring is > above the function definition? Yes, the latter. > >> As far as I'm concerned, recentering might be fine when we go to the end > >> of a small function (it will fit on the screen anyway), but a larger > >> function, which might have fit on the full screen, will be cut in half. > > > > IMO, C-M-e/C-M-a is not for observing the whole function. You may be > > looking for a separate feature, or maybe a modification of an existing > > feature. > > I don't think you can reasonably decide what they are for. I didn't decide anything, I just gave you my interpretation. That's what "IMO" is for. > > Can you cook up a test case? I'd like to see why this happens. (If > > showing this requires injection of specific amount of text into the > > compilation buffer, you could use 'cat' or some similar program to do > > so, instead of actually running a compiler.) > > Here's one: Thanks, I'll take a look. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2012-12-11 7:09 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-12-10 3:29 bug#13133: 24.2.90; scroll-conservatively is too coarse a setting Dmitry Gutov 2012-12-10 6:30 ` Eli Zaretskii 2012-12-10 6:46 ` Dmitry Gutov 2012-12-10 7:08 ` Eli Zaretskii 2012-12-10 8:28 ` Dmitry Gutov 2012-12-10 8:52 ` Eli Zaretskii 2012-12-11 2:07 ` Dmitry Gutov 2012-12-11 7:09 ` Eli Zaretskii
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.