Re: [O] Broken org-mode "Column width and alignment" in latest version
Dear Kaushal, It took me a while to digest everything in your message, but I have finally managed to do my home-work and everything is now working perfectly! Thanks very much! Yours, Ruy On Tue, Dec 12, 2017 at 6:53 PM, Kaushal Modi <kaushal.m...@gmail.com> wrote: > On Sat, Dec 9, 2017 at 1:11 PM Ruy Exel <ruye...@gmail.com> wrote: >> >> Dear Kaushal, >> >> The real treat is to read your nice message and to be a member of such a >> fantastic group of people! >> >> Following your advice to stick to a stable release I searched for info on >> how to install it and I found instructions in >> http://orgmode.org/org.html#Installation telling me to run "M-x >> package-install RET org RET" from within emacs. I did it and it all looked >> like everything was running smoothly untill I was issued the messages: >> >> WARNING: No org-loaddefs.el file could be found from where org.el is >> loaded. You need to run "make" or "make autoloads" from Org lisp directory > > > Did you add Org Elpa to package archives as described here: > http://orgmode.org/elpa.html ? > >> I am used to this since I first tried the cloned git version, but I >> noticed that there is no Makefile in the directory containing the newly >> dowloaded files (~/.emacs.d/elpa/org-20171113/), so I got stuck. > > > I haven't installed Org from within Emacs for quite some time now as I build > it using make from its git clone. Also I haven't seen the warning that you > see. Hopefully someone else can comment on that part. > > I noticed though that the Org version you quoted: > ~/.emacs.d/elpa/org-20171113/ is a bit old (not too old, but not the latest > served on Elpa either). If you add the Org Elpa to package-archive as I > suggested above, and install using the M-x package-list-packages interface, > the archives will first get auto-refreshed, and then you can be rest assured > that the installed packages are the latest versions. > >> >> I noticed that in the above installation instructions it is mentioned >> that: >> >> Important: you need to do this in a session where no .org file has been >> visited, i.e., where no Org built-in function have been loaded. Otherwise >> autoload Org functions will mess up the installation. >> >> so I repeated the process right after starting emacs with the >> --no-init-files option, then I added the line "(package-initialize)" to my >> initialization file but it still does not work, > > > What doesn't work? You shouldn't need to do --no-init-files. Simply make > sure that your config is not doing (require 'org) directly or indirectly > somewhere and you are not opening an Org file at emacs startup. That's all. > >> >> namely the old org-mode is loaded upon starting emacs. > > > How are you telling that? If you do M-: (featurep 'org) and it returns nil, > it means that org is not yet loaded. > >> >> It is curious that I now have two org-mode entries in the top Emacs-Info >> node, one for the old version (7.9.3f) and another one for the new one >> (9.1.2 (release_9.1.2-37-g3f8d67)). > > > That's a different thing, has to do with the Info-directory-list variable, > and is fine. You can have paths to Info manuals from multiple Org versions > added to that var, and so you will see multiple Org manuals. I personally > don't like that and so I surgically remove[1] all the Org versions that I am > not using in the current emacs session from load-path and > Info-directory-list. > >> Could I have premanently messed up my emacs installation by not following >> the above Important advice? > > > Not trying to sound philosophical, but nothing is permanent. All the package > installations happen in the elpa dir.. so to start the Org installation from > scratch, you can rm -rf all the org installations from the elpa/ dir and > restart emacs following that "Important" instruction and retry installing > Org. > > [1]: https://scripter.co/building-org-development-version/ > -- > > Kaushal Modi
[O] Confusing org-cycle invocation when cursor is in invisible text
I feel this issue might have already been raised here but after researching it I could not find anything relevant. So please ignore this message and excuse me if I am returning to something already discussed in this group. Consider the following simple tree structure - * Trees ** Pine It is a conifer ** Oak Place cursor here -> It belongs to the genus Quercus - If you place the cursor where indicated (i.e. after the sentence "Place cursor here ->" above) and press (org-shifttab), your buffer will show * Trees... with the cursor placed on the first of the three dots. If you then go to the kitchen to prepare a coffee and come back, you will probably not going to remember where the cursor was before the visibility went to the OVERVIEW state. Suppose you then decide to expand your tree by pressing (org-cycle) without having changed cursor position. In this case your buffer will turn to * Trees... ** Oak Place cursor here -> It belongs to the genus Quercus and you might then be led to thinking that your header "Trees" has only one sub-header, namely "Oak". Yes I know that the three dots after "Trees" is meant to indicate that there is still some hidden text but, given that your intention was to expand "Trees" and that you pressed the correct key for this purpose you might (incorrectly) feel assured that you achieved the appropriate goal and hence not pay due attention to the three dots. The point I want to raise is that I believe users should not be required to remember the position of the cursor when it falls inside hiddent text. Even more so, the state of the system at any given time should not depend on said position. Thus, after the first press of , above, the cursor should go by default to the beginning (maybe the end) of the hidden text. By the way, this behavior is already adopted when text becomes hidden due to a call to org-table-toggle-column-width. Regards, Ruy
Re: [O] Broken org-mode "Column width and alignment" in latest version
Dear Kaushal, The real treat is to read your nice message and to be a member of such a fantastic group of people! Following your advice to stick to a stable release I searched for info on how to install it and I found instructions in http://orgmode.org/org.html#Installation telling me to run "M-x package-install RET org RET" from within emacs. I did it and it all looked like everything was running smoothly untill I was issued the messages: WARNING: No org-loaddefs.el file could be found from where org.el is loaded. You need to run "make" or "make autoloads" from Org lisp directory I am used to this since I first tried the cloned git version, but I noticed that there is no Makefile in the directory containing the newly dowloaded files (~/.emacs.d/elpa/org-20171113/), so I got stuck. I noticed that in the above installation instructions it is mentioned that: Important: you need to do this in a session where no .org file has been visited, i.e., where no Org built-in function have been loaded. Otherwise autoload Org functions will mess up the installation. so I repeated the process right after starting emacs with the --no-init-files option, then I added the line "(package-initialize)" to my initialization file but it still does not work, namely the old org-mode is loaded upon starting emacs. It is curious that I now have two org-mode entries in the top Emacs-Info node, one for the old version (7.9.3f) and another one for the new one (9.1.2 (release_9.1.2-37-g3f8d67)). Could I have premanently messed up my emacs installation by not following the above Important advice? Regards, Ruy Exel On Sat, Dec 9, 2017 at 12:50 AM, Kaushal Modi <kaushal.m...@gmail.com> wrote: > Hello Ruy, > > First of all, thanks for confirming that this worked for you. > > Secondly, no question is a newbie question :) This mailing list is one of > the friendliest mailing lists I've participated in. So don't worry about > upsetting someone, or getting offended. So I am continuing this thread on > the mailing list. > > Feel free to ask any kind of Org question you might have, and there are > many folks here to help you out. > > Further comments are inline below. > > On Fri, Dec 8, 2017, 5:56 PM Ruy Exel <ruye...@gmail.com> wrote: > >> >> > #+BEGIN_EXAMPLE >> > ,#+STARTUP: align shrink >> > #+END_EXAMPLE >> >> Got it! Thanks very much. >> > > You're welcome. > > I am in fact a brand new user of org-mode and 7.9.3f is just the version >> which was dormant in my computer before I updated to the GIT version. >> Sometimes I use it for comparison. >> > > If you are a brand new user, it's my personal opinion that that stick to > the stable release. You get that by cloning the maint branch instead, or > getting org or org-plus-contrib via Org Elpa. > > The master branch isn't unstable, it's perfectly fine as a daily driver, > but some features could be in flux, which could get confusing if you just > started using Org. > > However I noticed that the online manual at (http://orgmode.org/manual/Col >> umn-width-and-alignment.html) is more compatible with that old version >> than the GIT version. >> > > The online version is synced with the stable releases of Org, which I > mentioned above. It's not in sync with the version you think (7.9.3f), but > with the latest stable release 9.1.4 (as of today). > > It just happens that the column shrink feature was recently (few months) > added to the Org master branch. So you don't see its reference in the > online manual. That feature will go out in the next major release of the > stable version.. 9.2. > > Of course I do not expect to have a fully working manual for a changing >> system such as the GIT version, >> > > You're in for a treat here :). This is Emacs, and in my experience the > best way to access the Info manuals. The Info manuals that get built along > with Org are always in sync with the respective versions. > > So, > > Org master > Manuals: Info (synced with Org master) > > Org maint > Manuals: Info, online (synced with Org maint) > > If you haven't used Info manuals, do C-h i h to learn how to use those > from within Emacs. They are vastly better searchable than the online > version. And you always access the correct version of the Org Info manual > from within Emacs. > > but in case the above manual is superseded by some other one, I'd like to >> know where it is. >> > > As above, if using master branch Org, you get the correct version of the > manual from within Emacs. > > PS: I figure this newbie message is not relevant to the folks at >> emacs-orgmode@gnu.org, so I'am not CCing it there anymore. >> > > As I said in the beginning of the email, don't worry. We are all here to > learn and share. > >> -- > > Kaushal Modi >
[O] Broken org-mode "Column width and alignment" in latest version
The "Column width and alignment" feature of org-mode ( http://orgmode.org/manual/Column-width-and-alignment.html) is not working in the latest GIT version (as of Fri Dec 8 20:06:59 BRST 2017). I have just tested it in the table |---+--| | | <6> | | 1 | one | | 2 | two | | 3 | This is a long chunk of text | | 4 | four | |---+--| which is actually the example given in the manual. It fails under the latest version (column width is unchanged upon alignment) but it works OK in an older version (Org version 7.9.3f - GNU Emacs 24.3). Regards, Ruy
Re: [O] Deletion immediately after insertion should leave org-mode tables unaltered but it doesn't
Hi Nicolas, With the new implementation, is it possible to insert a column to the left of the first column? Best, Ruy On Tue, Nov 21, 2017 at 8:47 PM, Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote: > Hello, > > Ruy Exel <ruye...@gmail.com> writes: > >> This is indeed a good idea as it mimics the creation of a row in emacs >> text-mode with "C-o". > > This is now implemented. > > Regards, > > -- > Nicolas Goaziou0x80A93738
Re: [O] Deletion immediately after insertion should leave org-mode tables unaltered but it doesn't
Hi Nicolas, This is indeed a good idea as it mimics the creation of a row in emacs text-mode with "C-o". Best wishes, Ruy On Sat, Nov 18, 2017 at 9:37 PM, Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote: > Hello, > > Ruy Exel <ruye...@gmail.com> writes: > > > Given a simple table such as > > > > | Name | Age | > > |---+-| > > | John | 20 | > > | Peter | 25 | > > |---+-| > > > > place the cursor in the cell containing 'Age', insert two columns > pressing > > 'M-S-right' each time and, immediately after that, delete two columns > with > > "M-S-left". One would expect the table to return to its original state, > > but is doesn't. In reality the table becomes > > > > | | Age | > > |---+-| > > | | 20 | > > | | 25 | > > |---+-| > > > > because the second deletion actually kills the column labeled "Name". > > > > Contrast this with the behaviour of inserting and deleting characters in > > text-mode and you will see that the above behaviour is counter intuitive. > > > > I believe this is due to the fact that 'M-S-right' inserts a column at > the > > cursor, placing the cursor within the inserted column, while, after > > deletion, the cursor is placed in the column to the LEFT of the deleted > > column (except after deleting the leftmost column). > > > > A possible solution is to place the column to the RIGHT of the deleted > > column after deletion (except after deleting the rightmost column). > > The deletion is triggered by pressing the arrow. Your suggestion > would make the point move right. This is not optimal either. > > Maybe the other way is better. Since column creation is triggered by > pressing arrow, we might create it to the right of the current > column, and point would move into it. > > WDYT? > > Regards, > > -- > Nicolas Goaziou > On Sat, Nov 18, 2017 at 9:37 PM, Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote: > Hello, > > Ruy Exel <ruye...@gmail.com> writes: > > > Given a simple table such as > > > > | Name | Age | > > |---+-| > > | John | 20 | > > | Peter | 25 | > > |---+-| > > > > place the cursor in the cell containing 'Age', insert two columns > pressing > > 'M-S-right' each time and, immediately after that, delete two columns > with > > "M-S-left". One would expect the table to return to its original state, > > but is doesn't. In reality the table becomes > > > > | | Age | > > |---+-| > > | | 20 | > > | | 25 | > > |---+-| > > > > because the second deletion actually kills the column labeled "Name". > > > > Contrast this with the behaviour of inserting and deleting characters in > > text-mode and you will see that the above behaviour is counter intuitive. > > > > I believe this is due to the fact that 'M-S-right' inserts a column at > the > > cursor, placing the cursor within the inserted column, while, after > > deletion, the cursor is placed in the column to the LEFT of the deleted > > column (except after deleting the leftmost column). > > > > A possible solution is to place the column to the RIGHT of the deleted > > column after deletion (except after deleting the rightmost column). > > The deletion is triggered by pressing the arrow. Your suggestion > would make the point move right. This is not optimal either. > > Maybe the other way is better. Since column creation is triggered by > pressing arrow, we might create it to the right of the current > column, and point would move into it. > > WDYT? > > Regards, > > -- > Nicolas Goaziou >
[O] Deletion immediately after insertion should leave org-mode tables unaltered but it doesn't
Given a simple table such as | Name | Age | |---+-| | John | 20 | | Peter | 25 | |---+-| place the cursor in the cell containing 'Age', insert two columns pressing 'M-S-right' each time and, immediately after that, delete two columns with "M-S-left". One would expect the table to return to its original state, but is doesn't. In reality the table becomes | | Age | |---+-| | | 20 | | | 25 | |---+-| because the second deletion actually kills the column labeled "Name". Contrast this with the behaviour of inserting and deleting characters in text-mode and you will see that the above behaviour is counter intuitive. I believe this is due to the fact that 'M-S-right' inserts a column at the cursor, placing the cursor within the inserted column, while, after deletion, the cursor is placed in the column to the LEFT of the deleted column (except after deleting the leftmost column). A possible solution is to place the column to the RIGHT of the deleted column after deletion (except after deleting the rightmost column). Best wishes, Ruy
Re: [O] Table refuses to forget cell formula which once overrode a column formula
Thanks for your reply. I now understand and I also agree it is a good solution. Best, Ruy On Nov 15, 2017 19:54, "Nicolas Goaziou" <m...@nicolasgoaziou.fr> wrote: > Ruy Exel <ruye...@gmail.com> writes: > > > Thanks very much. Just out of curiosity I'd be interested in > understanding > > how did you do it. My (non expert) impression is that using properties > to > > override column formulas isn't a good idea. > > The property is here to prevent evaluation of a column formula on > a given field. It doesn't override anything. > > > It seems to me it would be more natural to apply cell formulas AFTER > > all column formulas were applied, so that each cell would be simply > > the output of the formula defining it. > > This is what happens already. The property prevents useless > computations. > > Regards, >
Re: [O] Table refuses to forget cell formula which once overrode a column formula
Hi Nicolas,
Thanks very much. Just out of curiosity I'd be interested in understanding
how did you do it. My (non expert) impression is that using properties to
override column formulas isn't a good idea. It seems to me it would be
more natural to apply cell formulas AFTER all column formulas were applied,
so that each cell would be simply the output of the formula defining it.
Best,
Ruy
On Nov 15, 2017 14:42, "Nicolas Goaziou" <m...@nicolasgoaziou.fr> wrote:
Hello,
Ruy Exel <ruye...@gmail.com> writes:
> The following is very simple org-mode spreadsheet in which the cells in
the
> second column show the triple of the corresponding cell in the first
column
> due to the "column formula" in its TBLFM row $2=3*$1;N. However the third
> row (actually row @4) is an exception because of the "cell formula"
> @4$2=string("Exception") which expectedly overrides the above column
> formula.
>
> |+---|
> | Number |Triple |
> |+---|
> | 1 | 3 |
> | 2 | 6 |
> | 3 | Exception |
> | 4 |12 |
> |+---|
>
> #+TBLFM: $2=3*$1::@4$2=string("Exception")
>
> So all is well. Below you will find a copy of the above table, except
that,
> after copying, I have deleted the exceptional formula affecting cell @4$2.
>
> |+---|
> | Number |Triple |
> |+---|
> | 1 | 3 |
> | 2 | 6 |
> | 3 | Exception |
> | 4 |12 |
> |+---|
>
> #+TBLFM: $2=3*$1
>
> One would expect that, after updating this table with C-u C-c *, or C-c
C-c
> in the TBLFM line, the exceptional value in cell @4$2 would revert to the
> triple of '3', but instead the string "Exception" stays put.
Fixed. Thank you.
Regards,
--
Nicolas Goaziou
Re: [O] org-mode gets confused with column widths when 'time-stamp-custom-formats' are applied.
Wow! That was quick. Thanks.
Ruy
On Nov 15, 2017 15:15, "Nicolas Goaziou" <m...@nicolasgoaziou.fr> wrote:
> Hello,
>
> Ruy Exel <ruye...@gmail.com> writes:
>
> > Consider the table below:
> >
> > | Name | Date of Birth|
> > |---+--|
> > | John | <1978-11-14 Tue> |
> > | Peter | <1970-11-14 Sat> |
> > |---+--|
> >
> > Suppose we want to format time stamps differently, such as with the
> > following elisp commands:
> >
> > (setq org-time-stamp-custom-formats (quote ("<%d %b %y>" . "<%m/%d/%y %a
> > %H:%M>")))
> > (org-toggle-time-stamp-overlays)
> >
> > After realigning the table you get
> >
> > | Name | Date of Birth|
> > |---+--|
> > | John | <14 Nov 1978> |
> > | Peter | <14 Nov 1970> |
> > |---+--|
>
> Fixed. Thank you.
>
> Regards,
>
> --
> Nicolas Goaziou
>
[O] org-mode gets confused with column widths when 'time-stamp-custom-formats' are applied.
Consider the table below:
| Name | Date of Birth|
|---+--|
| John | <1978-11-14 Tue> |
| Peter | <1970-11-14 Sat> |
|---+--|
Suppose we want to format time stamps differently, such as with the
following elisp commands:
(setq org-time-stamp-custom-formats (quote ("<%d %b %y>" . "<%m/%d/%y %a
%H:%M>")))
(org-toggle-time-stamp-overlays)
After realigning the table you get
| Name | Date of Birth|
|---+--|
| John | <14 Nov 1978> |
| Peter | <14 Nov 1970> |
|---+--|
which is wrong because column widths are not uniform. The reason, I
suppose, is that when computing column widths, org-mode ignores the fact
that the change of time stamps may have altered the length of the printed
string.
Best wishes,
Ruy Exel
[O] Table refuses to forget cell formula which once overrode a column formula
This bug report is motivated by a question I asked at
https://emacs.stackexchange.com/questions/36855/table-refuses-to-forget-cell-formula-which-once-overrode-a-column-formula
and all of the necessary information can probably be obtained from there.
Nevertheless let me repeat it here:
-
The following is very simple org-mode spreadsheet in which the cells in the
second column show the triple of the corresponding cell in the first column
due to the "column formula" in its TBLFM row $2=3*$1;N. However the third
row (actually row @4) is an exception because of the "cell formula"
@4$2=string("Exception") which expectedly overrides the above column
formula.
|+---|
| Number |Triple |
|+---|
| 1 | 3 |
| 2 | 6 |
| 3 | Exception |
| 4 |12 |
|+---|
#+TBLFM: $2=3*$1::@4$2=string("Exception")
So all is well. Below you will find a copy of the above table, except that,
after copying, I have deleted the exceptional formula affecting cell @4$2.
|+---|
| Number |Triple |
|+---|
| 1 | 3 |
| 2 | 6 |
| 3 | Exception |
| 4 |12 |
|+---|
#+TBLFM: $2=3*$1
One would expect that, after updating this table with C-u C-c *, or C-c C-c
in the TBLFM line, the exceptional value in cell @4$2 would revert to the
triple of '3', but instead the string "Exception" stays put. Is this a bug
or am I doing something wrong?
I noticed that if I save the file, close it (kill-buffer) and then reopen
it, the strange behaviour disapears, namely, updating the table with C-u
C-c * causes cell @4$2 to turn to '9', as expected.
I am using GNU Emacs 24.3.1 and the latest version of org-mode.
-
The answer I got from emacs.stackexchange.com says:
-
The persistence of the string exception has nothing to do with copying. If
you recalculate the original table and afterwards remove the field formula
from it you also have the problem that exception is not replaced by 9 at
the next recalculation.
The reason for that behavior is that the text property :org-untouchable is
put on the output of field formulas. The normal function of
:org-untouchable is to prevent the modification of cells with field
formulas during the evaluation of a column formulas.
In my opinion the :org-untouchable property should be removed at the
beginning of calls to org-table-iterate and at the beginning of interactive
calls of org-table-recalculate.
You can obtain this behavior with the advices below. These advices are
tested with org-version 9.0.5 in emacs 25.1.50.2.
I would agree that the original behavior is faulty. Therefore, I suggest to
file a bug-report at https://lists.gnu.org/mailman/listinfo/emacs-orgmode.
A proper bug-fix should probably be implemented differently.
(defun org-table-remove-untouchable ( _args)
"Remove `:org-untouchable' property from org-table."
(save-excursion
(cl-assert (org-at-table-p) nil "Not in org-table.")
(remove-text-properties (org-table-begin) (org-table-end)
'(:org-untouchable nil
(defun org-table-recalculate-remove-untouchable ( all _noalign)
"Remove `:org-untouchable' property at the beginning of
`org-table-iterate'.
Use this function as :before advice of `org-table-iterate'."
(when (and (called-interactively-p 'any)
all)
(org-table-remove-untouchable)))
(advice-add 'org-table-iterate :before #'org-table-remove-untouchable)
(advice-add 'org-table-recalculate :before
#'org-table-recalculate-remove-untouchable)
-
Sincerely,
Ruy Exel
