[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: catchfilebetweentags the final version.
From: |
Arash Esbati |
Subject: |
Re: catchfilebetweentags the final version. |
Date: |
Thu, 25 Aug 2022 21:17:43 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 |
Uwe Brauer <oub@mat.ucm.es> writes:
>>>> "AE" == Arash Esbati <arash@gnu.org> writes:
>
>> I think this one should be customizable variable, right? Then it should
>> go in tex-style.el and look like this:
>
>> (defcustom LaTeX-catchfilebetweentags-use-numeric-label t
>> "Insert automatic numerical labels if non-nil."
>> :type 'boolean)
>
> I am confused now, I did understand you that this defcustom should go
> into tex-style.el, but I see you put in catchfilebetweentags.el
>
> So I am a bit confused.
I did everything in catchfilebetweentags.el and then wrote the message.
So yes, the idea was: Please move that from the catchfilebetweentags.el
I posted to tex-style.el 😅
>>> +(defvar catchbetween-counter 0
>>> + "Counter for catchfilebetweentags numbers.")
>>> +(make-variable-buffer-local 'catchbetween-counter)
>
>> I suggest to initialize this one to nil and add it
>> `TeX-normal-mode-reset-list' in the style hook. Then a user can reset
>> the variable with 'C-u C-c C-n' if it gets out of sync. Do:
>
> I don't understand that so
> LaTeX-catchfilebetweentags-use-numeric-label should be set to nil or t
> per default.
Your call I'd say. My suggestion would be nil since I'm not sure how
many other users use your scheme.
> If it is nil, I don't understand your comments about
> `TeX-normal-mode-reset-list' in the style hook
>
> I thought you run customize-option if is controlled by defcustom.
I was talking about this portion:
(defvar-local LaTeX-catchfilebetweentags-counter nil
"Counter for LaTeX-catchfilebetweentags numbers.")
Initially, you had
(defvar-local LaTeX-catchfilebetweentags-counter 0
"Counter for LaTeX-catchfilebetweentags numbers.")
> So as far as I can see you rewrote catchbetween-environment
>
> #+begin_src
> (defun LaTeX-env-catchfilebetweentags (_environment)
> "Insert a tag-skeleton defined by `LaTeX-catchfilebetweentags'.
> ENVIRONMENT is ignored."
> (let* ((fn (when LaTeX-catchfilebetweentags-use-numeric-label
> (LaTeX-catchfilebetweentags-counter-inc)))
> (tag (TeX-read-string
> (if fn (format "Tag (default %s): " fn) "Tag: ")
> nil nil (when fn (number-to-string fn)))))
> (unless (bolp)
> (newline)
> (delete-horizontal-space))
> (save-excursion
> (insert (concat (format "%%<*%s>" tag)
> "\n\n"
> (format "%%</%s>" tag)))))
> (forward-line))
> #+end_src
>
> Right? That is way above my elips knowledge, but I see you added the tag
> input, which is good.
>
> So it looks nice to me, much better than my version but I don't
> understand your comments about «TeX-normal-mode-reset-list' in the style
> hook»
My idea was: If `LaTeX-catchfilebetweentags-use-numeric-label' is nil,
the code above will always ask for a tag, without a default value since
`LaTeX-catchfilebetweentags-counter-inc' is never run.
If `LaTeX-catchfilebetweentags-use-numeric-label' is t, then
`LaTeX-catchfilebetweentags-counter-inc' checks if
`LaTeX-catchfilebetweentags-counter' is nil and then reparses the file.
Otherwise it just increments the counter. By adding
`LaTeX-catchfilebetweentags-counter' to `TeX-normal-mode-reset-list'
users can initiate a reparse unconditionally. Does it make sense?
Best, Arash
- catchfilebetweentags the final version., Uwe Brauer, 2022/08/24
- Re: catchfilebetweentags the final version., Arash Esbati, 2022/08/24
- Re: catchfilebetweentags the final version., Arash Esbati, 2022/08/24
- Re: catchfilebetweentags the final version., Uwe Brauer, 2022/08/25
- Re: catchfilebetweentags the final version., Uwe Brauer, 2022/08/25
- Re: catchfilebetweentags the final version.,
Arash Esbati <=
- Re: catchfilebetweentags the final version., Uwe Brauer, 2022/08/26
- [a new patch] (was: catchfilebetweentags the final version.), Uwe Brauer, 2022/08/26
- Re: [a new patch], Arash Esbati, 2022/08/29
- Re: [a new patch], Uwe Brauer, 2022/08/30
- Re: [a new patch], Uwe Brauer, 2022/08/30
- Re: [a new patch], Uwe Brauer, 2022/08/30
- Re: [a new patch], Arash Esbati, 2022/08/31
- Re: [a new patch], Uwe Brauer, 2022/08/31