Re: A few changes to test in master
Hi Jack, Jack Kamm writes: > Hmm, I'm experience the problem worse now -- the header is always > getting stuck on the first row it appears on. Also, I'm seeing the > follow error in my *Messages*: A silly oversight on my side (I need a little break.) Fixed. > Sure, see the patch below. Applied, thanks! -- Bastien
Re: A few changes to test in master
Hi Bastien, Bastien writes: >> I have noticed a new bug, where the header line randomly gets "stuck" >> on some row of the table, so even when I scroll and that row is no >> longer on top of the buffer, that row is still replaced by the header >> line. > > Yes, fixed now. Hmm, I'm experience the problem worse now -- the header is always getting stuck on the first row it appears on. Also, I'm seeing the follow error in my *Messages*: Error in post-command-hook (org-table-header-set-header): (error "Invalid or uninitialized timer") >> Thanks. The default face looks great on light-themed backgrounds like >> leuven, but is hard to read on some dark-themed backgrounds like >> tsdh-dark or zenburn, due to their light text. Maybe the simplest >> solution would be to set both the background and foreground colors in >> the default face? > > Sure - would you like to suggest a patch for this? Sure, see the patch below. >From 2922d104b3508b1269c17ad0a28103bd912e308b Mon Sep 17 00:00:00 2001 From: Jack Kamm Date: Fri, 7 Feb 2020 18:04:59 -0800 Subject: [PATCH] org-faces.el: Add foreground color to org-table-header face * lisp/org-faces.el (org-table-header): Add foreground color to org-table-header face, to ensure readability when using a dark theme. --- lisp/org-faces.el | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/lisp/org-faces.el b/lisp/org-faces.el index d50f715cc..d78b606ec 100644 --- a/lisp/org-faces.el +++ b/lisp/org-faces.el @@ -364,7 +364,9 @@ changes." "Face used for tables." :group 'org-faces) -(defface org-table-header '((t :inherit org-table :background "LightGray")) +(defface org-table-header '((t :inherit org-table + :background "LightGray" + :foreground "Black")) "Face for table header." :group 'org-faces) -- 2.25.0
Re: A few changes to test in master
Hi Jack, Jack Kamm writes: > FWIW, I wouldn't mind if this were a global minor mode, I intend to > activate it globally with `org-table-header-line-p'. Well, it only makes sense in org buffers, so activating it through this variable is okay IMO. > Since updating and testing for a few minutes, I haven't noticed this > issue anymore. However, I have noticed a new bug, where the header line > randomly gets "stuck" on some row of the table, so even when I scroll > and that row is no longer on top of the buffer, that row is still > replaced by the header line. Yes, fixed now. >> M-x customize-face RET org-table-header RET > > Thanks. The default face looks great on light-themed backgrounds like > leuven, but is hard to read on some dark-themed backgrounds like > tsdh-dark or zenburn, due to their light text. While this could be left > to the user or individual themes to fix, it'd be nice if it worked out > of the box for the common dark themes. Maybe the simplest solution would > be to set both the background and foreground colors in the default > face? Sure - would you like to suggest a patch for this? -- Bastien
Re: A few changes to test in master
Hi Bastien, Bastien writes: >> The variable `org-table-header-line-p' doesn't seem to have any effect >> for me, I find that I need to call "M-x org-table-header-line-mode" even >> when it's set. > > Should be fixed now. Confirmed, it works correctly for me now. >> Also, "M-x org-table-header-line-mode" seems to activate the minor mode >> globally > > Well, I tried various things and I didn't fix this one. Perhaps this > is due to the special display of the header line. I will continue to > look for a solution. FWIW, I wouldn't mind if this were a global minor mode, I intend to activate it globally with `org-table-header-line-p'. >> If I am in a table, and scroll-up-command brings me out of the table, >> then the header of the table still sits on top of the window immediately >> after scrolling. This gets fixed as soon as any action is taken >> (e.g. moving the cursor or hitting C-g). > > Yes, this happened to me sometimes. I think I enhanced the situation > a bit here, but I can't tell for 100% sure. Please test and report. Since updating and testing for a few minutes, I haven't noticed this issue anymore. However, I have noticed a new bug, where the header line randomly gets "stuck" on some row of the table, so even when I scroll and that row is no longer on top of the buffer, that row is still replaced by the header line. This bug happens infrequently, and I haven't figured out how to consistently reproduce yet. I noticed this happening when I was scrolling up and down many times past the same table, and also switching themes. >> It would be nice if the header row was a little more visually >> distinguishable from the other table rows (maybe by adding an underline >> to that row?) > > Good idea, done - you can now customize the face: > > M-x customize-face RET org-table-header RET Thanks. The default face looks great on light-themed backgrounds like leuven, but is hard to read on some dark-themed backgrounds like tsdh-dark or zenburn, due to their light text. While this could be left to the user or individual themes to fix, it'd be nice if it worked out of the box for the common dark themes. Maybe the simplest solution would be to set both the background and foreground colors in the default face?
Re: A few changes to test in master
On Wednesday, 5 Feb 2020 at 08:08, Bastien wrote: > I just fixed the scroll-bar issue, thanks! Confirmed! Many thanks. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.2-198-g06d36e
Re: A few changes to test in master
"Fraga, Eric" writes: > Much better. See attached screenshots. One with scroll bar (which I > normally don't have turned on) and one with line numbers (which I do > usually have). I just fixed the scroll-bar issue, thanks! -- Bastien
Re: A few changes to test in master
On Wednesday, 5 Feb 2020 at 00:21, Bastien wrote: > This should be fixed now, thanks! Much better. See attached screenshots. One with scroll bar (which I normally don't have turned on) and one with line numbers (which I do usually have). >> org-table-header-line-mode: Symbol’s function definition is void: >> face-remap-remove-relative > > Mhh... this I cannot reproduce (with Emacs -Q and latest master). > Let me know if you find where lies the problem. This seems to have been fixed. Thank you. -- Eric S Fraga via Emacs 28.0.50, Org release_9.3.2-198-g06d36e
Re: A few changes to test in master
Hi Jack, Jack Kamm writes: > Bastien writes: > >> - M-x org-table-electric-header-mode RET will display the first row >> of the table at point in the header line when the first row is not >> visible anymore. > > This is great, it's a huge quality-of-life improvement for working with > long tables. Below are some issues I noticed when playing with it. Thanks for testing and taking the trouble to report these issues. > The variable `org-table-header-line-p' doesn't seem to have any effect > for me, I find that I need to call "M-x org-table-header-line-mode" even > when it's set. Should be fixed now. > Also, "M-x org-table-header-line-mode" seems to activate the minor mode > globally, despite a message suggesting it is only activated in the > current buffer. Maybe because we use "defvar" instead of "defvar-local" > to define its variable? > > I tried replacing the "defvar" with "defvar-local", it seemed to fix the > global activation of the minor mode, but still it seems the hooks added > are still active in other org buffers. So if I activate the mode in > buffer A, then view a long table in buffer B, I see the table header > when scrolling through it, even though the mode isn't active in B. Well, I tried various things and I didn't fix this one. Perhaps this is due to the special display of the header line. I will continue to look for a solution. > If I am in a table, and scroll-up-command brings me out of the table, > then the header of the table still sits on top of the window immediately > after scrolling. This gets fixed as soon as any action is taken > (e.g. moving the cursor or hitting C-g). Yes, this happened to me sometimes. I think I enhanced the situation a bit here, but I can't tell for 100% sure. Please test and report. > It would be nice if the header row was a little more visually > distinguishable from the other table rows (maybe by adding an underline > to that row?) Good idea, done - you can now customize the face: M-x customize-face RET org-table-header RET > Feature request (for Org 9.5?): > > It would be great if an analogous feature could be added for the > left-most column of a table, so if a table is very wide, and I scroll to > the right, I could still see which row index I'm in. Yes. I am still trying to precisely see the problem and solve it in a way that's not too invasive. Best, -- Bastien
Re: A few changes to test in master
Hi Eric, "Fraga, Eric" writes: > the latest on the table header. With emacs -Q and org from a few > minutes ago, I get the following: > > screendu > > when I open the file, invoke M-x org-table-header-line-mode RET and > scroll down in the attached org file. This should be fixed now, thanks! > Note also that if I invoke the above command before opening an org > file, org complains (correctly) about the command not being suitable > outside org but then, when I open the attached file and invoke the > command again, I get: > > org-table-header-line-mode: Symbol’s function definition is void: > face-remap-remove-relative Mhh... this I cannot reproduce (with Emacs -Q and latest master). Let me know if you find where lies the problem. Best, -- Bastien
Re: A few changes to test in master
Bastien writes: > - M-x org-table-electric-header-mode RET will display the first row > of the table at point in the header line when the first row is not > visible anymore. This is great, it's a huge quality-of-life improvement for working with long tables. Below are some issues I noticed when playing with it. Major issues: The variable `org-table-header-line-p' doesn't seem to have any effect for me, I find that I need to call "M-x org-table-header-line-mode" even when it's set. Also, "M-x org-table-header-line-mode" seems to activate the minor mode globally, despite a message suggesting it is only activated in the current buffer. Maybe because we use "defvar" instead of "defvar-local" to define its variable? I tried replacing the "defvar" with "defvar-local", it seemed to fix the global activation of the minor mode, but still it seems the hooks added are still active in other org buffers. So if I activate the mode in buffer A, then view a long table in buffer B, I see the table header when scrolling through it, even though the mode isn't active in B. Minor issues: If I am in a table, and scroll-up-command brings me out of the table, then the header of the table still sits on top of the window immediately after scrolling. This gets fixed as soon as any action is taken (e.g. moving the cursor or hitting C-g). It would be nice if the header row was a little more visually distinguishable from the other table rows (maybe by adding an underline to that row?) Feature request (for Org 9.5?): It would be great if an analogous feature could be added for the left-most column of a table, so if a table is very wide, and I scroll to the right, I could still see which row index I'm in.
Re: A few changes to test in master
Bastien, the latest on the table header. With emacs -Q and org from a few minutes ago, I get the following: [screendump-20200204064315.png] when I open the file, invoke M-x org-table-header-line-mode RET and scroll down in the attached org file. Note also that if I invoke the above command before opening an org file, org complains (correctly) about the command not being suitable outside org but then, when I open the attached file and invoke the command again, I get: org-table-header-line-mode: Symbol’s function definition is void: face-remap-remove-relative Thank you. eric PS -signature out of date in this case. org up to date from 5 minutes ago now. – Eric S Fraga via Emacs 28.0.50, Org release9.3.2-198-g06d36e * Long table #+startup: shrink | name | cost | description| | | <6> | <20> | |--+--+| | an entry |1 | this is a very long description of the item we wish to buy | | an entry |2 | this is a very long description of the item we wish to buy | | an entry |3 | this is a very long description of the item we wish to buy | | an entry |4 | this is a very long description of the item we wish to buy | | an entry |5 | this is a very long description of the item we wish to buy | | an entry |6 | this is a very long description of the item we wish to buy | | an entry |7 | this is a very long description of the item we wish to buy | | an entry |8 | this is a very long description of the item we wish to buy | | an entry |9 | this is a very long description of the item we wish to buy | | an entry | 10 | this is a very long description of the item we wish to buy | | an entry | 11 | this is a very long description of the item we wish to buy | | an entry | 12 | this is a very long description of the item we wish to buy | | an entry | 13 | this is a very long description of the item we wish to buy | | an entry | 14 | this is a very long description of the item we wish to buy | | an entry | 15 | this is a very long description of the item we wish to buy | | an entry | 16 | this is a very long description of the item we wish to buy | | an entry | 17 | this is a very long description of the item we wish to buy | | an entry | 18 | this is a very long description of the item we wish to buy | | an entry | 19 | this is a very long description of the item we wish to buy | | an entry | 20 | this is a very long description of the item we wish to buy | | an entry | 21 | this is a very long description of the item we wish to buy | | an entry | 22 | this is a very long description of the item we wish to buy | | an entry | 23 | this is a very long description of the item we wish to buy | | an entry | 24 | this is a very long description of the item we wish to buy | | an entry | 25 | this is a very long description of the item we wish to buy | | an entry | 26 | this is a very long description of the item we wish to buy | | an entry | 27 | this is a very long description of the item we wish to buy | | an entry | 28 | this is a very long description of the item we wish to buy | | an entry | 29 | this is a very long description of the item we wish to buy | | an entry | 30 | this is a very long description of the item we wish to buy | | an entry | 31 | this is a very long description of the item we wish to buy | | an entry | 32 | this is a very long description of the item we wish to buy | | an entry | 33 | this is a very long description of the item we wish to buy | | an entry | 34 | this is a very long description of the item we wish to buy | | an entry | 35 | this is a very long description of the item we wish to buy | | an entry | 36 | this is a very long description of the item we wish to buy | | an entry | 37 | this is a very long description of the item we wish to buy | | an entry | 38 | this is a very long description of the item we wish to buy | | an entry | 39 | this is a very long description of the item we wish to buy | | an entry | 40 | this is a very long description of the item we wish to buy | | an entry | 41 | this is a very long description of the item we wish to buy | | an entry | 42 | this is a very long description of the item we wish to buy | | an entry | 43 | this is a very long description of the item we wish to buy | | an entry | 44 | this is a very long description of the item we wish to buy | | an entry | 45 | this is a very long description of the item we wish to buy | | an entry | 46 | this is a very long description of the item we wish to buy | | an entry | 47 | this is a very long description of the item we wish to buy | | an entry | 48 | this is a very long description of the item we wish to buy | | an entry | 49 | this is a very long description of the item we wish to buy | | an entry | 50 |
Re: A few changes to test in master
On Monday, 3 Feb 2020 at 09:17, Bastien wrote: > "Fraga, Eric" writes: > >> The header line is now 2 characters to the right of where it should be! >> I have looked at the code briefly but cannot figure out why this would >> be. >> >> I have not seen any difference in behaviour for shrunken columns. > > What is M-x org-version RET ? In my signature. > Can you send a reproducible ECM ? I'll try tomorrow. With respect to the placement of the table header, I should say that my line-number face is customized to have characters smaller than the default text. This will probably affect the placement and I'm sure will make it very difficult to adjust correctly (i.e. more difficult than is really worth the effort). Thank you. -- Eric S Fraga via Emacs 28.0.50, Org release_9.3.2-199-ga557cf
Re: A few changes to test in master
Hi Eric, "Fraga, Eric" writes: > The header line is now 2 characters to the right of where it should be! > I have looked at the code briefly but cannot figure out why this would > be. > > I have not seen any difference in behaviour for shrunken columns. What is M-x org-version RET ? Can you send a reproducible ECM ? -- Bastien
Re: A few changes to test in master
On Friday, 31 Jan 2020 at 21:31, Bastien wrote: > "Fraga, Eric" writes: > >> 1. the header contents are placed at the leftmost column means the first >>row does not align with the table in two cases: >>1. when display-line-number-mode is active and/or >>2. when org-indent-mode is used. > > This concern should be gone now - if you can, please pull from master > and test again. The header line is now 2 characters to the right of where it should be! I have looked at the code briefly but cannot figure out why this would be. I have not seen any difference in behaviour for shrunken columns. Thank you. -- Eric S Fraga via Emacs 28.0.50, Org release_9.3.2-198-g06d36e
Re: A few changes to test in master
Hi Eric, "Fraga, Eric" writes: > On Friday, 31 Jan 2020 at 17:50, Bastien wrote: >> "Fraga, Eric" writes: >>> 2. the display of the first row does not have column widths adjusted and >>>so the entries do not line up if the table itself has adjusted column >>>widths (C-c TAB). >> >> `org-table-automatic-realign' being t by default, I very seldom have a >> problem with the alignment of the first row, so this one does not seem >> to be very problematic to me. > > No, sorry, I think you misunderstood as I did not explain properly. If > some columns are hidden or shrunk, the header line is not and so the > columns are misaligned. This is independent of automatic > realignment. Yes, sorry, I realized I did not understood when I received another similar request. Please test the feature from master again, I fixed this two days ago. -- Bastien
Re: A few changes to test in master
On Friday, 31 Jan 2020 at 17:50, Bastien wrote: > "Fraga, Eric" writes: >> 2. the display of the first row does not have column widths adjusted and >>so the entries do not line up if the table itself has adjusted column >>widths (C-c TAB). > > `org-table-automatic-realign' being t by default, I very seldom have a > problem with the alignment of the first row, so this one does not seem > to be very problematic to me. No, sorry, I think you misunderstood as I did not explain properly. If some columns are hidden or shrunk, the header line is not and so the columns are misaligned. This is independent of automatic realignment. -- Eric S Fraga via Emacs 28.0.50, Org release_9.3.2-164-g3d0282
Re: A few changes to test in master
Hi Axel, Axel Kielhorn writes: > I now get: > > Error running timer: (invalid-function (ov (first (overlays-in > (point) (1+ (point)) [10 times] That was due to the use of `if-let' - this should be fixed now. Thanks, -- Bastien
Re: A few changes to test in master
> Am 01.02.2020 um 17:39 schrieb Bastien : > > Hi Axel, > > Axel Kielhorn writes: > >> There is another issue when a column is reduced in width by C-C TAB. >> The header line still has the original width, thus the columns are >> not aligned. > > Ah, I know understand - this should be fixed too, thanks. With Org mode version 9.3.2 (release_9.3.2-182-g4d5731 ...) I now get: Error running timer: (invalid-function (ov (first (overlays-in (point) (1+ (point)) [10 times] Greetings Axel
Re: A few changes to test in master
Hi Axel, Axel Kielhorn writes: > There is another issue when a column is reduced in width by C-C TAB. > The header line still has the original width, thus the columns are > not aligned. Ah, I know understand - this should be fixed too, thanks. -- Bastien
Re: A few changes to test in master
Hi Bastien, > Hi Axel, > > thanks for testing the feature and reporting these issues. > > I pushed a fix on master - can you confirm it solves your issues? It does, thanks for the quick response. There is another issue when a column is reduced in width by C-C TAB. The header line still has the original width, thus the columns are not aligned. Greetings Axel
Re: A few changes to test in master
Hi Axel, thanks for testing the feature and reporting these issues. I pushed a fix on master - can you confirm it solves your issues? -- Bastien
Re: A few changes to test in master
> Am 31.01.2020 um 12:26 schrieb Bastien : > > Dear all, > > I would like to highlight three changes from master that need to be > carefully tested before Org 9.4 can be released: > > - M-x org-table-electric-header-mode RET will display the first row > of the table at point in the header line when the first row is not > visible anymore. This sounds great! It works fine when I activate Display Line Numbers Mode. Without that I get: Org-Table-Header-Line mode enabled in current buffer Error running timer: (void-variable display-line-numbers-mode) [3 times] but no header line. When I enable Display Line Numbers Mode Activate org-table-header-line-mode And disable Display Line Numbers Mode it keeps on working but I still get lots of (void-variable display-line-numbers-mode) warnings. I’m using Emacs 26.3 on MacOS 10.13 with the scimax customization. Org mode version 9.3.2 (release_9.3.2-175-gf70490 ...) Greetings Axel
Re: A few changes to test in master
Samuel Wales writes: > org-table-header-line-mode? That's indeed better - I pushed the change. Thanks to both of you! -- Bastien
Re: A few changes to test in master
On Fri, Jan 31, 2020, 9:45 PM Samuel Wales wrote: > org-table-header-line-mode? > +1 >
Re: A few changes to test in master
org-table-header-line-mode?
Re: A few changes to test in master
On Fri, Jan 31, 2020, 6:28 AM Bastien wrote: > Dear all, > > I would like to highlight three changes from master that need to be > carefully tested before Org 9.4 can be released: > > - M-x org-table-electric-header-mode RET will display the first row > of the table at point in the header line when the first row is not > visible anymore. > Hello Bastien, Thanks for that mode! Minor nitpick coming up.. May I suggest naming the mode org-table-sticky-header-mode instead? Somehow the "electric" in the name wasn't intuitive to me.. or maybe that's just me.
Re: A few changes to test in master
Hi Eric, "Fraga, Eric" writes: > 1. the header contents are placed at the leftmost column means the first >row does not align with the table in two cases: >1. when display-line-number-mode is active and/or >2. when org-indent-mode is used. This concern should be gone now - if you can, please pull from master and test again. Thanks! -- Bastien
Re: A few changes to test in master
Hi Eric, "Fraga, Eric" writes: > This is very appealing and I'll be using it by default (despite issues; > see below) as I often have long tables in my documents. Thanks, I also start to use it by default to test it more. > Some issues which may or may not be easily fixable or may require more > effort than is worth: > > 1. the header contents are placed at the leftmost column means the first >row does not align with the table in two cases: >1. when display-line-number-mode is active and/or >2. when org-indent-mode is used. Yes -- I'll see what can be done in this area, but probably the easiest way is to warn the user of compatibility issues. > 2. the display of the first row does not have column widths adjusted and >so the entries do not line up if the table itself has adjusted column >widths (C-c TAB). `org-table-automatic-realign' being t by default, I very seldom have a problem with the alignment of the first row, so this one does not seem to be very problematic to me. Thanks for your feedback, -- Bastien
Re: A few changes to test in master
Hi stardiviner, stardiviner writes: > I can't added numeric priorities with default =[C-c ,]= keybinding.* The keybinding respect the current priority, which either depends on org-priority-lowest/highest/default or on #+PRIORITIES for buffer-local setting. Please change the setting (either globally or locally) and test again. Thanks, -- Bastien
Re: A few changes to test in master
Bastien writes: > Dear all, > > I would like to highlight three changes from master that need to be > carefully tested before Org 9.4 can be released: > > - M-x org-table-electric-header-mode RET will display the first row > of the table at point in the header line when the first row is not > visible anymore. > > - Numeric priorities: e.g. #+PRIORITIES: 1 10 3 in the buffer will > let you use numeric priorities (from 1 to 10, default to 3). > You cannot use higher values than 64 for priorities. I don't want > to go too far in the flexibility of priorities, but I think this > generalization is fine. I can't added numeric priorities with default =[C-c ,]= keybinding. > > - The new org-agenda-filter command has been adapted to use the > current filters as the default value. I find it more consistent > with the previous implementation of filtering. > > Let me know if any of these changes is problematic for you. > > Thanks, -- [ stardiviner ] I try to make every word tell the meaning what I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
Re: A few changes to test in master
On Friday, 31 Jan 2020 at 12:26, Bastien wrote: > I would like to highlight three changes from master that need to be > carefully tested before Org 9.4 can be released: > > - M-x org-table-electric-header-mode RET will display the first row > of the table at point in the header line when the first row is not > visible anymore. This is very appealing and I'll be using it by default (despite issues; see below) as I often have long tables in my documents. Some issues which may or may not be easily fixable or may require more effort than is worth: 1. the header contents are placed at the leftmost column means the first row does not align with the table in two cases: 1. when display-line-number-mode is active and/or 2. when org-indent-mode is used. 2. the display of the first row does not have column widths adjusted and so the entries do not line up if the table itself has adjusted column widths (C-c TAB). Thank you. -- Eric S Fraga via Emacs 28.0.50, Org release_9.3.2-164-g3d0282
A few changes to test in master
Dear all, I would like to highlight three changes from master that need to be carefully tested before Org 9.4 can be released: - M-x org-table-electric-header-mode RET will display the first row of the table at point in the header line when the first row is not visible anymore. - Numeric priorities: e.g. #+PRIORITIES: 1 10 3 in the buffer will let you use numeric priorities (from 1 to 10, default to 3). You cannot use higher values than 64 for priorities. I don't want to go too far in the flexibility of priorities, but I think this generalization is fine. - The new org-agenda-filter command has been adapted to use the current filters as the default value. I find it more consistent with the previous implementation of filtering. Let me know if any of these changes is problematic for you. Thanks, -- Bastien
