Nicolas Goaziou writes:
> I made some final changes to "hide-table-column" branch:
>
> - Now C-u C-c TAB shrink columns with a width cookie and expands the
> others;
>
> - When point is before the first column or after the last one, C-c TAB
> asks for columns ranges;
>
> - I added d
Completing myself,
Nicolas Goaziou writes:
> `org-table-toggle-column-width' is now bound to "C-c TAB". I removed
> "noshrink" STARTUP keyword, which wasn't useful. I also introduced an
> honest test coverage.
>
> Still no documentation, though.
I made some final changes to "hide-table-column"
Hello,
Adam Porter writes:
> My only feedback here is that maybe the startup keywords would be more
> descriptive if they were something like "table-shrink" or
> "column-shrink". I could imagine some new Org users conflating "folded"
> and "shrink" until they have used a more advanced feature l
Hello,
Eric S Fraga writes:
> Thanks Nicolas. Sounds very nice, matching at least my use cases quite
> well. I'll give this a try soon and will get back to you.
For the record, I updated the "hide-table-column" branch again.
`org-table-toggle-column-width' is now bound to "C-c TAB". I remove
Nicolas Goaziou writes:
> Moreover, I added two new STARTUP keywords: "shrink" and "noshrink",
> which allow to apply aforementioned `org-table-shrink' command on all
> tables upon opening a document. Not that "align" no longer toggle column
> width.
Hi Nicolas,
I'm late to this conversation, b
Hello,
Rick Frankel writes:
> Personally, my use of width cookies has been mostly for visual display of
> columns are very long and will wrap in an html or latex table export, but
> would force the display too wide. My ideal default would be to have a setting
> which would shrink tables a reason
Thanks Nicolas. Sounds very nice, matching at least my use cases quite
well. I'll give this a try soon and will get back to you.
--
: Eric S Fraga via Emacs 26.0.50, Org release_9.0.9-573-g09e612
signature.asc
Description: PGP signature
Hello,
bvrag...@iitk.ac.in (B.V. Raghav) writes:
> Can I request/suggest a new feature `#+TABLE_PROPERTIES: ' analogous to
> `#+TBLFM: ' that can save the state for those of us who want to, and the
> others may enjoy the volatileness[?]
Thank you for your suggestion.
However, I'm looking for s
Hello,
Eric S Fraga writes:
> I have two use cases which currently are managed with the width cookies
> and I can see that they probably should be managed differently. The
> cases are:
>
> 1. a table with wide columns that is used to collect information
>(publications with authors, title, j
Eric S Fraga writes:
> Hi Nicolas,
>
> I agree completely with your stated objective, specifically separating
> viewing from content and/or export. However, I am not sure this is
> achievable without losing some quite appealing current functionality.
>
If I understant correctly, `' defines a per
So I haven't posted in a while, but i use table a lot, so here's my $0.02.
Personally, my use of width cookies has been mostly for visual display of
columns are very long and will wrap in an html or latex table export, but
would force the display too wide. My ideal default would be to have a setti
Dear Nicolas,
I apologise for not understanding fully what you propose. I use org-mode
extensively, so any possibility of "change" tends to make me anxious.
Nicolas> Besides, columns cookies may work for you, but, as pointed
Nicolas> out, they are limited:
Nicolas> - Setting a width
Hi Nicolas,
I agree completely with your stated objective, specifically separating
viewing from content and/or export. However, I am not sure this is
achievable without losing some quite appealing current functionality.
I have two use cases which currently are managed with the width cookies
and
Hello,
Colin Baxter writes:
> Column cookies work - and they work well for me - so why on earth remove
> something that is actually *useful*?
Really, I explained already the motivation, right from my initial post.
Anyway, let me re-iterate and expound it a bit.
The first thing to know is I'm *
Hello,
I have come to this discussion late, but I totally agree with Kaushal,
whose use of tables almost mirrors my own.
Kaushal> I didn't understand the root reason for this change. If one
Kaushal> doesn't like using the column width cookies, then they can
Kaushal> choose to not use
> Hello,
> Kaushal Modi writes:
> This is not possible, and is exactly what annoys me in the current
> implementation.
> Moreover, I'm pretty sure you don't review every table in your
> document at the second it is opened. So there is no need to store
> the columns
On Tue, Jul 11, 2017 at 3:09 PM Nicolas Goaziou
wrote:
> Hello,
>
> Kaushal Modi writes:
>
> > 1. Need to save the column narrowed state somehow individually for each
> > column, specific to a table in a document.
>
> This is not possible, and is exactly what annoys me in the current
> implement
Hello,
Kaushal Modi writes:
> 1. Need to save the column narrowed state somehow individually for each
> column, specific to a table in a document.
This is not possible, and is exactly what annoys me in the current
implementation.
Moreover, I'm pretty sure you don't review every table in your d
On Tue, Jul 11, 2017 at 8:26 AM Nicolas Goaziou
wrote:
>
> I don't use column narrowing; I don't know what other users expect from
> it either.
>
I use column narrowing when I need to fit all columns of an org table in a
screen width (roughly 100 chars wide).
If I have a column called "Descript
Hi Nicolas
On Tue, Jul 11, 2017 at 1:47 PM, Nicolas Goaziou wrote:
> Michael Brand writes:
>> Also I hope that you can build in complete removal of columns for
>> export similar to as discussed around here:
>> http://lists.gnu.org/archive/html/emacs-orgmode/2016-04/msg00672.html
> Besides, wa
Uwe Brauer writes:
> That would be great indeed. So please don't drop the branch but instead,
> if you have time, try that and I would be more than happy to test it and
> then hopefully narrowing based on cookies could be dropped.
I will as soon as I have an idea about the "that" I have to try.
>>> "Nicolas" == Nicolas Goaziou writes:
> Uwe Brauer writes:
>> So you are saying we cannot have both.
> I'm not. I'm opposed to have overlapping features with two different
> implementations, that's all.
>> But couldn't the feature of shrink one particular wide column to a
Hello,
Michael Brand writes:
> Also I hope that you can build in complete removal of columns for
> export similar to as discussed around here:
> http://lists.gnu.org/archive/html/emacs-orgmode/2016-04/msg00672.html
This is orthogonal to the issue at hand.
Besides, was I supposed to implement i
Uwe Brauer writes:
> So you are saying we cannot have both.
I'm not. I'm opposed to have overlapping features with two different
implementations, that's all.
> But couldn't the feature of shrink one particular wide column to a
> certain width be implemented using your new implementation?
I al
>>> "Nicolas" == Nicolas Goaziou writes:
> Hello,
> Uwe Brauer writes:
>> If you want to implement the second feature differently, because of
>> maintain reasons that sound reasonable, but please don't simple remove
>> the second feature.
> Then I'll just drop this branch. I'
>>> "Nicolas" == Nicolas Goaziou writes:
> Hello,
> Uwe Brauer writes:
>> If you want to implement the second feature differently, because of
>> maintain reasons that sound reasonable, but please don't simple remove
>> the second feature.
> Then I'll just drop this bran
Hello,
Uwe Brauer writes:
> If you want to implement the second feature differently, because of
> maintain reasons that sound reasonable, but please don't simple remove
> the second feature.
Then I'll just drop this branch. I'm against having the same (sub-set of
a) feature implemented in two d
> Hello,
> Uwe Brauer writes:
> There is much overlapping between the two features. I'd rather implement
> so sort of narrowing using shrunk columns than have the two features in
> the code base.
Well all I am saying is there is the need for two features:
Shrinking (hiding
Hi Nicolas
On Tue, Jul 11, 2017 at 12:11 AM, Kaushal Modi wrote:
> The feature works nicely as explained, but please do not remove the width
> cookie!
>
> The new feature supports only completely hiding a column. But what we lose
> by removal of width cookie is:
>
> - Ability to truncate text in
On Mon, Jul 10, 2017 at 10:44 AM Nicolas Goaziou
wrote:
> Hello,
>
> Uwe Brauer writes:
>
> > This is the patch I applied and tested? If so, I think it is a very good
> > thing and should be in master.
>
> This is the same patch, along with the complete removal of old column
> narrowing using wi
Hello,
Uwe Brauer writes:
> I just was faced with a table which just contained 3 columns but very
> many rows. In second column however was very wide, it contained titled
> of journals. So 'cutting' them to half was sufficient to identify them
> but allowed me to see the third column. So I say n
Uwe Brauer writes:
"Nicolas" == Nicolas Goaziou writes:
>
> > Hello,
> > Uwe Brauer writes:
>
> >> This is the patch I applied and tested? If so, I think it is a very
> good
> >> thing and should be in master.
>
> > This is the same patch, along with the complete remov
>>> "Nicolas" == Nicolas Goaziou writes:
> Hello,
> Uwe Brauer writes:
>> This is the patch I applied and tested? If so, I think it is a very good
>> thing and should be in master.
> This is the same patch, along with the complete removal of old column
> narrowing using
Hello,
Uwe Brauer writes:
> This is the patch I applied and tested? If so, I think it is a very good
> thing and should be in master.
This is the same patch, along with the complete removal of old column
narrowing using width cookies.
Regards,
--
Nicolas Goaziou
>>> "Nicolas" == Nicolas Goaziou writes:
> Hello,
> I'd like to replace the visual effect of width cookies (not
> interpretation by export back-ends) with a more dynamic one. To that
> effect, I pushed a "hide-table-column" branch in the repository.
This is the patch I applied and t
Hello,
Currently, the only way to shrink an Org table column is to use
a so-called width cookie (e.g., "" or "<10>") so that aligning
table forces the column to fit within the specified number of
characters. When the width is less than the number of characters in the
field, contents is hidden with
36 matches
Mail list logo
