A few changes to test in master

A few changes to test in master

[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.

- 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

Re: A few changes to test in master

[Fraga, Eric]

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

Re: A few changes to test in master

[Bastien]

Hi Eric,

"Fraga, Eric" <e.fraga@ucl.ac.uk> 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

[Fraga, Eric]

On Friday, 31 Jan 2020 at 17:50, Bastien wrote:
> "Fraga, Eric" <e.fraga@ucl.ac.uk> 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

[Bastien]

Hi Eric,

"Fraga, Eric" <e.fraga@ucl.ac.uk> writes:

> On Friday, 31 Jan 2020 at 17:50, Bastien wrote:
>> "Fraga, Eric" <e.fraga@ucl.ac.uk> 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

[Bastien]

Hi Eric,

"Fraga, Eric" <e.fraga@ucl.ac.uk> 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

[Fraga, Eric]

On Friday, 31 Jan 2020 at 21:31, Bastien wrote:
> "Fraga, Eric" <e.fraga@ucl.ac.uk> 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

[Bastien]

Hi Eric,

"Fraga, Eric" <e.fraga@ucl.ac.uk> 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

[Fraga, Eric]

On Monday,  3 Feb 2020 at 09:17, Bastien wrote:
> "Fraga, Eric" <e.fraga@ucl.ac.uk> 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

[Fraga, Eric]

[-- Attachment #1.1.1: Type: text/plain, Size: 763 bytes --]

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

[-- Attachment #1.1.2: Type: text/html, Size: 1159 bytes --]

[-- Attachment #1.2: screendump-20200204064315.png --]
[-- Type: image/png, Size: 15644 bytes --]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: longtable.org --]
[-- Type: text/x-org; name="longtable.org", Size: 9160 bytes --]

* 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 | this is a very long description of the item we wish to buy |
| an entry |   51 | this is a very long description of the item we wish to buy |
| an entry |   52 | this is a very long description of the item we wish to buy |
| an entry |   53 | this is a very long description of the item we wish to buy |
| an entry |   54 | this is a very long description of the item we wish to buy |
| an entry |   55 | this is a very long description of the item we wish to buy |
| an entry |   56 | this is a very long description of the item we wish to buy |
| an entry |   57 | this is a very long description of the item we wish to buy |
| an entry |   58 | this is a very long description of the item we wish to buy |
| an entry |   59 | this is a very long description of the item we wish to buy |
| an entry |   60 | this is a very long description of the item we wish to buy |
| an entry |   61 | this is a very long description of the item we wish to buy |
| an entry |   62 | this is a very long description of the item we wish to buy |
| an entry |   63 | this is a very long description of the item we wish to buy |
| an entry |   64 | this is a very long description of the item we wish to buy |
| an entry |   65 | this is a very long description of the item we wish to buy |
| an entry |   66 | this is a very long description of the item we wish to buy |
| an entry |   67 | this is a very long description of the item we wish to buy |
| an entry |   68 | this is a very long description of the item we wish to buy |
| an entry |   69 | this is a very long description of the item we wish to buy |
| an entry |   70 | this is a very long description of the item we wish to buy |
| an entry |   71 | this is a very long description of the item we wish to buy |
| an entry |   72 | this is a very long description of the item we wish to buy |
| an entry |   73 | this is a very long description of the item we wish to buy |
| an entry |   74 | this is a very long description of the item we wish to buy |
| an entry |   75 | this is a very long description of the item we wish to buy |
| an entry |   76 | this is a very long description of the item we wish to buy |
| an entry |   77 | this is a very long description of the item we wish to buy |
| an entry |   78 | this is a very long description of the item we wish to buy |
| an entry |   79 | this is a very long description of the item we wish to buy |
| an entry |   80 | this is a very long description of the item we wish to buy |
| an entry |   81 | this is a very long description of the item we wish to buy |
| an entry |   82 | this is a very long description of the item we wish to buy |
| an entry |   83 | this is a very long description of the item we wish to buy |
| an entry |   84 | this is a very long description of the item we wish to buy |
| an entry |   85 | this is a very long description of the item we wish to buy |
| an entry |   86 | this is a very long description of the item we wish to buy |
| an entry |   87 | this is a very long description of the item we wish to buy |
| an entry |   88 | this is a very long description of the item we wish to buy |
| an entry |   89 | this is a very long description of the item we wish to buy |
| an entry |   90 | this is a very long description of the item we wish to buy |
| an entry |   91 | this is a very long description of the item we wish to buy |
| an entry |   92 | this is a very long description of the item we wish to buy |
| an entry |   93 | this is a very long description of the item we wish to buy |
| an entry |   94 | this is a very long description of the item we wish to buy |
| an entry |   95 | this is a very long description of the item we wish to buy |
| an entry |   96 | this is a very long description of the item we wish to buy |
| an entry |   97 | this is a very long description of the item we wish to buy |
| an entry |   98 | this is a very long description of the item we wish to buy |
| an entry |   99 | this is a very long description of the item we wish to buy |
| an entry |  100 | this is a very long description of the item we wish to buy |
| an entry |  101 | this is a very long description of the item we wish to buy |
| an entry |  102 | this is a very long description of the item we wish to buy |
| an entry |  103 | this is a very long description of the item we wish to buy |
| an entry |  104 | this is a very long description of the item we wish to buy |
| an entry |  105 | this is a very long description of the item we wish to buy |
| an entry |  106 | this is a very long description of the item we wish to buy |
| an entry |  107 | this is a very long description of the item we wish to buy |
| an entry |  108 | this is a very long description of the item we wish to buy |
#+TBLFM: $2=@-1+1;N

Re: A few changes to test in master

[Bastien]

Hi Eric,

"Fraga, Eric" <e.fraga@ucl.ac.uk> 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

[Fraga, Eric]

[-- Attachment #1: Type: text/plain, Size: 592 bytes --]

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

[-- Attachment #2: screendump-20200205062642.png --]
[-- Type: image/png, Size: 13223 bytes --]

[-- Attachment #3: screendump-20200205062229.png --]
[-- Type: image/png, Size: 14535 bytes --]

Re: A few changes to test in master

[Bastien]

"Fraga, Eric" <e.fraga@ucl.ac.uk> 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

[Fraga, Eric]

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

[stardiviner]

Bastien <bzg@gnu.org> 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

[Bastien]

Hi stardiviner,

stardiviner <numbchild@gmail.com> writes:

> I can't added numeric priorities with default =[C-c ,]= keybinding.*

The <C-c ,> 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
<C-c ,> again.

Thanks,

-- 
 Bastien

Re: A few changes to test in master

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 581 bytes --]

On Fri, Jan 31, 2020, 6:28 AM Bastien <bzg@gnu.org> 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.

[-- Attachment #2: Type: text/html, Size: 1328 bytes --]

Re: A few changes to test in master

[Samuel Wales]

org-table-header-line-mode?

Re: A few changes to test in master

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 113 bytes --]

On Fri, Jan 31, 2020, 9:45 PM Samuel Wales <samologist@gmail.com> wrote:

> org-table-header-line-mode?
>

+1

>

[-- Attachment #2: Type: text/html, Size: 644 bytes --]

Re: A few changes to test in master

[Bastien]

Samuel Wales <samologist@gmail.com> 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

[Axel Kielhorn]

> Am 31.01.2020 um 12:26 schrieb Bastien <bzg@gnu.org>:
> 
> 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

[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?

-- 
 Bastien

Re: A few changes to test in master

[Axel Kielhorn]

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

[Bastien]

Hi Axel,

Axel Kielhorn <org-mode@axelkielhorn.de> 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

[Axel Kielhorn]

> Am 01.02.2020 um 17:39 schrieb Bastien <bzg@gnu.org>:
> 
> Hi Axel,
> 
> Axel Kielhorn <org-mode@axelkielhorn.de> 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

[Bastien]

Hi Axel,

Axel Kielhorn <org-mode@axelkielhorn.de> 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

[Jack Kamm]

Bastien <bzg@gnu.org> 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]

Hi Jack,

Jack Kamm <jackkamm@gmail.com> writes:

> Bastien <bzg@gnu.org> 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

[Jack Kamm]

Hi Bastien,

Bastien <bzg@gnu.org> 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

[Bastien]

Hi Jack,

Jack Kamm <jackkamm@gmail.com> 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

[Jack Kamm]

[-- Attachment #1: Type: text/plain, Size: 943 bytes --]

Hi Bastien,

Bastien <bzg@gnu.org> 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.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-org-faces.el-Add-foreground-color-to-org-table-heade.patch --]
[-- Type: text/x-patch, Size: 912 bytes --]

From 2922d104b3508b1269c17ad0a28103bd912e308b Mon Sep 17 00:00:00 2001
From: Jack Kamm <jackkamm@gmail.com>
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

[Bastien]

Hi Jack,

Jack Kamm <jackkamm@gmail.com> 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